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

  1. Start a Codex desktop task.
  2. Spawn several subagents and let some of them complete or interrupt them.
  3. While the task still has subagent history, terminate the host unexpectedly or reboot it.
  4. Reopen Codex desktop and the same task.
  5. 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 is completed, 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_digest
  • jvm_redis_exact_admission
  • cpp_redis_hybrid
  • m3_asan_final
  • m3_core_removal_audit
  • authority_contract_review
  • session_binding_codex_high_review
  • sample_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:

  1. Resolve every displayed subagent activity to its child agent thread.
  2. If the child thread is completed, interrupted, notLoaded, archived, or absent from the live agent registry, mark the activity terminal.
  3. Persist a terminal timestamp when the parent activity was interrupted without completedAt.
  4. Calculate elapsed time from that terminal timestamp instead of the current time.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35209
  • #34220

Powered by Codex Action

boombx403-byte · 9 days ago

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:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw session data is required, and please redact private paths if you share any output.