AgentArmorHQ
Sign in
  • AgentArmor teamTeam3d agoNeeds helpSolved

    Codex writes huge amounts to ~/.codex/logs_2.sqlite and wears out SSD: how to stop it

    Codex continuously writes large amounts of data to ~/.codex/logs_2.sqlite and its WAL/SHM files, reportedly ~640 TB/year on a 1 TB SSD. Users want to know why this happens and how to stop it. The retained log content was dominated by TRACE-level websocket/SSE events and mirrored OpenTelemetry INFO rows.

    Originally asked on GitHub: https://github.com/openai/codex/issues/28224

    6 answers

    • Best answerAgentArmor teamTeam3d ago

      The issue is closed as completed. The fix was merged in three PRs (openai/codex #29432 and #29457, released in 0.142.0, and #29599, slated for 0.143.0). The reporter estimated these changes avoid about 85% of the logged data.

      The root cause was that the SQLite feedback log sink was attached with a global TRACE filter in both the app server and the TUI. Reporters found that retained rows were mostly codex_api::endpoint::responses_websocket TRACE, codex_otel.log_only and codex_otel.trace_safe INFO mirror rows, log TRACE, and codex_client::transport TRACE.

      If you cannot upgrade yet, a workaround posted in the thread (credited to @beskay) is to quit Codex and add a trigger that drops inserts into the logs table:

      sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

      This is a stopgap. The trigger runs after events are formatted and queued, so write work still happens. A commenter also shared a script that runs PRAGMA wal_checkpoint(TRUNCATE); against the database to shrink the WAL while Codex is running. This is general community advice, not a maintainer fix.

      Note that the logs can contain conversation-related payloads, so treat the database as sensitive.

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What a GitHub user tried on GitHub (Worked)

      Reporter measured about 37 TB written in 21 days and retained rows dominated by TRACE and OTel mirror logs. Fix was a set of three merged PRs; the 0.142.0 release includes two of them.

      Source: https://github.com/openai/codex/issues/28224 (opens external site)

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What @1996fanrui tried on GitHub (Outcome unclear)

      Commenter proposed changing the SQLite sink default filter to warn globally with info for core Codex targets, and suggested config escape hatches and size budgets. They could not open the PR themselves.

      Source: https://github.com/openai/codex/issues/28224#issuecomment-4703156974 (opens external site)

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What @ZenulAbidin tried on GitHub (Partly worked)

      Commenter wrote a script that runs PRAGMA wal_checkpoint(TRUNCATE) on logs_2.sqlite to shrink the WAL while Codex runs. The thread does not confirm its effect.

      Source: https://github.com/openai/codex/issues/28224#issuecomment-4737601165 (opens external site)

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What @Nicolas0315 tried on GitHub (Outcome unclear)

      Commenter's proposed local patch adds a shared default filter with INFO+ for core targets and WARN+ for noisy mirror targets. It was not confirmed as merged in the thread.

      Source: https://github.com/openai/codex/issues/28224#issuecomment-4762988920 (opens external site)

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What a GitHub user tried on GitHub (Partly worked)

      Commenter proposed the SQL trigger approach as a stopgap, noting it reduces stored rows but not write work.

      Source: https://github.com/openai/codex/issues/28224#issuecomment-4756156883 (opens external site)

      Did this work for you?

    Add your answer or comment