[Bug]: Orchestrator V2 shows Codex goals as Done while automatic continuation turns are still running

[mmb-it]

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

This started after I upgraded to the V2 orchestrator. I did not see this behavior before the upgrade.

1. Start a Codex task in goal mode that needs several substantive phases, with one phase per turn and the goal kept active until the task is finished.
2. Let the first turn finish and Codex automatically start the next goal continuation.
3. Observe that T3 shows Done even though Codex is still working. Compare the T3 run/provider state with the native Codex goal state and rollout activity.
4. Send a short follow-up in the same T3 thread. I sent "yes keep working".
5. T3 shows the thread as running again and displays new activity. Inspection confirms that the new T3 run uses the already-running native Codex continuation, without creating a new thread.
6. Let that continuation finish. Codex automatically starts another turn, and T3 loses tracking and shows Done again.

I reproduced the status mismatch on three goal threads and verified the follow-up/lose-tracking cycle on one of them.

Expected behavior

T3 should track automatic Codex goal continuation turns and show Working while they run. Their messages and tool activity should keep appearing in the existing thread without needing a manual follow-up after every phase. Goal completion should be distinct from the completion of one phase.

Actual behavior

The UI shows Done after a phase completes, while native Codex continues working toward the same active goal. Read-only inspection confirms that T3 records the latest run as completed and the provider thread as idle, while Codex has started another turn and continues recording tool activity and token usage.

A follow-up temporarily restores tracking. It creates a new T3 run associated with the existing native continuation turn. When that turn finishes, T3 marks the run completed and fails to track the next automatic continuation again.

This makes running work appear finished and hides its ongoing activity. Question/approval delivery may also be affected, but I have not reproduced a lost question or approval, so that is a concern rather than a confirmed symptom.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261003.2623, Orchestrator V2

Environment

macOS 27.0, arm64; T3 Code Nightly desktop; Codex CLI/app-server 0.160.0; model gpt-6.1-sol, high reasoning effort, full-access mode.

Logs or stack traces

Condensed evidence from local T3 V2 projections and the native Codex rollout on 2026-10-03. All times are UTC. This is a summary of separate records, not a raw single log.

09:27:58.168  Codex starts automatic continuation A:
              01a10117-79c7-7e10-b931-b014d7498e4a
              T3 still records the preceding run as completed.
09:54:01.902  User sends "yes keep working" in the same T3 thread.
              T3 creates run ordinal 2.
09:54:02.002  T3 records continuation A as running under that run.
              Same native Codex thread and same continuation turn ID.
09:54:12.224  T3 displays the agent response "I'm continuing."
09:56:31.826  Codex completes continuation A.
09:56:31.837  Codex starts automatic continuation B:
              01a10131-9fd3-7392-a838-9f1941bcdaf1
09:56:31.895  T3 marks run ordinal 2 completed.
09:58:15.122  Codex records further activity while its goal is active.
09:58:32      T3 still reports the latest run as completed.

Possible cause

Based on source inspection: apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts has no goal lifecycle handlers. Its turn/started handler registers pending T3 root turns, but otherwise routes unknown turns through rememberSubagentTurnStarted. A provider-started root goal continuation has no pending T3 root turn. This fits the observed missing continuation records, but it is not a verified fix.

Related reports and proposals

Related prior proposals: #8615 and #11516. Both closed without merging. In #11516, the maintainer asked for a fresh report or PR if the issue persisted after V2 landed. V2 merged in #2829.

I searched open and closed issues for goal, Codex continuation, and Codex/Done/v2 and found no report specifically covering this V2 continuation cycle.

Workaround

Sending a follow-up such as "yes keep working" restores tracking for the current continuation only. The next automatic goal turn loses tracking again. Checking native Codex logs confirms that work is continuing despite the Done label.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @mmb-it for the clear report! I confirmed this on main (263097a8da). It's a gap in Orchestrator V2. It isn't a duplicate of #13252 (open; /goal clear is still sent as ordinary chat text), and it isn't covered by the closed, unmerged V1 goal-UI PRs #8615 and #11516.

What's happening: in goal mode, Codex starts the next root turn on its own after a phase finishes. CodexAdapterV2 only picks up a turn/started notification when that turn is already in activeTurns, or when T3 has just called turn/start or thread/compact/start. Any other turn/started goes through rememberSubagentTurnStarted. On the root thread, that only parks the turn in pendingSubagentTurns, so it never becomes active, and later item and token events for it are dropped. Approval and user-input requests during that turn hit the same miss and fail with No active Codex turn context…. Nothing handles thread/goal/updated or thread/goal/cleared either. The previous T3 run has already received turn.terminal, so the thread shows Done while Codex keeps working.

The next follow-up then calls turn/start and binds whatever native turn id comes back. Since the automatic continuation was never tracked, it ends up attached to the new run. When it completes, T3 emits turn.terminal again, and the next automatic turn/started gets dropped the same way. Claude and Grok already open a continuation run when the provider starts a turn itself. Codex only does that for a background command that finishes after its turn has settled.

Likely fix area: when the provider starts a root turn on a thread T3 owns, open a continuation run, take in that turn's events, and keep the thread marked as working until the goal is actually done. Goal toolbars, /goal commands, and a "Goal active" status are separate questions from that V1 work, and #13252 tracks the clear-command bug. Lost questions and approvals are a likely side effect of the missing turn context, but I haven't reproduced them yet.

A maintainer will decide on the fix direction.