VS Code session still causes residual logs_2.sqlite churn on Windows after killing Desktop app and purging known noisy targets

Summary

I can still reproduce persistent local SQLite log churn on Windows in a live Codex / VS Code session after applying the mitigations discussed in recent issues and PRs.

This is related to:

• #28224
• #29463
• #29556
• #29570
• #29432
• #29457

The difference in my case is that I did not only do a read-only check. I also tried local stopgap mitigation:

1. fully stop the Windows Store Codex Desktop app processes
2. delete the known noisy targets from ~/.codex/logs_2.sqlite
3. run PRAGMA wal_checkpoint(TRUNCATE)
4. run VACUUM

Even after that cleanup, the active VS Code Codex session still keeps inserting/pruning rows and touching the SQLite/WAL files.

Environment

• Date observed: June 23, 2026
• OS: Windows x64
• Codex CLI runtime: codex-cli 0.142.0-alpha.6
• VS Code runtime path reported by codex doctor:
• c:\Users\qet63\.vscode\extensions\openai.chatgpt-26.616.51431-win32-x64\bin\windows-x86_64\codex.exe
• Windows Store Codex app processes were present earlier and then explicitly stopped before the final measurement

Before cleanup

The local DB matched the same noisy categories already reported elsewhere.

Top target + level pairs before cleanup:

• codex_otel.log_only / INFO = 23,383
• codex_otel.trace_safe / INFO = 23,351
• codex_api::endpoint::responses_websocket / TRACE = 22,248
• log / TRACE = 19,209
• codex_api::sse::responses / TRACE = 2,010

Recent retained rows also still included websocket / tungstenite-style target=log bodies such as:

• WouldBlock
• Read.with_context read -> poll_read
• WebSocketStream.with_context
• raw Received message { ... } payload lines

Cleanup I performed

I then deleted these targets from the local SQLite DB:

• log
• codex_otel.log_only
• codex_otel.trace_safe
• codex_api::endpoint::responses_websocket
• codex_api::sse::responses

After that I ran:

• PRAGMA wal_checkpoint(TRUNCATE)
• VACUUM

This reduced the main DB size from 509,677,568 bytes to 64,753,664 bytes.

Residual issue after cleanup

Even after the cleanup above, I still see ongoing insert/prune churn.

15-second sample after cleanup:

• COUNT(*): 29,342 -> 29,543 (+201)
• TRACE rows: 15,282 -> 15,343 (+61)
• MAX(id): 34,575,599 -> 34,577,067 (+1,468 in 15s)

That is still persistent churn rather than a settled state.

Current top retained target + level after cleanup:

• hyper_util::client::legacy::pool / TRACE = 5,781
• hyper_util::client::legacy::client / TRACE = 3,562
• hyper_util::client::legacy::connect::http / DEBUG = 2,370
• codex_client::custom_ca / INFO = 1,619
• codex_app_server::message_processor / TRACE = 1,534
• hyper_util::client::legacy::connect::http / TRACE = 1,349
• codex_core::stream_events_utils / DEBUG = 1,330
• log / TRACE = 944

File state observed after cleanup:

• logs_2.sqlite = 64,753,664 bytes
• logs_2.sqlite-wal = 63,406,832 bytes
• both files continue receiving updated modification timestamps during active use

Why this seems important

This suggests that the recent fixes reduced the worst offenders, but the Windows / VS Code path may still retain enough TRACE / DEBUG churn to keep writing continuously to logs_2.sqlite and logs_2.sqlite-wal.

So the current state looks more like:

• problem reduced significantly
• but not fully resolved
• residual dependency / transport / app-server traces still persist into the SQLite sink

Expected behavior

After the fixes in rust-v0.142.0, and especially after the known noisy targets are filtered, I would expect one of the following:

• the persistent SQLite sink stops recording these residual transport-level TRACE events by default
• or there is a documented config option to disable / sharply reduce local persistent TRACE logging
• or at minimum the WAL should stop showing this level of ongoing insert/prune churn during ordinary interactive use

Notes

I am not attaching the database because it may contain private local diagnostic / conversation data.

If helpful, I can provide a sanitized breakdown of additional target categories that continue to appear after the known-noisy targets are removed.