macOS: Persistent SQLite TRACE log churn still occurs after restart on Codex Desktop 26.616.71553 / CLI 0.142.0

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=log should not remain the dominant persisted SQLite source after #29457.
• codex_api::sse::responses and low-level websocket/tungstenite TRACE rows should not continue to generate insert-and-prune churn during normal use.
• COUNT(*) should not remain nearly stable while MAX(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

• #28224
• #29432
• #29457
• #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.