Long-running threads: unbounded memory growth, auto-resume of all open conversations, rollout corruption on mid-call close, scroll anchoring broken

Open 💬 2 comments Opened Aug 26, 2026 by autonomouscereal
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Long-running threads (10k–150k rollout items, kept intentionally) make Codex desktop progressively unstable: unbounded memory growth, aggressive auto-resume of every open conversation at launch, corrupted rollouts when the app closes mid-tool-call, and scroll-position jumping in long transcripts.

Environment

Windows 11 Pro (26200), Codex desktop MSIX 26.820.7780.0, bundled codex-cli 0.150.0-alpha.8.

Details

  1. Auto-resume of all open conversations on every launch, concurrently. With two large threads open (12.7k and 146k items), the app-server codex.exe reached 7.6–15.4 GB RSS and stayed there; memory does not stabilize after resume completes. Suggest lazy resume (on focus), and bounding resident history.
  1. Closing the app mid-tool-call corrupts the rollout. The in-flight call's output is never recorded; on next resume the session fails Custom tool call output is missing for call id: ... and retry-loops indefinitely (blocking that thread for local and remote use). We repaired manually by appending a synthesized custom_tool_call_output ("output lost, treat as aborted") — the session then resumes with parse errors: 0. Suggest the resume path synthesize exactly that instead of erroring.
  1. Scroll-position anchoring in very long threads is broken — the transcript randomly jumps up/down during streaming in large conversations, which makes long-queue sessions hard to use and appears to amplify memory/render pressure.
  1. Attestation warning on every turn: attestation generation request timed out timeout_seconds=0 — the zero-second timeout looks like a misconfigured flag; it fires constantly during normal turns.

Ask

Long-lived, ever-growing threads are a legitimate workflow. The app currently pays O(full thread) costs at launch, attach, and render time. Bounding resident state (pagination/windowing at every layer: resume, memory, UI) would fix the whole class.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 day ago

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

  • #39946
  • #40400
  • #39743
  • #40933

Powered by Codex Action

TAKURO-FU · 1 day ago

Additional Windows reproduction on Codex Desktop 26.820.7780.0:

  • As of 2026-08-27, the issue had been occurring for about two days.
  • Codex Desktop would freeze while its memory usage continued increasing.
  • Observed memory usage exceeded 10 GB and kept growing.
  • The rest of Windows became effectively unusable while Codex was in this state.
  • Force-quitting Codex immediately restored normal PC operation.
  • Rebooting Windows did not resolve the behavior; it reproduced after restart.
  • Task Manager screenshots during one reproduction showed Codex memory increasing from roughly 4.1 GB to 5.1 GB, and it later exceeded 10 GB.
  • Installed app version shown in Windows was 26.820.7780.0.
  • Uninstalling and reinstalling the desktop app resolved the issue. After reinstall, the memory runaway/freezing stopped.

No project files or local Codex state were manually deleted as part of the fix; the user performed a normal uninstall/reinstall.