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 framing

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

Version drift may sometimes be a downstream symptom of corrupted persisted state, not necessarily a separate root cause.

Proposed split

1. surface fatal initial bootstrap failure instead of swallowing it
2. harden malformed persisted provider runtime rows so one bad row does not poison listing/startup
3. widen recoverable Codex thread/resume fallback for narrow, clearly state-related corruption signatures
4. consider reset/clear-state UX separately only if smaller reliability slices are insufficient

Explicit non-goals

• do not bundle this with the diff-toggle fix
• do not bundle this with the version-display fix
• do not bundle reset/clear-state UX into the first reliability PR
• do not treat state.sqlite as the entire problem statement

Acceptance criteria for this issue

• maintainers can agree or redirect on the slice order before broader recovery UX is proposed
• follow-up PRs can stay narrowly scoped and upstreamable

[copypasteitworks]

Given CONTRIBUTING.md and the current state of the project I plan to start with a diagnosis-first draftPR that is intentionally tiny:

• surface fatal initial bootstrap snapshot failure instead of swallowing it
• keep scope to the web bootstrap path only
• no reset/clear-state UX (at this point)
• no provider runtime hardening in that PR
• no Codex resume fallback widening in that PR

If that direction is undesirable, I can stop there and leave it for later / local