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.
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.