high-frequency SQLite/WAL writes dominated by TRACE logs

What version of Codex CLI is running?

codex cli 0.146.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Windows

What terminal emulator and version are you using (if applicable)?

Powershell 7

Codex doctor report

What issue are you seeing?

es, there are high-frequency SQLite/WAL writes dominated by TRACE logs during the current Codex session, but it is not non-stop continuous writing 24 hours a day.

Detection time: 2026-08-05 09:52-09:55

Database: ~/.codex/logs_2.sqlite

Main DB size: 713.5 MiB

WAL size: 5.13 MiB

Log sequence number reached: 9,453,772

Within a continuous 20 seconds: 1684 TRACE entries, averaging 84.2 entries/sec

Single-second peak: 276 TRACE entries

TRACE accounts for approx: 99.2% of the logs in this window

WAL modification time changed 9 times within 15.6 seconds

Two codex.exe processes combined for approx. 6.95 MiB of write I/O and 5759 write operations in 20.7 seconds

Main sources: codex_api::sse::responses, codex_app_server::outgoing_message

The WAL size is not growing because it is currently overwriting in a circular manner within a fixed size, which does not mean there are no writes.

In the past 24 hours, there were about 15,131 TRACE entries, but they are distributed across only 734 active seconds, and there are long gaps during the night. Therefore, the accurate conclusion is: there is continuous high-frequency writing during Codex activity or streaming output responses, but it is not 24/7 continuous writing when idle.

Additionally, no explicit RUST_LOG=trace or log level configuration was found in config.toml, the current process environment, or the user/system environments. This looks more like the current Codex internal diagnostic database defaults to recording TRACE, rather than it being enabled by user configuration.

The database also has about 180.5 MiB of free pages, indicating significant un-reclaimed space in the current 713.5 MiB file. This detection was completely read-only, and neither the database nor the configuration was modified.

What steps can reproduce the bug?

use Codex for a long time >1 weeks
then its will auto reproduce this bug again

What is the expected behavior?

_No response_

Additional information

_No response_