[CLI] Concurrent startup races state DB migration 53 (duplicate column name: originator)

What version of Codex CLI is running?

Codex CLI 0.154.0 (Homebrew cask)

What subscription do you have?

ChatGPT Plus

Which model were you using?

N/A — the failure happened during local state initialization, before model selection.

What platform is your computer?

• macOS 26.6.2, Apple Silicon (macos-aarch64)
• agterm 0.28.0

What issue are you seeing?

When several Codex CLI sessions started almost simultaneously against the same existing
$CODEX_HOME, one process failed during state DB migration 53:

Codex couldn't start because its local database appears to be damaged.

Location: $CODEX_HOME/state_5.sqlite
Cause: failed to migrate state DB ... while executing migration 53:
error returned from database: (code: 1) duplicate column name: originator

The database was not damaged. Immediately after the incident:

• codex doctor --json reported state DB integrity: ok.
• PRAGMA quick_check returned ok.
• threads.originator existed.
• _sqlx_migrations recorded migrations 53 (threads originator) and 54
  (threads daybreak enabled) as successful at the exact second of the concurrent startup.
• A later Codex launch worked normally without repair or DB replacement.

Local logs show at least three Codex 0.154.0 processes first appearing in the same second. Two
of them also logged a concurrent system-skills installation failure (Directory not empty),
which independently confirms overlapping startup work.

My inference is that multiple processes determined migration 53 was pending before migration
execution was serialized. One process then applied and recorded the migration, while another
still attempted the already-planned ALTER TABLE ... ADD COLUMN originator and failed.

The generic "database appears to be damaged" message is misleading in this case and could
prompt users to unnecessarily rebuild a healthy DB.

What steps can reproduce the bug?

The likely sequence for this incident is below. The concurrent new-version starts are confirmed
by logs, but the exact pre-upgrade DB state was not preserved:

1. Keep several Codex sessions open for an extended period; some may still be older binaries.
2. Install a newer Codex version while those existing processes remain open.
3. Close the terminal application, terminating those sessions.
4. Reopen a terminal that restores all sessions by launching several Codex 0.154.0 instances
   concurrently.
5. All new processes share the same $CODEX_HOME/state_5.sqlite and encounter the newly
   available migration at approximately the same time.

A smaller synthetic reproducer may be to prepare a copy of a pre-migration-53 CODEX_HOME
and launch several Codex 0.154.0 processes against it simultaneously.

What is the expected behavior?

State DB migrations should be safe when multiple Codex processes start concurrently:

• Only one process should apply pending migrations.
• Waiting processes should re-read migration state after acquiring the migration lock.
• A process that loses the race should retry initialization rather than report DB corruption.

Additional information

Possible mitigations include a $CODEX_HOME-scoped migration lock, rechecking
_sqlx_migrations after acquiring the write lock, or retrying initialization when the final
schema and migration ledger are consistent.

No database, session transcript, authentication data, or unredacted local paths are attached.

Separately, if OpenAI has a contributor-recognition, swag, or bug-reward program for actionable
reports like this, I would be happy to be considered.

Start at Codex CLI startup state initialization and the state_5.sqlite migration path, focusing on migration 53 and the _sqlx_migrations ledger. Reproduce concurrent launches against a pre-migration-53 database if possible, then verify that migrations are serialized or retried and that healthy concurrent startup no longer reports database corruption.