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
Summary
Codex Desktop rapidly grew
~/.codex/logs_2.sqliteand~/.codex/logs_2.sqlite-walduring 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-cli 0.133.0-alpha.115.7.4/ build24G517$CODEX_HOME:~/.codexObserved behavior
During an active Codex Desktop conversation, Finder showed:
00:10:logs_2.sqlite-walwas already about63.4 MB00:12:logs_2.sqlite-walwas about146.6 MB, andlogs_2.sqlitewas about131.2 MBA later check while Codex was still running showed:
SQLite-level data at the same time looked much smaller than the on-disk files:
Top log targets by estimated bytes:
lsofshowed several Codex processes holding the samelogs_2.sqlitefiles open, including the Desktop app-server and several stdio app-server processes spawned undernode_repl:RUST_LOGfor the processes was alreadywarn, 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_bytesstored inlogsis 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: