state_5.sqlite and logs_1.sqlite grow unboundedly on long-running installs, causing write lock contention and app restart loop
What version of the Codex App are you using (From “About Codex” dialog)?
26.325 (internal engine: 0.118.0-alpha.2)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Windows 11 Pro 10.0.26200
What issue are you seeing?
On a machine that has been running Codex for several months, both SQLite databases grew to extreme sizes far outside any documented normal range. The bloat caused write lock contention, which manifested as repeated cache duplicate-write errors, ultimately triggering an auto-restart loop that made the app unusable.
What I saw the root might be:
PR #13781 reduced log retention from 90 days to 10 days, but the change only affects new writes — it does not retroactively purge or VACUUM existing rows on existing installs.
SQLite does not reclaim disk space after DELETE without an explicit VACUUM. Rows are removed logically but pages remain allocated.
Over months of daily use, log rows accumulate well past the point where the retention policy is effective, and no automatic VACUUM is triggered.
At extreme sizes, every write operation must wait for a read lock to be released on a bloated B-tree, creating contention that cascades into the app's cache layer.
What steps can reproduce the bug?
Run Codex Desktop actively for 3+ months without clearing state.
Check database sizes: ls -la ~/.codex/.sqlite
Observe auto-restart loop in the Desktop App once the databases exceed ~500 MB combined.
What is the expected behavior?
The app should either:
Periodically run VACUUM after retention-policy pruning, or
Warn the user when databases exceed a threshold (e.g., 200 MB), or
Run an incremental VACUUM at startup if the database is over a threshold.
Additional information
No VACUUM is triggered. The databases grow indefinitely. The app enters an auto-restart loop with cache duplicate-write errors visible in logs at %LOCALAPPDATA%\Packages\OpenAI.Codex_*\LocalCache\Local\Codex\Logs\.
5 Comments
In that case, it would be better to set the default to 200 MB and then include an option to customize the size.
First step here: https://github.com/openai/codex/pull/16330
Can I have the exact state of both DBs please?
state_5.sqlite
File size: 682 MB
Threads: 309
Log entries: ~694,000 rows (displayed as "694K" in diagnostic output)
spawn_edges: 12 total — 9 with status='open' (orphaned)
WAL file: state_5.sqlite-wal present (uncommitted transactions)
logs_1.sqlite
File size: 1.4 GB
Log entries: ~256,000 rows (displayed as "256K" in diagnostic output)
WAL file: logs_1.sqlite-wal = 11 MB (uncommitted transactions)
SHM file: logs_1.sqlite-shm present
Files have since been deleted during recovery; exact row counts not preserved.
Perfect thanks
The incremental vaccum will help
I'll make sure the logs of the
state_dbget dropped