[app] Reopening Codex restores completed subagents as unread and memory usage spikes
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.803.41515 (build 6321)
What subscription do you have?
ChatGPT account (the exact plan does not appear relevant to this client-side lifecycle issue)
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
After reopening or returning to Codex Desktop, the sidebar can show multiple subagent threads that have already finished. These completed child threads are restored as unread items even though neither the parent task nor the subagents have new actionable work.
At the same time, Codex memory usage increases sharply. The visible symptom suggests that completed child-thread state is being rehydrated into the active/unread sidebar and that more history or renderer state may be retained than necessary.
This creates two user-facing problems:
- completed work looks new and requires attention again;
- reopening the app can create substantial memory pressure and degrade responsiveness.
What steps can reproduce the bug?
- In Codex Desktop, run a task that spawns multiple subagents.
- Allow all subagents to complete and allow the parent task to finish.
- Leave and then reopen/re-enter Codex Desktop.
- Inspect the sidebar.
- Observe that multiple completed subagent threads can reappear as unread items.
- Inspect Codex memory usage in Activity Monitor and observe that it rises substantially after these entries are restored.
The issue is intermittent, but it has occurred after workflows with multiple completed subagents.
What is the expected behavior?
- Completed or closed subagents should not reappear as active unread sidebar items unless they contain a genuinely new actionable event.
- Reopening Codex should reconcile child-thread lifecycle and unread state before rendering the sidebar.
- Repeated reopen cycles should not duplicate or retain completed subagent entries.
- Completed child history should be loaded lazily or through the parent task so startup/sidebar memory remains bounded.
Additional information
Related reports cover adjacent parts of this behavior:
- #25179: stale completed subagents accumulate in the app UI/cache.
- #35228: closed child-thread IDs can remain in persisted unread state.
- #24510: unbounded thread metadata/history processing can cause high resource usage.
This report is narrower: it covers the macOS reopen path and the combined symptom of completed subagents returning as unread while memory usage spikes. No local identifiers, task content, or repository data are included.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Reproduced again on Codex Desktop
26.803.61601on macOS 26.4 arm64, with stronger lifecycle evidence.After resuming one long-running parent thread:
open;task_completeturn_abortedtask_completewere still represented by anopenspawn edge and appeared as running in the app;thread/resume, the app logged this warning three times fromapply_rollout_reconstruction:``
text
``ignored world-state patch without a full snapshot
The resumed rollout contained 67,417 items.
This narrows the symptom: completed or aborted child turns are persisted/restored as open spawn edges. The reconstruction warning may be related, but I cannot prove causality from local evidence alone.
Additional lifecycle evidence from the parent rollout:
spawn_agentcalls;close_agentcalls;close_agentaction.This means completed child handles can accumulate with no available close path. Even if
openis intended to mean reusable or addressable rather than executing, rendering those terminal children as running after resume is misleading. Automatic reconciliation againsttask_complete/turn_aborted, or an exposed close action, would prevent the accumulation.I could not inspect OS process state because macOS denied
ps, so this update does not claim that 270 model processes are actually alive. It confirms a persisted lifecycle/UI state mismatch: explicit child terminal events coexist with open child edges after resume.Expected reconciliation on resume:
task_completeorturn_abortedchildren as running;Additional reproduction on Codex Desktop
26.803.61601(build6396) on macOS, from the same long-running parent thread.This time the UI reported 246 open subagents, but the live collaboration tree contained only the root plus one completed reviewer. The persisted parent state contained 271 direct spawn edges:
270edges already recorded asclosed;1edge still recorded asopen: child019ff46e-aa0b-7740-870d-8bc157e1d4b8.That child rollout ended with an explicit
task_completeevent at2026-08-12T05:46:06.952Z, yet the corresponding spawn edge remainedopen. Calling the available interrupt action returnedprevious_status=completedbut did not reconcile the persisted edge.I created a SQLite backup and changed only that exact edge from
opentoclosed. Post-write checks showed:PRAGMA integrity_check = ok;271 closed;0 openfor the parent.This provides two distinct client symptoms:
task_completechild can remain persisted asopen, and the exposed interrupt action does not close/reconcile it.No child history was deleted. This looks like both a lifecycle-reconciliation defect and a UI count/rehydration defect. The resume path should reconcile terminal rollout events before computing or rendering the open/running SubAgent count.
Correction/addendum to my previous comment: the
271 closed / 0 openresult described the parent's direct spawn edges after repair. A recursive traversal then found 3 additional open nested edges at depth 2. Their child rollouts ended in terminal events (1 × task_complete,2 × turn_aborted). After closing those three exact edges, the recursive tree now reports:274 closedchild edges across depths 1–2;0 opendescendants;PRAGMA integrity_check = ok.The app had displayed 246 open SubAgents even though the repaired recursive persisted tree is 274 closed / 0 open. This strengthens the UI count-cache/rehydration mismatch: the visible number is neither the direct edge count nor the recursive persisted-open count.