Windows Codex app updated to 26.616.10790.0, but continuous disk writes persist and appear worse.

[Bobboom0921]

Windows Codex app updated to 26.616.10790.0, but continuous disk writes persist and appear worse.

Measured with Windows PerfProc counters while not performing other actions:

• Total Codex process writes average ~5284 KB/s over 50 seconds
• Projected ~435 GB/day, ~12.8 TB/month if sustained
• Main writer: Codex#5 / PID 2884, usually ~4.8-5.8 MB/s
• Hot files recently modified: ~/.codex/logs_2.sqlite, ~/.codex/logs_2.sqlite-wal, ~/.codex/state_5.sqlite-wal, session rollout jsonl, sandbox log

Previous version was 26.609.4994.0; updated version is 26.616.10790.0.
Please investigate excessive local logging / SQLite WAL writes or provide a way to disable or reduce local log persistence.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Windows app-server writes excessive TRACE logs to logs_2.sqlite WAL #29799
• Codex Windows app-server writes excessive TRACE logs to logs_2.sqlite WAL #29798
• Windows Codex app continuously writes high-volume TRACE websocket logs to ~/.codex/logs_2.sqlite despite RUST_LOG=warn #29463
• Windows Desktop 26.616.9593.0 still shows persistent SQLite log churn after rust-v0.142.0 fix #29570
• Excessive TRACE logging causes logs_2.sqlite/WAL growth and SSD write pressure #29674

Powered by Codex Action

[Yassycodes]

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855. My case started with a large logs_2.sqlite / WAL problem too, but even after rotating logs and reproducing with small fresh logs, Codex Desktop still caused intermittent mouse/typing/system input lag on Windows.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: #29949 (comment)

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows performance issues look related enough that they may need a canonical tracker.