Codex Desktop becomes unusable on long active threads due to app-server/renderer memory and TRACE log churn

[markmdev]

Summary

Codex Desktop becomes nearly unusable with long-running active threads, even after compaction-aware local transcript pruning.

The slowdown appears to come from the Codex app-server and renderer repeatedly handling large hot conversation state and logging large websocket/SSE response frames into logs_2.sqlite.

Environment

• Codex Desktop: 26.429.30905
• Electron: 41.2.0
• macOS: 26.0.1 (25A362)
• Machine memory: 16 GB

Observed behavior

During the slowdown:

• codex app-server spiked to ~64% CPU.
• codex app-server sampled physical footprint peaked at ~4.4 GB.
• A Codex renderer reached ~1.07 GB RSS.
• logs_2.sqlite / WAL grew by about 1.4 MB in one second.
• Recent log rows were dominated by TRACE entries from:
  • codex_api::endpoint::responses_websocket
  • codex_api::sse::responses
  • raw-ish response/frame logging such as response.completed / received websocket frames
• One active long-running thread had grown back to ~839 MB with 22 compactions.
• The app remained sluggish even after pruning older pre-compaction rollout records, until restart/reload.

Chronicle was not the active CPU source in this case.

Why this seems like a Codex Desktop issue

Compaction-aware pruning helps reduce hot rollout JSONL size, but the running Desktop app still appears to keep or reconstruct very large hot thread state in app-server/renderer memory.

Separately, TRACE logging of large websocket/SSE frames can make logs_2.sqlite churn quickly, which seems to amplify the slowdown.

This makes long-running "main" threads effectively degrade over time, even when compactions exist and old raw history has been pruned locally.

Expected behavior

Long-running threads should remain usable after compaction. Codex Desktop should not need manual JSONL pruning, log rotation, or full restart to recover basic responsiveness.

Suggested fixes

• Truncate or disable large TRACE websocket/SSE payload logging in normal Desktop builds.
• Avoid retaining/rendering full hot thread state after compaction.
• Lazy-load old transcript/UI history instead of materializing the whole active thread.
• Add a first-class local "prune/compact UI history" action that preserves agent-visible compacted context.
• Release app-server/renderer in-memory thread state after compaction/pruning without requiring a full app restart.
• Add diagnostics that show which active thread/log source is causing app-server or renderer pressure.

Impact

For users who keep long-running main threads open, Codex Desktop can become almost unusable: high CPU, high renderer/app-server memory, heavy SQLite log churn, and severe UI lag.

[github-actions]

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

• macOS Desktop UI lag with excessive codex disk writes despite low system resource pressure #21007
• Codex Desktop becomes unrecoverable on launch when the most recent session rollout exceeds ~500 MB #20269
• Windows 26.429 desktop becomes unresponsive with long threads, MCP auto-start duplicates, and non-Git workspace warnings #20867
• VS Code Codex extension repeatedly broadcasts huge thread-stream-state-changed snapshots for completed long threads, causing extension-host/renderer CPU spikes #20781

Powered by Codex Action

[baron]

Someone investigated this in #21211 You can improve performance just by truncating titles to 120 chars in state_5.sqlite but the sidebar still loads the full first message just on launch so it's still problematic.