fix: ship fixed SQLite via SQLx 0.9#24670
Closed
btraut-openai wants to merge 3 commits into
Closed
Conversation
This was referenced May 27, 2026
Contributor
Author
|
This is being handled by other folks who have a better idea of how to test. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Codex uses pooled SQLite connections in WAL mode for runtime state databases. SQLite documents a rare WAL-reset race that can corrupt a database when concurrent writers or checkpointers operate across connections, and the bundled SQLite
3.46.0currently shipped by Codex is in the affected version range.This was observed in practice on May 26, 2026:
~/.codex/state_5.sqlitedeveloped structural B-tree corruption after thread and spawned-agent state persistence, eventually preventing Nightly startup. Shipping a fixed SQLite engine prevents new exposure; merely upgrading a binary does not repair a database that is already malformed.This is an alternate implementation to #24664. It explores taking the upstream SQLx release path rather than vendoring SQLite or maintaining a patched SQLx fork.
What Changed
1.93.0to1.94.0, required by SQLx0.9.0.0.8.6to0.9.0and usesqlite-bundledrather than SQLx 0.9's broadersqliteaggregate feature.libsqlite3-systo0.37.0, whose bundled amalgamation is SQLite3.51.3, outside the affected WAL-reset range.QueryBuilderlifetimes, and explicitly audit fixed-fragment dynamic SQL construction viaAssertSqlSafe.Data And Recovery
This change does not introduce a Codex schema migration or SQLite file-format migration. A healthy existing state database can be opened by the fixed build and remains readable by an older Codex build; rolling back would, however, re-expose subsequent writes to vulnerable SQLite.
An already-corrupted
state_5.sqliteis not made trustworthy by installing this build. Recovery should continue to back up the database, WAL, and SHM files before rebuilding queryable state from durable rollout JSONL history. The existing CLI recovery flow provides backup-and-rebuild behavior; desktop recovery UX remains separate follow-up work.Draft Caveat
This branch intentionally does not update
.github/workflows/*: GitHub push protection rejects changes to those paths from this branch. If the SQLx 0.9 approach is chosen, CI and release workflow Rust toolchain pins must be updated to1.94.0through the authorized workflow-change path before merging.Verification
just test -p codex-statejust test -p codex-clijust fix -p codex-statejust bazel-lock-updatejust bazel-lock-checklinked_sqlite_has_wal_reset_bug_fixtest that the linked runtime SQLite version is not vulnerable.just fmtcompleted its Rust formatting step; its unrelated Python SDKuvstage could not write to the sandboxed global cache in the local environment.