›_ Codex Issues
Codex Issues / #24275

Codex Desktop rapidly grows logs_2.sqlite / WAL during normal active use

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

Summary

Codex Desktop rapidly grew ~/.codex/logs_2.sqlite and ~/.codex/logs_2.sqlite-wal during a normal active session. The growth was visible over only a few minutes and coincided with noticeable UI slowdown.

This looks related to #21134, #20213, and #19109, but I am filing this with fresh data from codex-cli 0.133.0-alpha.1.

Environment

  • Codex Desktop on macOS
  • codex-cli 0.133.0-alpha.1
  • macOS 15.7.4 / build 24G517
  • Default $CODEX_HOME: ~/.codex

Observed behavior

During an active Codex Desktop conversation, Finder showed:

  • around 00:10: logs_2.sqlite-wal was already about 63.4 MB
  • around 00:12: logs_2.sqlite-wal was about 146.6 MB, and logs_2.sqlite was about 131.2 MB

A later check while Codex was still running showed:

logs_2.sqlite      125M
logs_2.sqlite-shm  288K
logs_2.sqlite-wal  140M

SQLite-level data at the same time looked much smaller than the on-disk files:

rows: 2086
sum(estimated_bytes): 2404625
min ts: 2026-05-23 22:01:45
max ts: 2026-05-23 22:16:44

Top log targets by estimated bytes:

codex_api::endpoint::responses_websocket | 283 | 1196752
codex_otel.log_only                      | 290 | 408871
codex_otel.trace_safe                    | 287 | 376671
codex_api::sse::responses                | 49  | 134714
log                                      | 710 | 79236
codex_core::stream_events_utils          | 33  | 51749
hyper_util::client::legacy::pool         | 131 | 32141
codex_core_skills::loader                | 48  | 32016

lsof showed several Codex processes holding the same logs_2.sqlite files open, including the Desktop app-server and several stdio app-server processes spawned under node_repl:

codex app-server --analytics-default-enabled
codex app-server --listen stdio://
codex app-server --listen stdio://
codex app-server --listen stdio://

RUST_LOG for the processes was already warn, so this does not appear to be caused by a locally enabled verbose logging env var.

Expected behavior

The local diagnostic log DB should not grow by hundreds of MB within a few minutes of normal use, especially when the logical estimated_bytes stored in logs is only a few MB.

The log sink should also not materially degrade Codex Desktop responsiveness.

Impact

The app became slower while the log DB/WAL grew quickly. Users may need to fully quit Codex and manually clear or rotate logs_2.sqlite* to recover disk space and responsiveness.

Suggested direction

The data points to the same general area as the linked issues:

  • bound or disable high-volume websocket/SSE/OTel trace logging by default
  • ensure WAL checkpoint/truncation works under normal Desktop multi-process usage
  • avoid shared-log SQLite contention across multiple app-server processes
  • make local log retention/rotation configurable or automatic

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #23725

Powered by Codex Action

interfector18 · 1 month ago

I think this is part of the bug that caused about 30 TB of ssd write churn on my system, codex itself wrote 7 GB in 10 minutes from a quick iotop test, while the files themselves didn't get bigger than ~200MB

martinmclee · 28 days ago

Testing with empty proxy.

martinmclee · 28 days ago

I can confirm this affects my setup too.

Environment: Windows 11, %USERPROFILE% = C:\Users\User, codex CLI 0.142.0.

I captured state from C:\Users\User\.codex today:

  • logs_2.sqlite: 6,542.19 MB
  • logs_2.sqlite-wal: 101.82 MB
  • logs rows: 93,757 with high verbose logging volume (TRACE and DEBUG present; many internal targets).
  • session/archived_session activity is ongoing (several GB under .codex/sessions and .codex/archived_sessions).

CrystalDiskInfo snapshot (CrystalDiskInfo_20260623102934.txt) shows:

  • Host writes: 32,220 GB, reads 35,467 GB
  • Health Status: Good (92%)
  • Percentage Used: 8%
  • no media/data integrity errors
  • no unsafe shutdowns

So this looks like the same app-level logging/WAL churn bug pattern (not clear SSD failure).

I also confirmed this workaround from issue discussions is available in my setup:
CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;
(does not delete any sessions/log history, just blocks new log inserts).

Please confirm if any additional local traces would help.

RoyalBis · 24 days ago

I can confirm as well:

Platform:
Ubuntu Linux

Problem:
~/.codex/logs_2.sqlite-wal grew to 108G and filled the root filesystem.

Evidence:
df -h showed / at 100%:
/dev/mapper/ubuntu--vg-ubuntu--lv 155G 149G 0 100% /

/workspace is a separate filesystem and was not full:
/dev/sdb 157G 32G 117G 22% /workspace

du showed /home was the source:
136G /home
108G /home/ubuntu/.codex

Top-level ~/.codex files:
108G logs_2.sqlite-wal
214M logs_2.sqlite-shm
169M logs_2.sqlite

Impact:
Root filesystem filled completely, causing ENOSPC risk for unrelated system services.

Expected:
Codex log storage should be bounded, rotated, checkpointed, or configurable so it cannot consume the entire root filesystem.

Actual:
A SQLite WAL file under ~/.codex grew to 108G.

codex-cli 0.142.2

runminglu · 4 days ago

Additional sanitized data from macOS 26.4 (25E246), arm64:

  • current bundled binary: codex-cli 0.144.5
  • ChatGPT desktop bundle: 26.707.91948 (build 5440)
  • ~/.codex/logs_2.sqlite: 684,650,496 bytes (about 653 MiB)
  • ~/.codex/logs_2.sqlite-wal: 6,254,192 bytes
  • observed log timestamp range: 2026-07-08 through 2026-07-16
  • no log_dir or otel override in ~/.codex/config.toml

SQLite contents:

rows:                 385,575
sum(estimated_bytes): 412,815,435

TRACE  244,323 rows  214,758,911 estimated bytes
DEBUG   66,759 rows  104,008,096 estimated bytes
INFO    62,880 rows   86,134,648 estimated bytes
WARN    11,563 rows    7,890,828 estimated bytes
ERROR       50 rows       28,881 estimated bytes

TRACE + DEBUG are about 80.7% of all rows and 77.2% of logical log bytes.

Largest targets by estimated bytes:

codex_core::stream_events_utils  116,080,464
codex_mcp::connection_manager    100,295,674
codex_api::sse::responses         61,130,013
feedback_tags                     39,703,398
rmcp::service                     25,318,447
codex_core::tools::parallel       15,110,837
codex_core::session::turn         12,218,393

This is not currently a giant WAL case—the WAL has checkpointed down to about 6 MiB—but the main diagnostic database remains 653 MiB after roughly eight days, with most retained data at TRACE/DEBUG. This indicates that the high-volume persistent logging/retention behavior is still present in the 0.144.5 generation.