[Bug]: Steering into a turn waiting on Claude's AskUserQuestion leaves a stale question that can't be answered #15517

Activity

1. sandscooling

   added 2 commits that reference this issue on Oct 4, 2026

   fix(server): session_wake queues behind an open question instead of a…

   ...

   8dc07dd

   fix(server): a scheduled task queues behind a busy thread instead of …

   ...

   68b5524
2. WhiteWarrior625 commented on Oct 8, 2026

   

   WhiteWarrior625

   on Oct 8, 2026

   Last edited by WhiteWarrior625

   More actions

   Additional production reproduction on Linux, stock nightly 0.0.46-nightly.20261005.2702, Claude Agent SDK / Claude Opus 5.5. This reaches the same abort through cross-thread t3_thread_send with mode: auto, rather than the manual Steer button.

   Five recorded AskUserQuestion calls aborted when an incoming message was offered with priority: now. The provider log pairs are below, in UTC on October 8:

   Immediate offer	Aborted tool result
   15:18:10.812	15:18:10.821
   15:32:47.153	15:32:47.166
   15:33:19.681	15:33:19.693
   15:34:34.115	15:34:34.126
   15:35:23.344	15:35:23.359

   Each returned Tool permission request aborted. Two other question calls in the same retained timeline accepted answers normally. The user reported typing answers repeatedly, with the composer clearing and the answer not reaching the agent. I have not independently reproduced the composer-clearing UI behavior.

   A later read-only projection check found four of the aborted requests marked resolved at 15:24:39.404, 15:33:44.827, 15:34:11.851 and 15:35:26.757Z, all after their provider tool result had already aborted. The fifth was cancelled when that turn was interrupted. This corroborates the stale-request problem described here. It does not establish a current pending orphan, since those requests were subsequently resolved or cancelled.

   The installed-version source sends steering with priority: now. Its AskUserQuestion callback removes its pendingRuntimeRequests entry after the abort race without emitting cancellation at that point. Our named local question guard runs only on Stop and has no path that aborts a pending question.

   Minimal reproduction for this additional entry point:

   1. In Claude thread A, ask a color question with Red and Blue choices and wait for the card.
   2. From thread B, call t3_thread_send to A with mode: auto and a neutral follow-up while the question waits.
   3. Observe the immediate steering and aborted tool result, then answer the original card.
   4. Check whether the answer reaches Claude, and whether the old request remains displayed or gets resolved after Claude stopped waiting.

   We have switched informational cross-thread messages to queue mode while user input is pending. No local T3 patch was installed.

   Nightly check on October 8: the newest published Nightly is v0.0.46-nightly.20261008.2819, commit 5e2225671f705fcd33f1ea5591b79ba612fb6974. I inspected both that tag's AskUserQuestion callback and its Linux x86_64 AppImage's packaged server bundle. The callback still races answers against the abort signal, removes the pending runtime entry, and returns denial when aborted. It emits no runtime-request cancellation after that wait. The packaged callback contains the same sequence. This is a check of shipped code, not a live reproduction after upgrading. The stale-request cancellation fix is not present at this callback.

   Packaged server SHA256: 310635e55d11b09ef92672c2ea71d44f017cab43b26a83586b16be6ab051cfa5. The stock AppImage SHA256 matches the GitHub asset digest. Our installed app remains the older 2702 Nightly.
3. MasterMann commented on Oct 16, 2026

   

   MasterMann

   on Oct 16, 2026

   Last edited by MasterMann

   More actions

   Still reproducible on v0.1.0 (stable, released 2026-10-15). Here it combined with #15136 / #15993 and left the thread stuck.

   Environment: server v0.1.0 (Linux x64, desktop AppImage backend), used remotely from the Windows desktop app v0.1.0; claudeAgent / claude-opus-5-5, full access.

   Sequence (UTC, from the provider event log and server trace):

   Time	Event
   15:24:23	AskUserQuestion (4 questions) shown
   15:24:32	Follow-up message offered with priority: "now" → SDK tool_result "Tool permission request aborted"; the card stays pending in T3
   15:25:08	Agent calls t3_worktree_handoff (with continuationPrompt); thread rebinds
   15:25:10	Outgoing query.close; run fails "The provider event stream closed unexpectedly"; composer shows "Waiting on background task mcp__t3-code__t3_worktree_handoff" (Stop does not clear it); the queued continuation never starts
   15:29:24	Answering the stale card → runtime-request.respond fails: OrchestrationV2DispatchCommandError: Provider session provider-session:provider-instance:claudeAgent:thread:<id>:<session> was not found. (shown as an error toast)

   So once a handoff detach has released the session, the stale request from this bug turns into a user-visible "Provider session … was not found" error, and the thread has no recovery path: the question can't be answered, Stop does nothing, and the queued continuation stays queued. The source matches what this issue describes: on abort, the AskUserQuestion branch in ClaudeAdapterV2.ts removes the request from pendingRuntimeRequests and emits no runtime_request.updated cancellation. dismissNativeUserInputs only cancels it on a terminal provider turn, and that turn never arrives here.

   No relevant changes between v0.1.0 and main (17e1087d3).

   ---

   Produced by Claude Code (Claude Opus 5.5) via t3 triage.

   
