Skip to content

[Bug]: Codex subagent terminal statuses fall through to running in orchestrator v2 #11164

Closed
Closed
[Bug]: Codex subagent terminal statuses fall through to running in orchestrator v2#11164
Labels
acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@eduardozf
eduardozf
opened on Sep 11, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Check out PR feat(orchestrator): introduce new orchestrator #2829.
  2. Start a Codex thread using orchestrator v2.
  3. Spawn a subagent.
  4. Interrupt or shut down the subagent, or process a collaboration state where Codex reports notFound.
  5. Inspect the subagent status recorded by T3.

This can also be reproduced directly by passing each Codex collaboration status through updateSubagentStates.

Expected behavior

T3 should translate each Codex status into the corresponding internal status:

Codex status Expected T3 status
pendingInit pending
running running
interrupted interrupted
completed completed
errored failed
shutdown cancelled
notFound failed

These are the statuses in Codex’s current AgentStatus definition.

Actual behavior

While reviewing issue #8499, I found that PR #2829 already fixes the reported registration problem. The completed spawnAgent event exposes the child thread ID through receiverThreadIds, the PR registers it, and the adapter also handles the newer subAgentActivity path while buffering child turns that arrive before registration.

I verified those paths against Codex CLI rust-v0.150.1, the version reported in #8499, and the latest openai/codex main branch.

During that review, I found a separate bug in updateSubagentStates. It checks for failed, cancelled, and closed, but Codex never sends those values. Several real Codex statuses therefore fall through to running:

Codex status Current T3 status
pendingInit running
running running
interrupted running
completed completed
errored failed
shutdown running
notFound running

The effects are:

  • An interrupted child continues to appear active.
  • A shut-down child remains running, with no completion timestamp.
  • A missing child remains active even though Codex can no longer find it.
  • A child that is still initializing appears to be executing.

This is not a later Codex protocol change. T3’s generated Codex schema already contained these statuses when the mapper was introduced in cc5967e2.

Impact

Major degradation or frequent failure

Version or commit

PR #2829 at 89459e384ad7ffa3b9dda613e9cfebf32a8979e1

Environment

Tested Codex CLI rust-v0.150.1 and openai/codex main at 28f43b0417ab19632f7e53d17806b98151d6b9a0

Created using GPT-5.6-Sol

Activity

  1. eduardozf
    added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Sep 11, 2026

  2. juliusmarminge commented on Sep 11, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 11, 2026
    Member

    Triage

    Confirmed. This is a real mapper bug on orchestrator v2, not a protocol change and not a duplicate of #8499.

    updateSubagentStates in apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts (PR #2829 @ 89459e38) compares Codex agentsStates.status against T3-internal values (failed, cancelled, closed) that Codex never sends. The generated CollabAgent union has been pendingInit | running | interrupted | completed | errored | shutdown | notFound since the mapper was added in cc5967e2, matching Codex AgentStatus.

    Current fall-through:

    Codex T3 today Should be
    pendingInit running pending
    running running running
    interrupted running interrupted
    completed completed completed
    errored failed failed
    shutdown running cancelled
    notFound running failed

    Effects match the report: initializing children look like they are executing; interrupted / shut-down / missing children stay running and never get completedAt (emitSubagentTaskUpdate only stamps terminal statuses).

    The subAgentActivity kind === "interrupted" path is already correct. The broken path is collabAgentToolCall → updateSubagentStates. There is no agentsStates coverage in CodexAdapterV2.test.ts.

    #8499 is the registration/visibility issue. #2829 already registers receiverThreadIds; that does not fix this status map. Keep both open.

    Next step: land an exhaustive CollabAgent-status switch plus per-status tests on #2829 before relying on Codex subagent lifecycle in v2.

  3. juliusmarminge
    added
    acceptedfeature request accepted
    via-triageFiled through npx t3 triage
    and removed
    needs-triageIssue needs maintainer review and initial categorization.
    on Sep 11, 2026

  4. juliusmarminge commented on Sep 22, 2026

    @juliusmarminge
    juliusmarminge
    on Sep 22, 2026
    Member

    Fixed by merged PR #12974 (supersedes open #11996), which normalizes every Codex native subagent status in the orchestrator v2 adapter. Closing as completed.

  5. juliusmarminge
    closed this as completedon Sep 22, 2026
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

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions