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

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.

2. 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.

3. 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.

4. 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.

Reproduce launch and resume with the reported 12.7k- and 146k-item threads, then inspect the app-server resume path and transcript streaming/scroll behavior. Done means resident memory is bounded, open conversations are not all resumed concurrently, mid-tool-call closure resumes without missing-output errors, long-thread scrolling stays anchored, and the zero-second attestation warning no longer fires during normal turns.