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

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 #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}

Start in apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts at updateSubagentStates, then pass each Codex collaboration status through the mapper as described in the issue. Verify that pendingInit, interrupted, shutdown, and notFound receive their expected T3 statuses while existing mappings remain unchanged; done means no real Codex status falls through to running.