Repository navigation
Description
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.
- 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.
- Let the first turn finish and Codex automatically start the next goal continuation.
- 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.
- Send a short follow-up in the same T3 thread. I sent "yes keep working".
- 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.
- 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.
Activity
juliusmarminge commentedon Oct 3, 2026
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 clearis 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.
CodexAdapterV2only picks up aturn/startednotification when that turn is already inactiveTurns, or when T3 has just calledturn/startorthread/compact/start. Any otherturn/startedgoes throughrememberSubagentTurnStarted. On the root thread, that only parks the turn inpendingSubagentTurns, 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 withNo active Codex turn context…. Nothing handlesthread/goal/updatedorthread/goal/clearedeither. The previous T3 run has already receivedturn.terminal, so the thread shows Done while Codex keeps working.The next follow-up then calls
turn/startand 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 emitsturn.terminalagain, and the next automaticturn/startedgets 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,
/goalcommands, 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.