Desktop app shows completed subagents as active and keeps increasing elapsed time after host reboot
Resolved 💬 2 comments Opened Jul 26, 2026 by kairos-code-dev Closed Jul 26, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
After a Windows/WSL host power loss and reboot, the Codex desktop app keeps completed or interrupted subagents in the Active list as if they are still working. Their elapsed timers continue increasing for days.
This is confusing because it looks like those agents are still consuming tokens and compute, even though the backend no longer considers them live.
Environment
- Codex desktop package:
OpenAI.Codex_26.721.4979.0_x64 - Codex CLI:
0.145.0 - Host: Windows 11 Pro 10.0.26200 (build 26200)
- Workspace: WSL2 Ubuntu 24.04
- WSL kernel:
6.6.87.2-microsoft-standard-WSL2
Trigger
The machine lost power while a long-running Codex task had multiple subagents. The machine and Codex desktop app were then restarted and the same task was reopened.
Steps to reproduce
- Start a Codex desktop task.
- Spawn several subagents and let some of them complete or interrupt them.
- While the task still has subagent history, terminate the host unexpectedly or reboot it.
- Reopen Codex desktop and the same task.
- Open the subagent activity panel.
Actual behavior
- Old subagents remain under Active with the Korean status
작업 중("working"). - Their elapsed timers keep increasing, including entries showing 2–4 days.
- The live subagent registry does not contain those agents.
- Attempting to interrupt one of the stale agent paths returns
not_found. - Reading the underlying agent thread shows
thread.status.type = "notLoaded"and its latest turn iscompleted, while the UI still shows it as active. - Some parent activity records have an interrupted turn without
completedAt, even though the child agent's own latest turn completed. This may be the stale-state source. - The presentation makes users reasonably believe tokens and CPU are still being consumed.
Examples observed in the Active panel included:
cpp_redis_descriptor_digestjvm_redis_exact_admissioncpp_redis_hybridm3_asan_finalm3_core_removal_auditauthority_contract_reviewsession_binding_codex_high_reviewsample_node_placement_audit
Backend evidence for one stale entry:
- agent thread ID:
019f8ef3-eec2-7bf2-a92e-da5da6489fd5 - thread status:
notLoaded - latest agent turn:
completed - desktop Active panel:
작업 중, elapsed time continuously increasing
Expected behavior
- A completed or interrupted subagent should leave the Active list immediately.
- After app/host restart, activity should be reconciled from the child thread's terminal state.
- Elapsed time should stop at completion/interruption.
- If reconciliation cannot determine the state, the UI should show an explicit stale/unknown state rather than "working".
- The panel should distinguish UI history from agents that are actually scheduled and consuming tokens.
Suggested reconciliation rule
On task load and after reconnect:
- Resolve every displayed subagent activity to its child agent thread.
- If the child thread is
completed,interrupted,notLoaded, archived, or absent from the live agent registry, mark the activity terminal. - Persist a terminal timestamp when the parent activity was interrupted without
completedAt. - Calculate elapsed time from that terminal timestamp instead of the current time.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hi @kairos-code-dev, this subagent persistence/history issue aligns with some boundary anomalies observed in multi-agent rollouts. Codex Rescue Alpha5 provides read-only lifecycle and subagent boundary diagnostics, cleanly separating historical start markers from current live execution state without altering the source rollout.
If you have access to the local session, you can run a non-destructive check:
No raw session data is required, and please redact private paths if you share any output.