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
- Auto-resume of all open conversations on every launch, concurrently. With two large threads open (12.7k and 146k items), the app-server
codex.exereached 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.
- 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 synthesizedcustom_tool_call_output("output lost, treat as aborted") — the session then resumes withparse errors: 0. Suggest the resume path synthesize exactly that instead of erroring.
- 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.
- 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.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional Windows reproduction on Codex Desktop 26.820.7780.0:
No project files or local Codex state were manually deleted as part of the fix; the user performed a normal uninstall/reinstall.