High-frequency TRACE rows are still written to logs_2.sqlite with RUST_LOG=warn #30780

Summary

Codex app-server appears to keep writing high-frequency TRACE rows into ~/.codex/logs_2.sqlite even when the running codex app-server process has RUST_LOG=warn in its environment.

I am reporting this because I rely on Codex heavily for daily work and genuinely want to keep using it. Seeing a local SQLite log file receive continuous high-frequency TRACE writes makes me worried about unnecessary SSD wear and makes it harder to feel comfortable leaving Codex open for long sessions.

Environment

• Platform: macOS
• Codex CLI version: codex-cli 0.142.4
• Running server command observed: /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
• Process environment confirmed: RUST_LOG=warn
• SQLite log DB: ~/.codex/logs_2.sqlite

Observed behavior

After setting RUST_LOG=warn via launchctl setenv RUST_LOG warn, fully restarting Codex, and confirming the running codex app-server process environment shows RUST_LOG=warn, ~/.codex/logs_2.sqlite still receives many TRACE rows during normal use.

Recent measurements from my machine:

• A quiet 20-second sample showed about 938 new TRACE rows, around 47 TRACE rows/sec.
• A recent 5-minute query showed 1720 TRACE rows, with about 9653 KB estimated bytes.
• The DB size was observed around 252,268,544 bytes, with WAL around 5,537,312 bytes.
• The TRACE rows include targets / messages related to:
  • log
  • codex_api::sse::responses
  • codex_api::endpoint::responses_websocket
  • tokio-tungstenite WebSocket frame/read/decompress style logs

Example recent TRACE message prefixes included WebSocket frame parsing, read/poll calls, and response/SSE messages. I am not attaching full log bodies because they may contain sensitive session content.

Expected behavior

When RUST_LOG=warn is active for codex app-server, I would expect TRACE-level diagnostic details not to be persisted continuously into the local SQLite log store.

If this SQLite log store is intentionally separate from RUST_LOG, it would be very helpful to have a supported setting to disable TRACE persistence, lower the persisted level, cap retention more aggressively, or move the store to a user-configurable location.

Why this matters

I understand this may not immediately damage an SSD, but the constant write activity is concerning for users who keep Codex open and depend on it for long working sessions. Codex is becoming important to my workflow, so I want to be able to trust that leaving it open is not causing unnecessary disk writes.

Reproduction outline

1. Set RUST_LOG=warn for the macOS user launch environment.
2. Fully restart Codex.
3. Confirm the running codex app-server process has RUST_LOG=warn.
4. Query ~/.codex/logs_2.sqlite for recent rows by level.
5. Observe continued high-frequency TRACE rows during normal active use.

Useful checks:

SELECT level, COUNT(*) AS rows, ROUND(SUM(estimated_bytes)/1024.0, 1) AS estimated_kb
FROM logs
WHERE ts >= strftime('%s','now') - 300
GROUP BY level
ORDER BY rows DESC;

SELECT target, level, COUNT(*) AS rows, ROUND(SUM(estimated_bytes)/1024.0, 1) AS estimated_kb
FROM logs
WHERE ts >= strftime('%s','now') - 300
GROUP BY target, level
ORDER BY rows DESC
LIMIT 20;

Thanks for looking into this. I really like and depend on Codex; I am mainly hoping there can be a way to keep using it confidently without worrying about high-frequency local TRACE writes.