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.
[Bug]: A steer cancels the agent's pending question or approval#26841
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
- Keep the default follow-up behavior, Steer (pingdotgg/t3code#24718).
- In a Claude thread, ask the agent something that makes it call
AskUserQuestion, or that needs a tool approval. Leave the question unanswered. - 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_sendwithmode: "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.steerTurnsends the steer withpriority: "now";- the SDK aborts the pending permission callback, so
AskUserQuestionresolves 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.sendToThreadinautoandsteermode.
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.