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

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

Start by tracing bootstrap loading and recovery across T3CODE_STATE_DIR, state.sqlite, files under the state directory, CODEX_HOME, and persisted browser/Electron client state. Reproduce the unusable-startup and Codex resume cases, then define recovery behavior for malformed persisted data and fresh-thread fallback. Done should include clear failure messaging and a reliable recovery path.