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

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