Excessive TRACE logging causes logs_2.sqlite/WAL growth and SSD write pressure

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,274
• TRACE rows: 10,624
• sqlite_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_websocket
• codex_api::sse::responses
• hyper_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:

1. Do not persist TRACE logs by default in normal desktop usage.
2. Provide a documented setting/env var to control persisted log level.
3. Add retention/rotation/compaction for logs_2.sqlite.
4. Periodically checkpoint/truncate WAL, or otherwise prevent unbounded WAL growth.
5. 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.