›_ Codex Issues
Codex Issues / #29674

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

Open 💬 5 comments Opened Jun 23, 2026 by komoblack-ship-it
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #29463
  • #29570
  • #29589
  • #28224
  • #29556

Powered by Codex Action

Yassycodes · 2 months ago

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855. My case started with a large logs_2.sqlite / WAL problem too, but even after rotating logs and reproducing with small fresh logs, Codex Desktop still caused intermittent mouse/typing/system input lag on Windows.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows performance issues look related enough that they may need a canonical tracker.

denispol · 2 months ago

Addressed by lowering the default persisted level to INFO (TRACE/DEBUG no longer persisted by default), configurable via [log] level / CODEX_LOG_DB_LEVEL: https://github.com/denispol/codex/pull/1

nintendomustdie · 1 month ago

I can still reproduce the high-churn logging pattern on Windows Codex Desktop after updating to a newer app package.

Environment:

  • OS: Windows
  • Codex Desktop package: OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0
  • Database checked read-only via: file:C:/Users/<user>/.codex/logs_2.sqlite?mode=ro
  • SQLite CLI: 3.53.3 2026-06-26

Current database summary:

rows = 67025
min(id) = 19983079
max(id) = 30429972
journal_mode = wal

Level distribution:

TRACE  53953 rows  105.9 MiB
INFO    4909 rows    5.3 MiB
DEBUG   7515 rows    4.4 MiB
WARN     661 rows    0.3 MiB
ERROR     49 rows    0.1 MiB

15-second read-only sample:

before_id=30429972
before_count=67025
after_id=30465346
after_count=67087
id_delta=35374
count_delta=62

That still looks like continuous insert/prune churn: MAX(id) advances very quickly while the retained row count changes only slightly.

Rows retained from that sampling window were still mostly stream/TRACE-related:

codex_api::sse::responses                 TRACE    48 rows   48.2 KiB
codex_core::stream_events_utils           DEBUG     8 rows   11.9 KiB
feedback_tags                             INFO      2 rows    3.0 KiB
codex_api::endpoint::responses_websocket  TRACE     1 row   292.1 KiB
codex_core::stream_events_utils           INFO      1 row     1.0 KiB
codex_core::session::turn                 TRACE     1 row     0.9 KiB
codex_core::client                        TRACE     1 row     0.9 KiB

So at least on this Windows Desktop build, the issue does not appear fully resolved yet. The WAL did not grow during this short sample, but the database was still being written to at a high rate while old rows were being pruned.

masteryyh · 1 month ago

Is there any chance to change log level or disable trace logging? This problem still exists even after ChatGPT App released to replace original Codex App