Codex Desktop rehydrates nonexistent historical subagents as active whenever an affected task is opened

Additional reproducible datapoint from Codex Desktop on Linux. This is the second occurrence for this user/task workflow.

Environment:

• OS: Pop!_OS 24.04 LTS, Linux x86_64
• Codex CLI currently: 0.147.0
• Affected subagent session metadata was created under Codex Desktop / CLI 0.144.4
• Long-running parent task with multiple brainstorm, plan, review, and fix waves

Observed on 2026-08-08 (Asia/Kolkata):

• The Subagents panel displayed exactly 18 historical agents as is working.
• Those 18 entries mapped exactly to child session metadata accumulated across earlier completed waves: 14 reviewers and 4 implementation workers.
• Parent rollout records contain successful close_agent calls whose returned previous_status was completed for these agents.
• Reissuing close_agent against all 18 IDs now returns agent with id ... not found from codex_core::tools::router.
• Local process inspection shows only the expected Codex app-server/proxy/code-mode-host processes, not 18 executing child processes.
• The UI therefore reports active work while the authoritative live registry has no corresponding agents.
• A prior local state backup named for stale-agent repair confirms this is a recurrence rather than the first incident.

Impact:

• The user cannot trust whether background work is actually executing.
• The agent initially misreported the panel as stale without verification because no list/status API is exposed; only ID-based close/wait calls are available.
• Restart/reopen is only a cosmetic workaround and does not address the parent/child state projection defect.

This Linux recurrence supports the issue's proposed root cause: parent-task restoration is rendering historical spawn/session records as active without reconciling them against terminal rollout events or the live agent registry.

Additional requested diagnostics can be provided in sanitized form. The affected project contents and prompts are private and are intentionally omitted.

The cross-platform recurrence makes this look like a restoration contract problem rather than a renderer-only cache bug.

I would treat every persisted child-agent row on task load as historical evidence to reconcile, not as a liveness record that can be replayed directly into Working.

A child can carry separate fields such as:

child_id
spawn_generation
last_terminal_event = completed|closed|failed|null
last_terminal_event_at
live_owner_epoch|null
last_reconciled_at

Then task restoration can use a monotonic rule:

terminal evidence exists           => terminal, never Working
live registry/lease confirms child => active
neither                            => stale/unknown, never Working by default

That is important because historical spawn edges are append-only facts: they prove the child once existed, not that it is executing now. A reboot cannot make that old fact current again.

The existing close_agent -> not found result is also useful reconciliation evidence. close should be idempotent at the control-plane level: if the live registry has no child and durable history already shows terminal completion, return already_terminal and repair the projection rather than leaving a Working badge.

I would add one recovery fixture built from the reported sequence:

spawn child C
C completes
close_agent(C) -> previous_status=completed
persist parent
restart app/server
open parent
=> C renders completed/history-only
=> C does not count toward active limits
=> no runtime/process is recreated for C

and the corruption twin:

historical spawn exists, terminal record missing, no live owner
=> stale/unknown + repair path, not active

The invariant is: task restoration may reconstruct history, but only current runtime evidence may reconstruct liveness.

Still issue alive in desktop app 26.803.5235.0 (win11pro fully updated)

workaroudn: select one by time, waiting the sync, go abck and the subagent go back "done"

Really, last update made things worst :D

<img width="302" height="70" alt="Image" src="https://github.com/user-attachments/assets/17a2cec1-4b0e-42be-be8a-95f658762c2e" />

This reopen-triggered rehydration also reproduced on Windows: children with terminal task_complete rollouts and no live handles returned to Active after the parent was opened again. Opening a child forced a one-by-one refresh; restart did not repair the projection. This links directly to #37042, #37563, and the stale-handle report in #23930.

Additional macOS reproduction observed on 2026-08-26:

• Before restarting Codex Desktop, the Subagents panel showed Active 33 / Done 10.
• Runtime inspection exposed no corresponding live workers for several displayed entries.
• Direct interrupt attempts for displayed agents such as /root/fix_keyboard_navigation, /root/workbench_roving_focus, and /root/issue21_implementation_retry returned not_found.
• After fully restarting the app and reopening the same task, the panel became Active 40 / Done 3.
• Several agents previously shown under Done moved back to Active/Working, including Fix selector dynamic asset loading, Scope vehicle selector asset, and Invoice dropdown offset.
• Their displayed elapsed timers continued increasing.
• The underlying agents had previously returned completed/final results.

This strengthens the task-rehydration/state-reconciliation diagnosis: restart does not merely preserve stale classifications; it can reclassify additional completed agents as active and reduce the Done count. The UI therefore cannot be used to determine whether model usage or concurrency is still active.

Two cropped screenshots containing only the Subagents panel are available if maintainers need them.

Update (2026-08-26, Windows/MSIX): the load-time rehydration pattern is reproducible on Codex Desktop 26.820.7780.0 (x64) with bundled CLI codex-cli 0.150.0-alpha.8.

After completed child agents were cleaned/closed, the UI initially looked clear. After the app ran for some time and the affected parent chat was reopened, historical children reappeared as Active/Working. A read-only audit showed no live child handles, but 172 persisted child rows (171 normally completed, 1 incomplete), stale thread-history activity, 452 rollout ordinal gaps, and projection cursors that lagged far behind the corresponding rollout ends. The rollout JSONL files were still present, so this is not confirmed message deletion; the history materializer is failing to advance and task load rehydrates stale activity as active.

Reproduction: spawn children, let them complete, close/reopen Codex, wait for background materialization, then reopen the same long-running parent task and inspect Subagents. The stale rows return. This reproduces the lifecycle/state-projection divergence on current Windows. No private project data is attached.