Skip to content

Completed subagents appear active until their results are opened #37729

Open
Open
Completed subagents appear active until their results are opened#37729
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsubagentIssues involving subagents or multi-agent features

Description

@JoachimHollman
JoachimHollman
opened on Aug 9, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    subagentIssues involving subagents or multi-agent features
    on Aug 9, 2026

  2. github-actions commented on Aug 9, 2026

    @github-actions
    github-actionsBot
    on Aug 9, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. pomazanbohdan commented on Aug 10, 2026

    @pomazanbohdan
    pomazanbohdan
    on Aug 10, 2026

    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.

  4. qiuyan81 commented on Aug 11, 2026

    @qiuyan81
    qiuyan81
    on Aug 11, 2026

    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.

  5. ponvignesh commented on Aug 11, 2026

    @ponvignesh
    ponvignesh
    on Aug 11, 2026 – with ChatGPT Codex Connector

    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.

  6. apoorvdarshan commented on Aug 13, 2026

    @apoorvdarshan
    apoorvdarshan
    on Aug 13, 2026 – with ChatGPT Codex Connector

    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.

  7. Sythos commented on Aug 14, 2026

    @Sythos
    Sythos
    on Aug 14, 2026

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

    #37563
    #37426
    #37042
    #37041

  8. ponvignesh commented on Aug 14, 2026

    @ponvignesh
    ponvignesh
    on Aug 14, 2026 via email
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsubagentIssues involving subagents or multi-agent features

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions