Skip to content

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

Open
Open
Excessive TRACE logging causes logs_2.sqlite/WAL growth and SSD write pressure#29674
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

Description

@komoblack-ship-it
komoblack-ship-it
opened on Jun 23, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    performance
    on Jun 23, 2026

  2. github-actions commented on Jun 23, 2026

    @github-actions
    github-actionsBot
    on Jun 23, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Yassycodes commented on Jun 25, 2026

    @Yassycodes
    Yassycodes
    on Jun 25, 2026 – with ChatGPT Codex Connector

    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: #29949 (comment)

    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.

  4. denispol commented on Jun 25, 2026

    @denispol
    denispol
    on Jun 25, 2026

    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

  5. nintendomustdie commented on Jun 30, 2026

    @nintendomustdie
    nintendomustdie
    on Jun 30, 2026 – with ChatGPT Codex Connector

    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.

  6. masteryyh commented on Jul 10, 2026

    @masteryyh
    masteryyh
    on Jul 10, 2026

    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

  7. peaceroad
    added a commit that references this issue on Jul 26, 2026

    fix: add workaround for Codex TRACE log growth

    ec6676d

  8. jjlin90 commented on Sep 15, 2026

    @jjlin90
    jjlin90
    on Sep 15, 2026

    Confirmed still reproducible on the current Windows Desktop build after updating and restarting.

    Environment

    • OS: Windows x64
    • Desktop package: OpenAI.Codex_26.908.9136.0_x64
    • Bundled CLI: codex-cli 0.154.0-alpha.6.2
    • Effective RUST_LOG in the running Codex process: warn
    • Database: %USERPROFILE%\.codex\logs_2.sqlite
    • Database size before the sample: 107,417,600 bytes

    Controlled reproduction

    I had a local BEFORE INSERT safety trigger installed as a workaround. For this test I temporarily removed it, sampled normal active Codex use for 45 seconds, then restored the trigger and truncated the WAL.

    Aggregate results for the 45-second unblocked window:

    Metric Before After Delta
    MAX(id) 535,947 536,174 +227
    Retained rows 55,554 55,780 +226
    WAL bytes 0 803,432 +803,432

    New rows by level, selected by id > 535947:

    • TRACE: 131
    • INFO: 73
    • DEBUG: 21
    • WARN: 2

    Dominant targets:

    • codex_app_server::outgoing_message: 77
    • codex_app_server::message_processor: 47
    • feedback_tags: 16
    • codex_core::stream_events_utils: 14
    • codex_models_manager::cache: 12
    • codex_http_client::custom_ca: 11
    • codex_models_manager::manager: 11

    This is about 5 new log IDs/second during an ordinary active task. The workload was not a stress test.

    A/B confirmation and cleanup

    After restoring the insert-blocking trigger:

    • PRAGMA wal_checkpoint(TRUNCATE) returned (0, 0, 0).
    • A subsequent 10-second verification showed MAX(id) delta 0, retained-row delta 0, and WAL-byte delta 0.

    This continues to isolate the persistent logs INSERT path as the source of the WAL churn. No raw log bodies or database files are attached because they may contain private conversation text, local paths, tool output, or protocol payloads.

    The earlier changes that limited TUI streaming traces, increased SQLite sink batching, and prevented SQLx-warning feedback loops appear not to cover this current Windows app-server path. It would still be valuable for the SQLite sink to honor the effective log level, or to expose a documented persisted-log-level/disable setting with bounded retention and WAL maintenance.

  9. Husienvora commented on Sep 23, 2026

    @Husienvora
    Husienvora
    on Sep 23, 2026

    Adding a different failure mode from the same write pattern

    My drive (1 TB XPG S70 Blade, InnoGrit IG5236) corrupted Windows twice in a month while running Codex with subagents. SMART: 2% used, 99% spare, never above thermal warning, full surface write/read test clean. But Media and Data Integrity Errors = 37 and it always failed at the next boot, never mid-session. That is FTL/mapping-table corruption from many concurrent small synchronous writes, not NAND wear. A secure erase fixes it for a few days because it rebuilds the map, then it comes back.

    So the TRACE churn is not only a TBW cost. On some controllers it corrupts the drive's own metadata, and the endurance counters never show it.

    Windows workaround until there is a log level setting: move .codex off the OS drive with a junction. The app sees the same path.

    robocopy %USERPROFILE%.codex E:\agents.codex /E /MOVE
    mklink /J %USERPROFILE%.codex E:\agents.codex

    Do it with Codex closed. Full write-up with the SMART data and what I ruled out:
    https://husiensvora.substack.com/p/are-ai-agents-killing-your-ssd

    If anyone here has a non-zero Media and Data Integrity Errors count, I would like to know the controller.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions