Repository navigation
macOS: Persistent SQLite TRACE log churn still occurs after restart on Codex Desktop 26.616.71553 / CLI 0.142.0 #29612
Description
Summary
After fully restarting Codex Desktop, I can still reproduce persistent SQLite log churn in ~/.codex/logs_2.sqlite on macOS with Codex Desktop 26.616.71553 / CLI 0.142.0.
This appears to be reduced compared with the original high-volume report in #28224, but not fully fixed after the rust-v0.142.0 changes in #29432 and #29457.
The remaining churn is still dominated by persisted TRACE rows, especially target=log and codex_api::sse::responses.
Environment
- Platform: macOS arm64
- Codex Desktop app:
26.616.71553 - Codex app build:
4265 - CLI:
codex-cli 0.142.0 - Active log DB:
~/.codex/logs_2.sqlite~/.codex/logs_2.sqlite-wal~/.codex/logs_2.sqlite-shm
- Test was performed after fully quitting and restarting Codex Desktop.
- No SQLite trigger workaround was installed.
- I used read-only SQLite queries only.
Current DB snapshot after restart
At 2026-06-23 19:11:36 CST:
~/.codex/logs_2.sqlite 213 MB
~/.codex/logs_2.sqlite-wal 5.0 MB
~/.codex/logs_2.sqlite-shm 32 KB
SQLite summary:
retained rows: 28,283
min(id): 18,416,628
max(id): 19,692,779
estimated retained content: 46.33 MiB
newest log timestamp: 2026-06-23 19:11:36 local
Recent persisted targets
Rows retained from the last 5 minutes after restart:
target level rows kib
----------------------------------------- ----- ---- ------
log TRACE 1973 1249.0
codex_api::sse::responses TRACE 340 340.8
codex_mcp::connection_manager TRACE 228 225.1
codex_core::stream_events_utils DEBUG 106 161.9
codex_core::stream_events_utils INFO 41 45.6
feedback_tags INFO 35 48.9
hyper_util::client::legacy::pool TRACE 29 6.7
hyper_util::client::legacy::client TRACE 21 4.9
codex_app_server::outgoing_message TRACE 18 2.9
codex_api::endpoint::responses_websocket TRACE 17 1497.3
The newest retained rows still include low-level websocket/tungstenite TRACE messages such as:
tokio-tungstenite ... WebSocketStream.with_context
tokio-tungstenite ... Stream.poll_next
tokio-tungstenite ... Read.with_context read -> poll_read
Parsed headers [...]
Opcode: Data(Text)
Masked: false
WouldBlock
I am intentionally not pasting raw feedback_log_body payloads beyond sanitized examples because they may contain private conversation, local path, tool, or response data.
30 second read-only sample
After restart, I measured COUNT(*), MAX(id), and file sizes over 30 seconds:
rows: 28,822 -> 28,960 delta +138
max_id: 19,710,785 -> 19,713,965 delta +3,180
db bytes: 221,396,992 -> 221,396,992 delta +0
wal bytes: 5,150,032 -> 5,150,032 delta +0
So Codex inserted approximately 3,180 rows in 30 seconds, about 106 inserts/sec, while only 138 rows were retained. File sizes stayed stable during this short sample, so file size alone hides the ongoing insert-and-prune churn.
Top retained rows from the sampled ID range:
target level rows kib
----------------------------------------- ----- ---- ------
log TRACE 887 1154.9
codex_api::sse::responses TRACE 72 72.0
hyper_util::client::legacy::pool TRACE 28 6.2
hyper_util::client::legacy::client TRACE 24 5.2
codex_mcp::connection_manager TRACE 18 14.7
codex_app_server::outgoing_message TRACE 15 2.4
codex_core::stream_events_utils DEBUG 13 20.9
hyper_util::client::legacy::connect::http DEBUG 12 2.7
log DEBUG 12 0.7
codex_core::stream_events_utils INFO 8 10.1
feedback_tags INFO 8 8.7
codex_client::default_client DEBUG 7 7.9
Expected behavior
After the rust-v0.142.0 persistent-log fixes, Codex should not continue to persist high-frequency TRACE target=log rows or low-level websocket/SSE internals into logs_2.sqlite by default.
In particular:
target=logshould not remain the dominant persisted SQLite source after Filter noisy targets from persistent logs #29457.codex_api::sse::responsesand low-level websocket/tungstenite TRACE rows should not continue to generate insert-and-prune churn during normal use.COUNT(*)should not remain nearly stable whileMAX(id)grows by thousands in seconds.- If this logging is intentional, there should be a supported config flag to disable or reduce persistent SQLite logging.
Actual behavior
The issue is reduced compared with #28224, but still reproducible:
logs_2.sqlite/ WAL file sizes did not grow during the short sample.- However,
MAX(id)continued to advance quickly. - Retained rows stayed comparatively low because rows appear to be inserted and pruned.
- The dominant retained sampled target was still
TRACE target=log. - Recent rows still include low-level websocket/tungstenite TRACE records.
Related
- Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance #28224
- Stop logging every Responses WebSocket event #29432
- Filter noisy targets from persistent logs #29457
- macOS: Persistent SQLite TRACE target=log churn remains after rust-v0.142.0 #29532
This looks very similar to #29532, but I am opening this with a fresh post-restart macOS sample from Codex Desktop 26.616.71553 / CLI 0.142.0.
Activity
github-actions commentedon Jun 23, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
mdbecker commentedon Jun 23, 2026
I can reproduce similar idle SQLite churn on macOS with Codex Desktop
26.616.71553/ bundledcodex-cli 0.142.0.Codex Desktop was open in the background and not being actively used. I normally launch it via the macOS GUI / Spotlight, not from the CLI.
Environment
Running process:
The actual environment of the running app-server process includes:
RUST_LOG=warnI did not intentionally enable trace/debug logging.
SQLite health
The DB appears healthy:
Idle sample
Over a 5-minute idle sample,
sqlite_sequenceadvanced by 2,975 IDs while retained row count stayed flat:File sizes stayed bounded, but the WAL timestamp/size continued updating:
This looks like ongoing insert-then-prune churn: the retained row count is capped, but the app-server is still continuously inserting rows while idle.
Exact sampled ID-window breakdown
Immediately after the 5-minute sample, I queried the exact ID window. Only 1,000 rows from the 2,975 allocated IDs were still retained:
All retained rows from that sampled window belonged to the same app-server process:
I am intentionally not pasting raw
feedback_log_bodyvalues because they may contain private local diagnostic or conversation data.Open DB handles
The Codex app-server process is the process holding the DB/WAL/SHM files:
I did not see deleted
logs_2.sqlite/ WAL / SHM handles held open.Summary
This seems consistent with the remaining post-
0.142.0issue described here:logs_2.sqlitefile size may stay bounded, but the app-server still persists high-frequencyTRACE target=logrows while idle.In my case, the app was idle and the running process had
RUST_LOG=warn, but the DB still showed about9.92inserted IDs/sec with retained rows dominated byTRACE target=log.etraut-openai commentedon Jun 23, 2026
Thanks for reporting. We're using #28224 to track this issue.