Summary
Codex app on Windows appears to continuously write high-volume local runtime logs into ~/.codex/logs_2.sqlite / WAL, suspected TRACE or streaming event logging. This caused visible local disk churn and WAL growth during normal Codex desktop usage.
Environment
- OS: Windows, native Codex desktop app
- Codex app package observed locally:
OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
- Codex executable path observed:
C:\Program Files\WindowsApps\OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
- Runtime database:
C:\Users\A\.codex\logs_2.sqlite
- Date observed: 2026-07-05 Asia/Shanghai
Evidence collected
Initial readonly file-size check:
logs_2.sqlite: 61,251,584 bytes, 58.41 MiBlogs_2.sqlite-wal: 3,221,872 bytes, 3.07 MiBlogs_2.sqlite-shm: 32,768 bytes, 0.03 MiB
15 second file-level sampling before mitigation:
logs_2.sqlite: 61,251,584 bytes -> 61,251,584 byteslogs_2.sqlite-wal: 4,132,392 bytes -> 4,132,392 bytes- WAL LastWriteTime advanced during the sample window
After temporary mitigation, file-size check:
logs_2.sqlite: 61,251,584 bytes, 58.41 MiB, LastWrite 2026/7/5 12:11:36logs_2.sqlite-wal: 4,239,512 bytes, 4.04 MiB, LastWrite 2026/7/5 12:12:29logs_2.sqlite-shm: 32,768 bytes, 0.03 MiB, LastWrite 2026/7/5 12:04:27
sqlite3 and lsof were not available in PATH, so detailed level distribution and open-handle inspection were not completed.
Temporary local mitigation applied
A user-confirmed SQLite trigger was added to stop further inserts into logs:
CREATE TRIGGER IF NOT EXISTS block_log_inserts
BEFORE INSERT ON logs
BEGIN
SELECT RAISE(IGNORE);
END;
Readback confirmed:
trigger=('block_log_inserts', 'logs')
This is only a local emergency workaround. It silently drops future local log rows and should not be considered a proper fix.
Expected behavior
Codex should not continuously write high-volume TRACE/streaming-event logs to local SQLite during normal desktop use, or it should expose a documented way to bound, rotate, sample, disable, or lower the verbosity of this runtime log stream.
Actual behavior
The local SQLite runtime log database and WAL showed ongoing write activity and WAL growth. User perceived it as high-frequency disk writes.
Request
Please investigate whether Codex desktop is over-logging TRACE/streaming events into logs_2.sqlite, especially on Windows, and provide an official fix or mitigation that does not require modifying the SQLite schema manually.
Summary
Codex app on Windows appears to continuously write high-volume local runtime logs into
~/.codex/logs_2.sqlite/ WAL, suspected TRACE or streaming event logging. This caused visible local disk churn and WAL growth during normal Codex desktop usage.Environment
OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0C:\Program Files\WindowsApps\OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0\app\resources\codex.exeC:\Users\A\.codex\logs_2.sqliteEvidence collected
Initial readonly file-size check:
logs_2.sqlite: 61,251,584 bytes, 58.41 MiBlogs_2.sqlite-wal: 3,221,872 bytes, 3.07 MiBlogs_2.sqlite-shm: 32,768 bytes, 0.03 MiB15 second file-level sampling before mitigation:
logs_2.sqlite: 61,251,584 bytes -> 61,251,584 byteslogs_2.sqlite-wal: 4,132,392 bytes -> 4,132,392 bytesAfter temporary mitigation, file-size check:
logs_2.sqlite: 61,251,584 bytes, 58.41 MiB, LastWrite 2026/7/5 12:11:36logs_2.sqlite-wal: 4,239,512 bytes, 4.04 MiB, LastWrite 2026/7/5 12:12:29logs_2.sqlite-shm: 32,768 bytes, 0.03 MiB, LastWrite 2026/7/5 12:04:27sqlite3andlsofwere not available in PATH, so detailed level distribution and open-handle inspection were not completed.Temporary local mitigation applied
A user-confirmed SQLite trigger was added to stop further inserts into
logs:Readback confirmed:
This is only a local emergency workaround. It silently drops future local log rows and should not be considered a proper fix.
Expected behavior
Codex should not continuously write high-volume TRACE/streaming-event logs to local SQLite during normal desktop use, or it should expose a documented way to bound, rotate, sample, disable, or lower the verbosity of this runtime log stream.
Actual behavior
The local SQLite runtime log database and WAL showed ongoing write activity and WAL growth. User perceived it as high-frequency disk writes.
Request
Please investigate whether Codex desktop is over-logging TRACE/streaming events into
logs_2.sqlite, especially on Windows, and provide an official fix or mitigation that does not require modifying the SQLite schema manually.