Codex Desktop app-server writes high-volume TRACE rows to logs_2.sqlite despite RUST_LOG=warn and analytics disabled

Open 💬 1 comment Opened Jul 3, 2026 by 54rachelbai-dot

Summary

Codex Desktop's local app-server is continuously writing high-volume TRACE rows into ~/.codex/logs_2.sqlite. This continues after setting [analytics] enabled = false, restarting Codex Desktop, and confirming the app-server process is running with RUST_LOG=warn.

This causes frequent writes and WAL growth in the local SQLite log store. There does not appear to be a documented config/CLI switch to disable or reduce this local SQLite TRACE storage.

Environment

  • Component: Codex Desktop / app-server / local SQLite logs
  • macOS: Apple Silicon (macos-aarch64 as reported by codex doctor)
  • Codex.app: 26.623.101652
  • Codex.app build: 4674
  • CLI: codex-cli 0.142.5
  • Local log DB: ~/.codex/logs_2.sqlite

Configuration tested

User config includes:

[analytics]
enabled = false

After adding this, Codex Desktop was fully restarted.

The current app-server process still starts as:

/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

The process environment includes RUST_LOG=warn.

Evidence

After restart with [analytics] enabled = false, recent local SQLite log counts still show heavy TRACE writes:

Last 60 seconds:
TRACE  1146
DEBUG  20
INFO   19
WARN   6

Top targets over a recent 120-second window:

TRACE  log                                 984
TRACE  codex_api::sse::responses           116
TRACE  codex_mcp::connection_manager       40
TRACE  codex_app_server::outgoing_message  38
DEBUG  codex_core::stream_events_utils     34

A 20-second sampling loop showed this was not just old data or a one-time startup event:

14:08:25 rows_last5s=1252 trace_last5s=1247
14:08:30 rows_last5s=90   trace_last5s=88
14:08:35 rows_last5s=111  trace_last5s=111
14:08:40 rows_last5s=2    trace_last5s=2
14:08:45 rows_last5s=113  trace_last5s=113

The DB had previously grown to about 209 MB with a 14 MB WAL. After deleting old rows, VACUUM, and checkpointing, it shrank to about 4.8 MB, but after restart and continued TRACE writes it quickly grew again to about:

logs_2.sqlite      12.8 MB
logs_2.sqlite-wal   5.3 MB

Steps to reproduce

  1. Use Codex Desktop on macOS.
  2. Add this to ~/.codex/config.toml:

``toml
[analytics]
enabled = false
``

  1. Fully restart Codex Desktop.
  2. Confirm app-server process has RUST_LOG=warn and is using logs_2.sqlite.
  3. Query recent log rows:

``bash
sqlite3 -header -column 'file:$HOME/.codex/logs_2.sqlite?mode=ro' \
'SELECT level, COUNT(*) AS rows
FROM logs
WHERE ts >= CAST(strftime("%s","now") AS INTEGER) - 60
GROUP BY level
ORDER BY rows DESC;'
``

  1. Observe high TRACE row counts continuing after restart.

Expected behavior

One of the following should be true:

  • Local SQLite TRACE storage should respect RUST_LOG=warn and avoid recording TRACE rows at high volume.
  • [analytics] enabled = false should disable this local event/analytics-style trace storage if it is part of that pipeline.
  • A documented setting should exist to disable local SQLite TRACE recording or lower its retention/verbosity.
  • The bounded local store should avoid sustained high-frequency writes and WAL growth by default.

Actual behavior

TRACE rows continue to be written in bursts, including windows with more than 1,000 TRACE rows in 5 seconds, even with [analytics] enabled = false and RUST_LOG=warn.

Privacy note

No raw feedback_log_body contents are included here. The counts above are aggregate queries only. If needed, the user can submit /feedback from within Codex Desktop and include logs/session context.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