Log level not configurable - logs_2.sqlite grows to 1.4GB with hardcoded TRACE

Open 💬 4 comments Opened Jul 4, 2026 by wu350891451-jpg

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

logs_2.sqlite grows to 1.4GB with TRACE-level logs (66.8% of rows). config.toml has no log_level field, RUST_LOG env var is not read (no from_default_env in binary), [otel] enabled=false doesn't stop local tracing. Only [feedback] max_bytes (undocumented) limits growth via auto-prune. Please expose log level as a configurable option.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

#31111
#30988
#30780
#30322
#30236

Powered by Codex Action

darlingm contributor · 1 month ago

100% agreed. See https://github.com/openai/codex/issues/28224#issuecomment-4869138540 for a workaround to block the writes. Combine with starting over with new sqlite files to reclaim space if that's an issue.

Loong0x00 · 1 month ago

This is still reproducible with codex-cli 0.144.5, and the same persistent TRACE behavior remains in the 0.144.6 source.

Local measurements from a Linux system:

~/.codex/logs_2.sqlite is about 400 MiB.
sqlite_sequence is at ~14.9 million while only ~208k rows are retained, so roughly 14.7 million rows have already been inserted and pruned.
In a 30-second active sample, Codex inserted 131 log rows containing ~803 KiB of payload; 84 TRACE rows accounted for ~759 KiB.
A separate 30-second WAL-index sample observed 1,227 WAL frames (~5.06 MiB) and one WAL reset. At the same activity level, WAL traffic alone extrapolates to ~13.6 GiB/day, before main-database checkpoint and filesystem overhead.
RUST_LOG=off together with --disable sqlite still created and populated logs_2.sqlite (including TRACE rows). The sqlite feature is marked removed/no-op.

The catastrophic WebSocket/OTel flood from #28224 appears fixed, but the remaining hard-coded persistent TRACE sink is still an unnecessary continuous write stream. It also persists prompt/tool/network content without a supported opt-out. Users should not have to patch Codex or move all SQLite-backed state to volatile storage to stop diagnostic TRACE logging. This remains a product bug, not a user configuration problem.

darlingm contributor · 1 month ago

This is still reproducible with codex-cli 0.144.5, and the same persistent TRACE behavior remains in the 0.144.6 source.

Yep, for whatever reason, using up customers' SSD endurance on massive scales when you consider the number of active Codex users hasn't been a high enough priority to issue a 0.144.x fix. With the other issue on this and its history and activity, you have to figure out how to laugh at this situation or join a betting pool for when it'll get released. Or, you'll drive yourself crazy.