Persisted state corruption can leave T3 Code unusable with no clear recovery path

[copypasteitworks]

Summary

Persisted state corruption can leave T3 Code unusable with no clear recovery path.

This should be treated as a separate reliability track, distinct from the already-open diff and version fixes.

Symptom

• the app can become broken or unusable on startup
• current bootstrap behavior does not clearly explain that persisted state load failed
• one malformed persisted runtime row can poison list-based recovery paths
• some Codex resume failures caused by state corruption are still treated as fatal even though a fresh thread start would be an acceptable fallback

Known workaround

In at least one repro, renaming state.sqlite allowed the app to recover.

That suggests persisted corruption can poison startup, but the mental model here should be broader than a single DB file.

Important

For this track, state should include all persisted surfaces that can poison startup or recovery:

• T3CODE_STATE_DIR
• state.sqlite
• files under the state dir such as keybindings, logs, attachments, and runtime metadata
• CODEX_HOME
• persisted browser/Electron client state

[eggfriedrice24]

Working on a server side fix for the SQLite corruption crash loop.

Root cause: NodeSqliteClient.ts calls openDatabase() synchronously with no error handling. When state.sqlite is corrupted, new DatabaseSync() throws, becoming an unhandled defect that crashes the process. The desktop app then restarts the backend in a loop, never recovering.

Repro (manual):

# write garbage into the database file
echo "not a db" > ~/.t3/userdata/state.sqlite
# start the app, observe crash loop:
# "Error: file is not a database" repeated every ~500ms
t3code

Fix will:

• Validate the SQLite file header before opening (valid files start with SQLite format 3\0, or the file doesn't exist yet)
• If corrupted, back up the bad file (.corrupted.<timestamp>) and let a fresh database be created
• Wrap openDatabase() in Effect.try so open failures produce typed errors instead of process crashes
• Log a clear warning when corruption is detected and auto recovered

Note: PR #964 (draft) addresses the web/UI recovery view for bootstrap snapshot failures. This fix is complementary, targeting the server side crash loop so the backend never gets stuck.

[israelvf]

Hey folks! I was experiencing the exact same infinite backend crash loop on startup (code=1 signal=null), but after doing a deep dive, I found that my issue was not related to SQLite corruption (a clean wipe of ~/.t3 and ~/.config/t3code didn't help).

It turns out it's an unhandled ENOTDIR exception caused by the Claude CLI path resolution.

The Root Cause

Using strace, I caught the backend dying because it attempts to execute claude inside the Go compiler binary:

[pid 1036996] execve("/usr/bin/go/claude", ["claude", "--version"], 0x11b00010ce00) = -1 ENOTDIR (Not a directory)

Because /usr/bin/go is a binary file (not a directory) on my system (Arch Linux/CachyOS), the OS throws an ENOTDIR error. The backend doesn't seem to catch this specific spawn error, which immediately crashes the node process:

ERROR (#10): Error: spawn ENOTDIR
    at ChildProcess.spawn (node:internal/child_process:421:11)
    at Module.spawn (node:child_process:810:9)
    at MixedScheduler.<anonymous> (file:///opt/t3code-bin/resources/app.asar/node_modules/@effect/platform-node-shared/dist/NodeChildProcessSpawner.js:228:37)

The Workaround

I managed to bypass the crash loop completely by installing the Claude CLI. Since the app now successfully finds the valid binary earlier in its search, it never reaches the buggy /usr/bin/go/claude check, and the backend survives.

Suggested Fix

It looks like the path resolution logic (perhaps iterating over $PATH) is blindly appending /claude to paths that are actually files instead of directories. Wrapping the spawn or path check in a try/catch that handles ENOTDIR should prevent the entire backend from going down when hunting for the agent. Hope this helps!