High-frequency TRACE writes to logs_2.sqlite after restart

[Alexin12]

High-frequency TRACE writes to logs_2.sqlite after restart

Summary

Codex Desktop / bundled CLI appears to keep writing high-volume TRACE logs into ~/.codex/logs_2.sqlite even after updating to the latest available version and fully restarting Codex.

The database seems bounded in row count, but max(id) continues growing quickly. This suggests logs are being inserted and cleaned up, while the SQLite file remains large.

Environment

• OS: macOS
• Codex Desktop bundled CLI: codex-cli 0.142.5
• Shell CLI: codex-cli 0.142.5
• RUST_LOG=warn
• No explicit log_dir, sqlite_home, or otel.trace_exporter setting was found in the user config.

Observed files

~/.codex/logs_2.sqlite      300 MB
~/.codex/logs_2.sqlite-wal  7.2 MB
~/.codex/logs_2.sqlite-shm  32 KB

After restart, one codex process was holding the SQLite database, WAL, and SHM files.

Full log level distribution

level  rows   row_pct  bytes     byte_pct
TRACE  43182  77.77    89915842  81.95
DEBUG  6087   10.96    11960577  10.90
INFO   5429   9.78     7085846   6.46
WARN   821    1.48     750028    0.68
ERROR  3      0.01     4336      0.00

Top log targets by estimated bytes

target                                    level  rows   bytes
codex_api::endpoint::responses_websocket  TRACE  1225   55711004
codex_api::sse::responses                 TRACE  18541  19431739
codex_core::stream_events_utils           DEBUG  3373   7969060
log                                       TRACE  15680  7913711
codex_mcp::connection_manager             TRACE  5016   4429031
codex_core::session::handlers             DEBUG  740    3027763
feedback_tags                             INFO   1467   2161344
codex_core::stream_events_utils           INFO   857    1359595
codex_otel.log_only                       INFO   815    1144788
codex_otel.trace_safe                     INFO   812    1065326
rmcp::service                             TRACE  43     758364
codex_core::session::turn                 TRACE  662    601855

Recent write-rate sample after restart

Recent one-minute distribution:

TRACE  1040 rows  134565 bytes
INFO   10 rows    7544 bytes
DEBUG  5 rows     10346 bytes
WARN   1 row      1036 bytes

Ten-second max(id) sample after a full Codex restart:

before max_id=35584404, rows=55490
after  max_id=35584680, rows=55494

That is about 276 new IDs over 10 seconds, or about 27.6 IDs/second. The row count increased by only 4, which suggests ongoing insertion plus cleanup.

The WAL file size did not grow during this 10-second sample, but the database was still being written to.

Expected behavior

With RUST_LOG=warn and no explicit debug/trace logging configuration, Codex should not continuously write high-volume TRACE logs to local SQLite storage during normal idle or light interactive use.

If this is expected bounded diagnostic behavior, please document:

• what logs_2.sqlite stores,
• why TRACE entries are persisted even when RUST_LOG=warn,
• the retention policy,
• whether the SQLite file is expected to remain large after cleanup,
• and whether users can safely compact or relocate this store.

Actual behavior

TRACE entries dominate both row count and estimated bytes, mostly from codex_api::endpoint::responses_websocket, codex_api::sse::responses, log, and codex_mcp::connection_manager.

Why this matters

The behavior creates continuous local disk writes and leaves a large SQLite database under ~/.codex. Users are concerned about unnecessary disk I/O, SSD write amplification, and local storage growth.

Request

Please confirm whether this is expected behavior in Codex Desktop / CLI 0.142.5. If not expected, please reduce default TRACE persistence or provide an official setting/maintenance command to disable, bound, relocate, or compact this SQLite diagnostic store safely.

[github-actions]

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

• Codex Desktop app-server writes high-volume TRACE rows to logs_2.sqlite despite RUST_LOG=warn and analytics disabled #30988
• High-frequency TRACE rows are still written to logs_2.sqlite with RUST_LOG=warn #30780
• Codex desktop writes high-frequency TRACE logs to ~/.codex/logs_2.sqlite despite RUST_LOG=warn #31111
• Codex App writes high-volume TRACE logs to logs_2.sqlite despite RUST_LOG=warn #30236
• Codex Desktop 26.623.3763.0 still persists high-frequency target=log TRACE rows to logs_2.sqlite after #29457 #30162

Powered by Codex Action

[mayank6091]

@Alexin12 One challenge with verbose tracing is distinguishing operational logs from execution-level insights. Recording every event is valuable, but the data becomes much more useful when it's organized around a single execution timeline rather than scattered across individual log entries.