[Bug]: A steer cancels the agent's pending question or approval#26841

opened12d agobyIimmakermatty

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. Keep the default follow-up behavior, Steer (pingdotgg/t3code#24718).
  2. In a Claude thread, ask the agent something that makes it call AskUserQuestion, or that needs a tool approval. Leave the question unanswered.
  3. While the question is pending, send another message to the same thread: press Enter in the composer, promote a queued message to a steer, or send through the MCP t3_thread_send with mode: "auto" as another agent does.

Expected behavior

The question or approval stays pending until the user answers it. The new message waits in the queue behind the turn and runs after the answer.

Actual behavior

The message steers the running turn, and the pending request is cancelled:

  • ClaudeAdapterV2.steerTurn sends the steer with priority: "now";
  • the SDK aborts the pending permission callback, so AskUserQuestion resolves as "User cancelled tool execution." and an approval as cancelled.

The user never gets to answer the question. Every path that resolves to steer_active does this:

  • the composer's steer;
  • deliveryIntent: "auto";
  • queued-message.promote-to-steer;
  • ThreadManagementService.sendToThread in auto and steer mode.

CommandPolicy.resolveMessageDispatchIntent already queues a steer behind native maintenance commands (/compact, /logout). It has no such check for a pending runtime request.

Impact

Major degradation or frequent failure

With Steer as the default, any message sent while an agent waits on the user cancels the question. That includes a message from the user or from another agent coordinating threads.

Version or commit

v0.1.3 and main @ 8ff9ae1f87

Environment

macOS, T3 Code (Beta) desktop 0.1.3, Claude provider. Observed when an agent's t3_thread_send (mode: "auto") into another thread cancelled that thread's pending AskUserQuestion.

Workaround

Set the follow-up behavior to Queue, and only send mode: "queue" between threads.

Synced from GitHub

Fresh evidence on 0.1.7-nightly.20261102.4080 (Linux server, Claude provider, claude-sonnet-5-5). Two threads each had a pending AskUserQuestion. I messaged one through t3_thread_send with mode: "auto" and the other with mode: "queue". The auto message was delivered as "steered", and the card was cancelled 4.4 seconds later. The queue message was delivered as "queued", and the card stayed pending. In a larger local sample, 59 of 75 cancelled or expired user_input requests were live cards, and 51 of those were on runs that ended completed. So senders can avoid this today by using queue for a thread with a pending question, which matches this issue's expected behavior.