Codex Desktop 26.623.3763.0 still persists high-frequency target=log TRACE rows to logs_2.sqlite after #29457

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.623.3763.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows x64

What issue are you seeing?

Codex Desktop still persists high-frequency target=log TRACE rows to ~/.codex/logs_2.sqlite while the app-server is idle, even after the persistent-log filtering work in #29457.

Environment:

• OS: Windows x64
• Codex Desktop package: OpenAI.Codex_26.623.3763.0_x64__2p2nqsd0c76g0
• Writer process:
• ...\app\resources\codex.exe app-server --analytics-default-enabled
• Database:
• ~/.codex/logs_2.sqlite
• WAL mode with logs_2.sqlite-wal and logs_2.sqlite-shm

Read-only idle test:

• Duration: 120 seconds
• No destructive actions were performed.
• The database was opened read-only through Python sqlite3 using mode=ro.
• No trigger was created.
• No VACUUM/checkpoint was run.
• No files were deleted, renamed, moved, or modified by the test.

Observed result:

start: 2026-06-26 10:21:16
end:   2026-06-26 10:23:16

seq:   229351948 -> 229353400   delta +1452
rows:  83334     -> 83334       delta +0

id range start: 207879401 .. 229351948
id range end:   207879401 .. 229353400
new retained rows after start max(id): 1004

File sizes during the same 120-second window:

logs_2.sqlite      803586048 -> 803586048   delta 0, mtime_delta 24.254s
logs_2.sqlite-wal  187208712 -> 187208712   delta 0, mtime_delta 117.735s
logs_2.sqlite-shm      32768 ->     32768   delta 0

New rows by level:

TRACE 995
DEBUG 6
INFO  3

Top new targets:

984 target=log
6   hyper_util::client::legacy::pool
3   hyper_util::client::legacy::connect::http
3   hyper_util::client::legacy::client
2   codex_api::sse::responses
1   feedback_tags
1   codex_core::stream_events_utils
1   codex_core::spawn
1   codex_client::transport
1   codex_client::default_client
1   codex_client::custom_ca

All new retained rows came from this process UUID:

pid:16600:8a302128-bd94-4942-9875-13c0d6f0e0ac

The process was confirmed as:

ProcessId: 16600
CommandLine: "C:\Program Files\WindowsApps\OpenAI.Codex_26.623.3763.0_x64__2p2nqsd0c76g0\app\resources\codex.exe" app-server --analytics-default-enabled
ExecutablePath: C:\Program Files\WindowsApps\OpenAI.Codex_26.623.3763.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Representative latest rows were still websocket/tungstenite-style TRACE noise, for example:

TRACE | log | WouldBlock
TRACE | log | tokio-tungstenite ... compat.rs:157 Read.with_context
TRACE | log | tokio-tungstenite ... compat.rs:154 Read.read
TRACE | log | tokio-tungstenite ... compat.rs:183 Write.flush
TRACE | log | writing frame <FRAME> ... opcode: PONG
TRACE | log | Sending frame: Frame { ... opcode: Control(Pong) ... }

What steps can reproduce the bug?

1. Start Codex Desktop 26.623.3763.0 on Windows.
2. Leave the app-server idle for approximately 120 seconds.
3. In another process, open ~/.codex/logs_2.sqlite in read-only mode.
4. Record sqlite_sequence.seq, COUNT(*), MAX(id), WAL file mtime, and the delta rows where id > <start_max_id>.
5. Observe that seq / MAX(id) continues to increase and newly retained rows are dominated by target=log / TRACE.

What is the expected behavior?

After #29457, target=log should be excluded from the persistent SQLite sink, or production Desktop builds should otherwise avoid persisting high-frequency websocket/tungstenite TRACE logs while idle.

File size alone is not a sufficient signal here: in this test, the main DB and WAL sizes stayed constant, but seq, MAX(id), retained delta rows, and WAL mtime showed continued insert/prune churn.

Additional information

I am not uploading the SQLite database because persistent logs may contain private runtime data. The measurements above were collected using read-only queries and process metadata only.

This appears related to #28224, #29432, #29457, #29570, and #29799, but the important new data point is that the issue is still reproducible on OpenAI.Codex_26.623.3763.0 and still dominated by target=log / TRACE.