Recover legacy Codex thread names in the native state database

[huzhongyyuan]

Problem

Older Codex versions persisted renamed thread names in session_index.jsonl, while newer native surfaces also read threads.name from state_5.sqlite. After provider/relay changes, those legacy sessions remain resumable but their renamed titles can be absent in Codex CLI or Codex for VS Code.

Proposed behavior

On CC-Switch startup, perform a safe one-time backfill for each applicable Codex state database:

• fill only blank/null threads.name values from matching session_index.jsonl entries;
• never overwrite a current non-empty name;
• preserve archive status and all unrelated fields;
• cover the default Codex DB and configured sqlite_home;
• take a SQLite backup and use a crash-consistent per-DB migration ledger;
• protect against concurrent writers/source changes and bound startup work.

I have an implementation with focused race, rollback, replacement-DB, archive, malformed-input, size-limit, and sqlite_home tests and will open the PR after this issue as requested by the contribution guide.

[SaladDay]

Thanks for the thoughtful implementation and focused tests 🙏 After reviewing #396, I do not think an automatic startup migration is worth the long-term maintenance and data-safety cost in its current form.

Main concerns:

• threads.name is updated without checking history_mode. It is authoritative for paginated threads, not legacy threads, so many writes will not fix the intended UX and may leave stale searchable values.
• An empty thread_name is a valid clear/tombstone record, but the parser rejects it and aborts the entire migration. One cleared name can block unrelated recoveries on every startup.
• A same-ID race is not recoverable: a newer name appended after the final pre-commit check can leave the older value committed and the ID ledgered; the retry then filters that ID and never applies the newer name.
• This is not always a small one-time operation. Unmatched IDs can cause repeated index work and BEGIN IMMEDIATE locks, even a zero-row repair may create a permanent ledger table, and failed attempts can retain uniquely named backups without a retention policy.

⚠️ The remaining benefit is narrow, while merging this adds an automatic write path into an externally managed database, startup locking and I/O, backup lifecycle responsibilities, and future schema-compatibility work.

I would not merge this as a startup migration. If recovery is still desired, a safer shape would be an explicit opt-in repair command with a dry run, limited to applicable paginated rows, with tombstone-aware parsing, value-aware retry state kept in CC-Switch storage, and bounded backup retention.

Thanks again—the concern is the ongoing ownership and failure surface of the design, not the effort put into the patch.