You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A /goal stops a turn that waits on the person's question (OpenCode since v0.1.9, Codex, Claude) #191
A native /goal sent while the turn waits on the person's question or approval stops that turn and cancels the pending request. The overlay's row 30 guard ("a steer waits behind a turn that waits on the person") does not cover it. Upstream T3 Code v0.1.9 extends this to OpenCode, so the overlay needs the guard that #173 proposed upstream.
What happens (upstream v0.1.9, 24e77473ec)
apps/server/src/orchestration-v2/Orchestrator.ts:1205-1215: goalDriverFor returns a goal driver for Codex and Claude, and since v0.1.9 also for OpenCode when capabilities.turns.supportsNativeGoals === true (feat(opencode): mirror native goals across clients pingdotgg/t3code#33758). Before v0.1.9, /goal was ordinary text on OpenCode and went through the row 30 guard.
Orchestrator.ts:6188-6229: for a goal command, when dispatch already resolved to queue_after_active with a delivery intent, the target is projection.runs.findLast(isLiveRun). If goalCommandStopsActiveRun(...) holds, the run is stopped with "Stopped to apply /goal". The check waitsOnPendingRequest(projection) from row 30 is not consulted on that path, so a run waiting on a question or approval is stopped and its request goes with it.
Proposed: port the guard into the overlay's row 30 as a separate pull request after the v0.1.9 rebuild reaches main: a goal command does not stop a run that waitsOnPendingRequest, and queues behind it like a steer. Include a test for each goal driver (Codex, Claude, OpenCode with native goals) that fails without the guard.
Activity