›_ Codex Issues
Codex Issues / #37729

Completed subagents appear active until their results are opened

Open 💬 7 comments Opened Aug 9, 2026 by JoachimHollman
💡 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?

The exact Codex Desktop build was not available to the agent. Observed on 2026-08-09.

What subscription do you have?

Not relevant to the UI behavior.

What platform is your computer?

macOS 26.6.1 (25G76), arm64.

What issue are you seeing?

Completed subagents can remain presented in the parent task UI as if they are still active. In this case, the UI appeared to show three active subagents, while the runtime agent-status query reported that every child agent was completed and only the parent agent was running.

Opening each completed subagent caused its apparent active indicator to disappear. This suggests that the indicator represents an unread completion/result, but visually communicates ongoing execution instead.

This is confusing because users may reasonably conclude that agents are still consuming model time or other resources.

What steps can reproduce the bug?

  1. Start one or more subagents from a parent task.
  2. Let the subagents finish.
  3. Return to the parent task without opening the completed subagent results.
  4. Observe that the UI still appears to present some subagents as active.
  5. Verify through agent runtime status that those subagents are completed.
  6. Open the completed subagents one by one.
  7. Observe that their indicators disappear after being viewed.

What is the expected behavior?

The UI should clearly distinguish:

  • Running: the subagent is still executing.
  • Completed — unread result: execution has ended, but its result has not been opened.
  • Completed — read: execution has ended and its result has been viewed.

A label such as “3 unread subagent results” would avoid implying that three agents are still running.

Additional information

No continued execution was actually observed. The issue is the mismatch between the visual state and the runtime state, which made it necessary to inspect the agent status explicitly to determine whether resources were still being consumed.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 18 days ago

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

  • #37426

Powered by Codex Action

pomazanbohdan · 17 days ago

Confirmed on Windows; this appears to be the same UI/status rehydration issue.

Environment:

  • ChatGPT/Codex Desktop package: OpenAI.Codex 26.803.5235.0 (x64)
  • OS: Windows 11 Pro 10.0.26200, x64
  • Chromium: 151.0.7922.76
  • Affected parent task: “Quick Dev 3.0”

Observed behavior:

  • The Subagents panel showed “Active · 11” for a parent task containing historical child work.
  • A read-only status sample of four child references returned:
  • 1 child: active, latest turn inProgress
  • 2 children: idle, latest turn completed
  • 1 child: notLoaded, latest turn completed
  • Opening a historical child and returning to the parent changes its row from Active/Working to Done/Completed.
  • After reopening or reloading the parent task, stale Active rows can be reconstructed again.
  • Therefore, the displayed elapsed time is not reliable evidence of a live worker.

App-level log evidence for 2026-08-10 (06:00:08–12:24:33 UTC; conversation IDs omitted):

  • 792 thread/list responses were observed; all had errorCode=null.
  • 234 turn/started and 76 turn/completed events were logged for unknown conversations.
  • 2,046 item/started and 2,038 item/completed events were logged for unknown conversations.
  • These events were emitted to both the primary and avatar-overlay renderers.
  • The app-server started twice with no reconnect attempts.

Interpretation:
The renderer appears to receive terminal/live events after the corresponding child state has been unloaded or is not hydrated, then projects historical or unresolved children as Active. Opening the child seems to force a status refresh.

Expected behavior:

  • Only children with live inProgress execution should count as Active.
  • completed, interrupted, and notLoaded historical children should not be shown as running.
  • Opening a child should not be required to repair its status.
  • Reload/restart should preserve terminal status.

This Windows reproduction is also consistent with #37802, #37563, and #37042. I can provide sanitized log excerpts privately if needed.

qiuyan81 · 17 days ago

Windows reproduction and persistence evidence

I can reproduce the same behavior on:

  • Codex Desktop 26.803.8161.0
  • Windows 11 Pro, build 26200

