Codex Windows app-server writes excessive TRACE logs to logs_2.sqlite WAL

Open 💬 3 comments Opened Jun 24, 2026 by starming0110

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.616.10790.0

What subscription do you have?

improve

What platform is your computer?

x64

What issue are you seeing?

Title:
Codex Windows app-server writes excessive TRACE logs to logs_2.sqlite WAL

Component:
Codex Windows desktop app / app-server

Version:
OpenAI.Codex 26.616.10790.0
Windows package path:
C:\Program Files\WindowsApps\OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0

Issue:
The Codex app-server continuously writes high-frequency TRACE logs into:
C:\Users\<user>\.codex\logs_2.sqlite
and its WAL file:
C:\Users\<user>\.codex\logs_2.sqlite-wal

Observed evidence:

  • logs_2.sqlite size: ~583 MB
  • logs_2.sqlite-wal size: ~116 MB
  • SQLite journal mode: WAL
  • Recent 1-minute window: ~1,788 to ~1,992 TRACE rows
  • Recent 5-minute window: ~1,789 TRACE rows
  • Writer process: codex.exe app-server --analytics-default-enabled
  • Process version: OpenAI.Codex 26.616.10790.0
  • Realtime 16-second sampling showed max(id) increasing from 21308956 to 21311034 while WAL mtime kept updating.
  • Latest TRACE rows include websocket/tungstenite/SSE frame-level logs such as:
  • received frame
  • decompressing bytes in final frame
  • codex_api::sse::responses
  • tokio-tungstenite compat read/poll_read

Expected behavior:
Production Codex desktop builds should not persist frame-level TRACE logs at this frequency during normal usage, or should cap/throttle/rotate them aggressively.

Impact:
Continuous disk writes, growing SQLite/WAL files, unnecessary background I/O, and possible retention of detailed runtime content in local logs.

Notes:
RUST_LOG in the current shell is set to warn, and config.toml/config.json do not appear to explicitly enable TRACE logging.

What steps can reproduce the bug?

Title:
Codex Windows app-server writes excessive TRACE logs to logs_2.sqlite WAL

Component:
Codex Windows desktop app / app-server

Version:
OpenAI.Codex 26.616.10790.0
Windows package path:
C:\Program Files\WindowsApps\OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0

Issue:
The Codex app-server continuously writes high-frequency TRACE logs into:
C:\Users\<user>\.codex\logs_2.sqlite
and its WAL file:
C:\Users\<user>\.codex\logs_2.sqlite-wal

Observed evidence:

  • logs_2.sqlite size: ~583 MB
  • logs_2.sqlite-wal size: ~116 MB
  • SQLite journal mode: WAL
  • Recent 1-minute window: ~1,788 to ~1,992 TRACE rows
  • Recent 5-minute window: ~1,789 TRACE rows
  • Writer process: codex.exe app-server --analytics-default-enabled
  • Process version: OpenAI.Codex 26.616.10790.0
  • Realtime 16-second sampling showed max(id) increasing from 21308956 to 21311034 while WAL mtime kept updating.
  • Latest TRACE rows include websocket/tungstenite/SSE frame-level logs such as:
  • received frame
  • decompressing bytes in final frame
  • codex_api::sse::responses
  • tokio-tungstenite compat read/poll_read

Expected behavior:
Production Codex desktop builds should not persist frame-level TRACE logs at this frequency during normal usage, or should cap/throttle/rotate them aggressively.

Impact:
Continuous disk writes, growing SQLite/WAL files, unnecessary background I/O, and possible retention of detailed runtime content in local logs.

Notes:
RUST_LOG in the current shell is set to warn, and config.toml/config.json do not appear to explicitly enable TRACE logging.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