Windows Desktop 26.616.9593.0 still shows persistent SQLite log churn after rust-v0.142.0 fix

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

OpenAI.Codex 26.616.9593.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows x64

What issue are you seeing?

I am still observing SQLite persistent-log churn in the Windows Desktop app after updating to OpenAI.Codex 26.616.9593.0.

The issue appears related to the persistent logging problem discussed in:

https://github.com/openai/codex/issues/28224
https://github.com/openai/codex/releases/tag/rust-v0.142.0
https://github.com/openai/codex/pull/29432
https://github.com/openai/codex/pull/29457

According to the rust-v0.142.0 release notes, persistent-log churn should be reduced by removing per-event WebSocket payload logging and filtering duplicated telemetry records. PR #29457 also indicates that noisy persistent-log targets such as target=log, codex_otel.log_only, and codex_otel.trace_safe should be filtered from the SQLite sink.

However, on my Windows Desktop build, read-only validation still shows insert-and-prune churn:

COUNT(*) increases only slightly or stays nearly stable,
but MAX(id) continues to grow rapidly.

This suggests that rows are still being continuously inserted into the SQLite log table and then pruned, which can still cause unnecessary WAL writes and SSD write amplification.

The test was performed in read-only mode. I did not modify the database, did not create triggers, did not run VACUUM/checkpoint, and did not delete or rename any log files.

What steps can reproduce the bug?

Update Codex Desktop to:
OpenAI.Codex 26.616.9593.0
Use a Codex home directory containing the persistent log database:
logs_2.sqlite
logs_2.sqlite-wal
logs_2.sqlite-shm
Start Codex Desktop and keep it running for a few minutes.
Use Python standard library sqlite3 to connect to the SQLite database in read-only mode:
file:D:/codex_data/logs_2.sqlite?mode=ro
PRAGMA query_only = ON
Record the initial values:
SELECT COUNT(*) FROM logs;
SELECT MAX(id) FROM logs;
Wait for approximately 5 minutes while Codex Desktop is running.
Record the values again:
SELECT COUNT(*) FROM logs;
SELECT MAX(id) FROM logs;
Query the newly retained delta rows:
SELECT target, level, COUNT(*)
FROM logs
WHERE id > <start_max_id>
GROUP BY target, level
ORDER BY COUNT(*) DESC
LIMIT 30;

In my Desktop test, the result was:

Codex Desktop version:
OpenAI.Codex 26.616.9593.0

logs_2.sqlite:
347,586,560 -> 347,586,560 bytes
growth: 0 bytes

logs_2.sqlite-wal:
7,321,272 -> 7,321,272 bytes
growth: 0 bytes

logs_2.sqlite-shm:
32,768 -> 32,768 bytes
growth: 0 bytes

COUNT(*):
131,036 -> 131,276
delta: +240

MAX(id):
16,243,300 -> 16,254,163
delta: +10,863
approx. rate: ~2,172.6 ids/min

The newly retained delta rows were still dominated by log / TRACE:

Delta top target/level:
log / TRACE = 978
codex_api::sse::responses / TRACE = 91
codex_mcp::connection_manager / TRACE = 64
codex_api::endpoint::responses_websocket / TRACE = 8

The retained database also still contains historical noisy targets:

TRACE = 87,809
INFO = 32,575
DEBUG = 10,130
WARN = 507
ERROR = 15

Top retained target/level:
log / TRACE = 54,317
codex_otel.log_only / INFO = 14,716
codex_otel.trace_safe / INFO = 14,427
codex_api::endpoint::responses_websocket / TRACE = 13,889

I also tested the VS Code extension openai.chatgpt@26.616.71553 with a similar read-only procedure, and it showed similar behavior:

COUNT(*): 128,204 -> 128,204
MAX(id): 16,173,368 -> 16,180,539
Duration: 3 minutes
MAX(id) delta: +7,171
Approx. rate: ~2,390 ids/min

Delta query for the VS Code extension test:

Query condition: id > 16173368
New retained rows: 1,731
MIN(id): 16,173,390
MAX(id): 16,205,064

Top delta target/level:
log / TRACE = 1,000
codex_api::sse::responses / TRACE = 599
codex_api::endpoint::responses_websocket / TRACE = 7

What is the expected behavior?

After the fix described in rust-v0.142.0, I would expect the Windows Desktop app to no longer show persistent insert-and-prune churn in logs_2.sqlite.

Specifically:

1. COUNT(*) should not stay nearly stable while MAX(id) grows by thousands per minute.
2. Newly retained delta rows should not be dominated by log / TRACE.
3. target=log should not remain the top persistent SQLite log source after #29457.
4. codex_otel.log_only and codex_otel.trace_safe should not continue to be persisted in large numbers.
5. successful WebSocket/SSE event logging should not produce continuous TRACE-level churn.
6. logs_2.sqlite-wal should not be continuously touched or written during light or idle use.

The main expected fixed state is not necessarily “zero logging”, but the persistent SQLite sink should no longer be dominated by the noisy targets that the release notes and PRs describe as filtered.

Additional information

This validation was intentionally read-only and non-destructive:

No trigger was created.
No VACUUM was run.
No checkpoint was run.
No files were deleted, renamed, or moved.
No database writes were performed.
No configuration was modified during the test.

The SQLite database was opened using:

mode=ro
PRAGMA query_only = ON

I am not uploading the SQLite log database because previous discussions suggested that raw WebSocket/SSE payloads or diagnostic records may contain private information.

My current interpretation is:

OpenAI.Codex 26.616.9593.0 does not appear to have the persistent-log churn fix fully applied,
or the fix does not cover the Windows Desktop SQLite sink path.

Could you please confirm:

1. Whether OpenAI.Codex 26.616.9593.0 is expected to include the rust-v0.142.0 persistent-log fixes;
2. Whether target=log / TRACE should still be persisted to logs_2.sqlite after #29457;
3. Whether codex_api::sse::responses / TRACE is expected to remain in the persistent SQLite sink;
4. Whether there is a supported configuration flag to disable or reduce persistent SQLite logging until the Desktop and VS Code extension builds fully include the fix.

At the moment, I am avoiding long-running Codex Desktop and VS Code Codex sessions, and I am not cleaning the old log database because the current builds still appear to generate persistent log churn.