Reproduced in the Linux web dev app on main 70e5e384da, using Claude Opus 5.5. Started a turn running sleep 180, queued /goal finish the refactor, then an ordinary message. Both Steer buttons were enabled. Clicking the goal row and pressing Ctrl+Shift+Enter left both rows queued without a visible error; the runtime trace recorded “Goal commands must run as a separate turn.” Recording. Windows desktop was not tested.
[Bug]: Steer stays enabled on queued /goal messages and fails silently#22397
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Start a turn on a Claude thread and keep it running.
- Queue a message that starts with
/goal, for example/goal finish the refactor. - Queue a second, ordinary message.
- Click Steer on the
/goalrow, or press the steer shortcut.
Expected behavior
The UI does not offer an action that the server always rejects. For a queued /goal (and /compact, /logout), one of these occurs:
- The Steer button is disabled, with a tooltip that gives the server's reason ("Goal commands must run as a separate turn").
- Or, if the click is permitted, the failure shows to the user.
The steer shortcut skips items that it cannot steer, or it tells the user why it did nothing.
Actual behavior
The Steer button is enabled. When you click it, nothing visible occurs. The queued item stays in the queue.
The server rejects the command in dispatchSteerIntoRun (Orchestrator.ts, isGoalCommand). This rejection is intentional, as stated in #18957. But the client does not know about it:
QueuedRunsControl.tsxenables Steer based only onworkflow.canPromoteToSteer, which checks the active run and the provider capabilities. It does not check the message text.steerNextalways targetsqueued[0]. Thus, while a/goalis first in the queue, the shortcut fails on every press, and you cannot steer the ordinary messages behind it with the shortcut.useAtomCommandreports the failure only toconsole, so the user sees no error.
In my local command receipts, a queued /goal at the front of the queue caused 52 of 59 rejected UI steers in 5 days. I clicked again and again because nothing showed that the click had failed.
Impact
Major degradation or frequent failure
Version or commit
Desktop 0.1.0 (installed build). The same code is on main @ b5a0696.
Environment
Windows 11, T3 Code (Beta) desktop, Claude provider (claude-opus-5-5)
Logs or stack traces
shell
| 1 | OrchestratorDispatchError: Failed to dispatch orchestration command queued-message.promote-to-steer (…). |
| 2 | at orchestrationV2.dispatch.withReceipt (…) |
| 3 | at ThreadMessageIntake.dispatchCommand (…) |
| 4 | at ws.rpc.orchestration.dispatchCommand (…) { |
| 5 | [cause]: Error: Goal commands must run as a separate turn. Queue it or wait for the active turn to finish. |
| 6 | } |
Workaround
Stop the active turn. The queued /goal then runs as its own turn. To steer an ordinary queued message, use the Steer button on that row, not the shortcut.