[app] Reopening Codex restores completed subagents as unread and memory usage spikes

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

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?

  1. In Codex Desktop, run a task that spawns multiple subagents.
  2. Allow all subagents to complete and allow the parent task to finish.
  3. Leave and then reopen/re-enter Codex Desktop.
  4. Inspect the sidebar.
  5. Observe that multiple completed subagent threads can reappear as unread items.
  6. 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 18 days ago

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

  • #37563
  • #37042
  • #37041
  • #37729
  • #37453

Powered by Codex Action

Harry813 · 16 days ago

Reproduced again on Codex Desktop 26.803.61601 on macOS 26.4 arm64, with stronger lifecycle evidence.

After resuming one long-running parent thread:

  • local persisted state contained 270 child edges for that parent, and every edge was still recorded as open;
  • the corresponding child rollouts ended with:
  • 255 × task_complete
  • 13 × turn_aborted
  • 2 × other response items, both stale for multiple days;
  • sampled children whose rollout ended in an explicit task_complete were still represented by an open spawn edge and appeared as running in the app;
  • during thread/resume, the app logged this warning three times from apply_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:

  • 330 spawn_agent calls;
  • 0 close_agent calls;
  • the current Desktop collaboration tool surface does not expose a close_agent action.

This means completed child handles can accumulate with no available close path. Even if open is intended to mean reusable or addressable rather than executing, rendering those terminal children as running after resume is misleading. Automatic reconciliation against task_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:

  1. replay or recover the latest valid world-state snapshot;
  2. reconcile each child edge against terminal rollout events;
  3. do not render task_complete or turn_aborted children as running;
  4. keep completed child history available without restoring it as active work.
Harry813 · 16 days ago

Additional reproduction on Codex Desktop 26.803.61601 (build 6396) 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:

  • 270 edges already recorded as closed;
  • 1 edge still recorded as open: child 019ff46e-aa0b-7740-870d-8bc157e1d4b8.

That child rollout ended with an explicit task_complete event at 2026-08-12T05:46:06.952Z, yet the corresponding spawn edge remained open. Calling the available interrupt action returned previous_status=completed but did not reconcile the persisted edge.

I created a SQLite backup and changed only that exact edge from open to closed. Post-write checks showed:

  • PRAGMA integrity_check = ok;
  • 271 closed;
  • 0 open for the parent.

This provides two distinct client symptoms:

  1. the displayed 246 open count does not match persisted edge status (1 open) or the live runtime tree (0 running children);
  2. an explicit task_complete child can remain persisted as open, 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.

Harry813 · 16 days ago

Correction/addendum to my previous comment: the 271 closed / 0 open result 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 closed child edges across depths 1–2;
  • 0 open descendants;
  • 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.