Summary
Codex Desktop appears to write high-frequency TRACE logs into ~/.codex/logs_2.sqlite, causing the SQLite database and WAL file to grow quickly. This can create avoidable SSD write pressure during normal usage.
Environment
- Product: Codex Desktop / local Codex app
- OS: Windows
- Shell: PowerShell
- Log database:
~/.codex/logs_2.sqlite
- SQLite journal mode: WAL
Observed behavior
The local log database had grown to approximately 293 MiB, with an additional WAL file of about 5.3 MiB.
Inspection showed:
logs table row count: 21,274TRACE rows: 10,624sqlite_sequence for logs: ~17.4 million- SQLite free pages: 61,249 pages, roughly 239 MiB
- A
VACUUM INTO estimate reduced the database to about 46 MiB
- Recent rows were overwhelmingly TRACE-level; in one sample, 499 of the latest 500 rows were TRACE
Top TRACE sources by volume included:
codex_api::endpoint::responses_websocketcodex_api::sse::responseshyper_util::client::legacy::*codex_mcp::connection_manager
In a recent minute bucket, TRACE rows were being written hundreds to over a thousand times per minute.
Temporary mitigation used locally
As a local workaround, I backed up the database and added a SQLite trigger to ignore TRACE inserts:
CREATE TRIGGER IF NOT EXISTS codex_suppress_trace_logs
BEFORE INSERT ON logs
WHEN NEW.level = 'TRACE'
BEGIN
SELECT RAISE(IGNORE);
END;
After this, new TRACE rows stopped appearing, and WAL growth dropped significantly. Non-TRACE logs (DEBUG, INFO, WARN) still continued at a much lower rate.
This workaround is not ideal because it depends on the current DB schema/file and may disappear if Codex recreates or migrates the database.
Requested fix
Please consider a product-level fix so users do not need to patch the SQLite database manually:
- Do not persist TRACE logs by default in normal desktop usage.
- Provide a documented setting/env var to control persisted log level.
- Add retention/rotation/compaction for
logs_2.sqlite.
- Periodically checkpoint/truncate WAL, or otherwise prevent unbounded WAL growth.
- Consider avoiding large response/websocket/SSE TRACE payloads in persistent local logs unless explicit diagnostics are enabled.
Why this matters
The current behavior can create unnecessary local disk writes and database growth during ordinary Codex use. On SSDs this raises concern about avoidable write amplification and long-term wear, especially for users who keep Codex running for long sessions.
Summary
Codex Desktop appears to write high-frequency TRACE logs into
~/.codex/logs_2.sqlite, causing the SQLite database and WAL file to grow quickly. This can create avoidable SSD write pressure during normal usage.Environment
~/.codex/logs_2.sqliteObserved behavior
The local log database had grown to approximately 293 MiB, with an additional WAL file of about 5.3 MiB.
Inspection showed:
logstable row count: 21,274TRACErows: 10,624sqlite_sequenceforlogs: ~17.4 millionVACUUM INTOestimate reduced the database to about 46 MiBTop TRACE sources by volume included:
codex_api::endpoint::responses_websocketcodex_api::sse::responseshyper_util::client::legacy::*codex_mcp::connection_managerIn a recent minute bucket, TRACE rows were being written hundreds to over a thousand times per minute.
Temporary mitigation used locally
As a local workaround, I backed up the database and added a SQLite trigger to ignore TRACE inserts:
After this, new TRACE rows stopped appearing, and WAL growth dropped significantly. Non-TRACE logs (
DEBUG,INFO,WARN) still continued at a much lower rate.This workaround is not ideal because it depends on the current DB schema/file and may disappear if Codex recreates or migrates the database.
Requested fix
Please consider a product-level fix so users do not need to patch the SQLite database manually:
logs_2.sqlite.Why this matters
The current behavior can create unnecessary local disk writes and database growth during ordinary Codex use. On SSDs this raises concern about avoidable write amplification and long-term wear, especially for users who keep Codex running for long sessions.