Observed behavior:

  1. An affected parent thread showed 103 Active and 49 Done child agents (152 total).
  2. Many entries shown as Active had actually completed days earlier; some were more than 16 days old.
  3. Restarting Codex did not reconcile the stale states.
  4. Opening an already-completed child caused its reconciled completion state to persist locally, after which the stale Active entry disappeared. Without opening each child, the stale state remained.
  5. With this large stale list present, opening the parent thread could freeze the UI.

Sanitized local diagnostics from the affected installation:

  • The affected parent had 152 persisted child relationships.
  • Across the local state database, 1,236 child relationships were present; 1,234 had an open edge marker and 2 had a closed marker at inspection time. I understand that this edge marker may not itself be the runtime status, but the skew may help reproduce the hydration path.
  • The oldest open relationship was about 24.9 days old.
  • Related processes used about 3.77 GB of working set; the largest renderer used about 1.81 GB.
  • During a 3-second sample, total CPU time increased by only 0.04 seconds. This looked more like state/history hydration plus renderer pressure than agents actively doing work.
  • This installation also has substantial local history (1,384 rollout JSONL files, about 24.83 GB; local log index about 1.63 GB), which may amplify the freeze even if it is not the cause of the stale status.

Expected behavior:

  • Hydrating a parent should reconcile terminal child states without requiring the user to open every child manually.
  • Completed — unread should be distinct from Running.
  • Reconciliation should be bounded or lazy enough that a parent with 152 historical children remains responsive.
  • Startup or parent hydration should provide a self-healing/batch path that persists reconciled terminal state locally.

This appears closely related to the cold hydration behavior discussed in #37042, with an additional large-history UI freeze symptom.

No project names, prompts, repository paths, thread IDs, account details, or conversation contents are included here.

ponvignesh · 17 days ago

Confirmed on Codex Desktop for Windows ARM64.

Environment:

  • Codex Desktop package: OpenAI.Codex_26.803.10989.0_arm64
  • Windows: 10.0.26200, ARM64
  • Local Codex command runner observed: 0.147.0-alpha.6.6

Observed behavior:

  • Historical completed subagents remained displayed under Active / Working.
  • Some displayed elapsed times of approximately 31 days, creating the impression that they were still executing.
  • Opening an affected subagent and navigating back immediately changed its card to Done.
  • Repeating this for each stale card corrected them individually.

This closely matches the report: the terminal state appears not to be reconciled until the child detail view forces a refresh. The long elapsed time makes the stale status especially confusing because users cannot tell whether work or usage is still active.

No private task content, thread identifiers, repository paths, or organization data are included.

apoorvdarshan · 14 days ago

I’m seeing the same behavior in Codex Desktop. The Subagents panel shows completed subagents as still running/active, but opening them shows the work as Done/completed. I also checked the underlying task status and found no active subagents running. The active indicator disappears after opening the completed result, which appears to be a stale UI state.

Sythos · 14 days ago

Just asking but, isn't this issue a duplicate of the following?

#37563
#37426
#37042
#37041

ponvignesh · 14 days ago

Looks like it the same .

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Sythos @.*>
Sent: Friday, 14 August 2026 16:49:06
To: openai/codex @.*>
Cc: ponvignesh @.>; Comment @.>
Subject: Re: [openai/codex] Completed subagents appear active until their results are opened (Issue #37729)

[https://avatars.githubusercontent.com/u/15103522?s=20&v=4]Sythos left a comment (openai/codex#37729)<https://github.com/openai/codex/issues/37729#issuecomment-5291379522>

Just asking but, isn't this issue a duplicate of the following?

#37563<https://github.com/openai/codex/issues/37563>
#37426<https://github.com/openai/codex/issues/37426>
#37042<https://github.com/openai/codex/issues/37042>
#37041<https://github.com/openai/codex/issues/37041>

—
Reply to this email directly, view it on GitHub<https://github.com/openai/codex/issues/37729?email_source=notifications&email_token=ADMNPPKLCUQEJ3CW3NF732L5J3HAFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRZGEZTOOJVGIZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5291379522>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADMNPPL6AZ7XFYQPA7JU2L35J3HAFAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMJQGQZDIOBVGA42C5QC>.
You are receiving this because you commented.Message ID: @.***>