4. beardedarchitect commented on Oct 17, 2026

   

   beardedarchitect

   on Oct 17, 2026

   More actions

   Also hitting this regularly on the Windows 11 desktop app with Claude Opus 5.5. The trigger is a message from another T3 session (cross-thread send) arriving while an AskUserQuestion card is waiting for my answer. Claude then asks the same questions again, often 2–3 times in a row, and I have to retype my answers each time. No logs captured; reporting the frequency and the entry point.

   Claude Opus 5.5 via T3 Code
5. juliusmarminge commented on Oct 21, 2026

   

   juliusmarminge

   on Oct 21, 2026 – with GitCafe Production

   Member

   More actions

   Reproduced on current main (e27a03e): after a steer during AskUserQuestion, answering the stale card failed delivery. The question-only fix in https://git.cafe/pingdotgg/t3code/pulls/22803 cancels the aborted request before answering; the replacement question remains answerable. Runtime evidence and 204 passing adapter tests back this. Mobile, other adapters and remote/tunnel remain unverified.
6. whygee-dev commented on Oct 25, 2026

   

   whygee-dev

   on Oct 25, 2026

   More actions

   Same failure on command approval cards, which #22803 leaves out ("Approval requests and modes are unchanged").

   Environment: T3 Code (Beta) 0.1.2 desktop, macOS, claudeAgent provider, Claude Code 2.1.309 through the Agent SDK.

   A typed follow-up steered into the turn (priority: "now") while a Bash approval card is pending aborts the permission request, as described above for AskUserQuestion. The card stays live. Clicking Approve then fails delivery, yet the request is stored as approved, and nothing tells the user that the command never ran. #21158 does not cover this either: it only reroutes agent-originated sends, and this was a human steer.

   Sequence (UTC, 2026-10-25), from the provider event log, orchestration_v2_projection_runtime_requests and server.trace.ndjson:

   Time	Event
   00:30:45.180	Bash approval request created (kind: command)
   00:30:45.517	Follow-up offered with priority: "now"
   00:30:45.525	SDK tool_result "Tool permission request aborted", with tool_result_meta permission_decision: {decision: "reject", source: "user_abort"}
   00:30:48.859 to 00:30:50.373	Approve clicked on the still-live card: five No pending Claude runtime request failures in ClaudeAdapterV2.respondToRuntimeRequest
   00:30:49.035	Runtime request projected resolved with decision: "accept"; its approval_request turn item completed

   A second occurrence in the same thread: request created 2026-10-24 23:11:54.124, steer offered 23:12:11.676, aborted 23:12:11.688, projected resolved / accept at 23:12:12.143 (that trace has rotated out).

   Code path (0.1.2 bundle): the approval branch of canUseToolEffect awaits awaitClaudeApprovalDecision(decision, callbackOptions.signal) and, on exit, only deletes the entry from pendingRuntimeRequests in ensuring(...). Like the question branch before #22803, it emits no runtime_request.updated / turn_item.updated cancellation on abort, so the request stays pending until a click resolves it, and the click's decision is what gets projected.

   Steps to reproduce:

   1. In a Claude thread, have the agent run a Bash command that needs approval.
   2. While the card is pending, steer a follow-up into the turn.
   3. Click Approve on the card.

   Expected: the aborted approval card closes, as #22803 does for questions.
   Actual: the card stays; Approve fails delivery five times and the request is recorded as accepted.
7. m4littlemozarts commented on Oct 27, 2026

   

   m4littlemozarts

   on Oct 27, 2026

   More actions

   This one's pretty serious for multi-agent setups. Any cross-thread t3_thread_send that steers into a Claude thread with an open question cancels the question. Claude asks again, and the dead card stays answerable. Tonight, in the same minute, I answered 2 dead cards in one thread and 8 in another. The original report lists it as minor, but it breaks the whole ask-and-answer loop.

   Still reproduces on 0.1.3-nightly.20261027.3754 (Linux, claudeAgent, claude-opus-5-5). The new "Answer delivery not confirmed" notice shows up, but only after the answer has gone nowhere. Would love to see #22803 and #21158 land.

   Claude Opus 5.5 via T3 Code
8. shivamhwp commented on Nov 10, 2026

   

   shivamhwp

   on Nov 10, 2026

   Collaborator

   More actions

   [Fable 5.2][Claude Code] on behalf of shivam.

   Retested on main at 41443e5 (Linux, web dev client, Claude Haiku 5.5) and this no longer reproduces. Closing as fixed by #27320, merged as 41588d4.

   Steps: Claude ran a 40 second foreground command with a follow-up queued behind it, then asked the Red or Blue question. I clicked Send now on the queued message while the question was open.

   • The question Claude gave up on left the thread. Its runtime request went to cancelled at the moment of the steer.
   • Claude asked again, and that was the only question card shown.
   • I answered Red, the request went to resolved, and Claude replied You answered: "Red".
   • server.trace.ndjson has no No pending Claude runtime request failure.

   tool_use                        kind        status     created_at                resolved_at
   toolu_01F8nLpRNKc1651RVCDLD1hr  user_input  cancelled  2026-11-10T14:53:44.709Z  2026-11-10T14:53:53.426Z
   toolu_01EUEBHHBsQA5R3pKvgoJPvV  user_input  resolved   2026-11-10T14:53:55.814Z  2026-11-10T14:54:50.205Z
   

   One run, on the web client only. Not checked: the desktop app, mobile, and a steer sent from another thread with t3_thread_send.

   
   
9. shivamhwp

   closed this as completedon Nov 10, 2026