Sign up
View stargazers13Sign up

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

opened20d agobyTtiliakoos

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. Start a Claude thread: "Run the shell command sleep 30 in the foreground. When it finishes, use the AskUserQuestion tool to ask me which color to pick, with the options "Red" and "Blue". After I answer, quote my answer exactly."
  2. While the command runs, type a follow-up and press Enter. With the default follow-up behaviour it is queued.
  3. When the question appears, click Steer on the queued message.
  4. Answer the question that is shown first.

Expected behavior

The question Claude gave up on closes in T3 Code, so only the question Claude is waiting on is shown, and answering it reaches Claude.

Actual behavior

The steer aborts the pending tool permission request. The SDK returns tool_result "Tool permission request aborted" (is_error), Claude reads the steered message and asks the same question again as a new request. T3 Code keeps the aborted request pending, so the thread shows two questions. Answering the stale one marks it resolved, but the server logs No pending Claude runtime request …, Claude never gets the answer, and the real question still waits. Nothing tells the user.

In ClaudeAdapterV2.ts, the AskUserQuestion branch of the permission callback races the answer against the abort signal. On abort it removes the request from pendingRuntimeRequests and returns deny, but it emits no runtime_request.updated that cancels the request, so the projection never leaves pending.

Impact

Minor bug or occasional failure

Version or commit

upstream/main at ee7b49d638, dev desktop app

Environment

macOS 27, T3 Code dev desktop app, Claude Fable 5.1 through the Claude Agent SDK

Logs or stack traces

Provider events for the thread (trimmed):

105:45:16.671 outgoing prompt.offer {"content":"PROBE2: queued before the question, steered while it is pending.","priority":"now"}
205:45:16.704 incoming tool_result {"content":"Tool permission request aborted","is_error":true,"tool_use_id":"toolu_0149MNMxsZ7jF7UxaZcK6of1"}
305:45:21.016 incoming assistant thinking: "…the color question got aborted before you answered… I'll ask it again."
405:45:21.023 incoming tool_use AskUserQuestion toolu_01E98pK64FFo5cdGAAHhgMgk

orchestration_v2_projection_runtime_requests afterwards: both toolu_0149… and toolu_01E9… are user_input / pending. After answering the first: toolu_0149… resolved, and server.trace.ndjson holds five No pending Claude runtime request runtime-request:…toolu_0149… failures.

Related

  • #11116: found while verifying the fix, where a message can be sent while a question is pending.
  • #14496 (open) reports failed answer deliveries, which would make the stale answer visible but would not close the aborted request.

Claude Opus 5.5 via T3 Code

WWhiteWarrior62515d ago
Synced from GitHub

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 offerAborted tool result
15:18:10.81215:18:10.821
15:32:47.15315:32:47.166
15:33:19.68115:33:19.693
15:34:34.11515:34:34.126
15:35:23.34415: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.

MMasterMann7d ago
Synced from GitHub

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):

TimeEvent
15:24:23AskUserQuestion (4 questions) shown
15:24:32Follow-up message offered with priority: "now" → SDK tool_result "Tool permission request aborted"; the card stays pending in T3
15:25:08Agent calls t3_worktree_handoff (with continuationPrompt); thread rebinds
15:25:10Outgoing 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:24Answering 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.

Image
Bbeardedarchitect7d ago
Synced from GitHub

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

JJulius Marminge3d ago

Reproduced on current main (e27a03e94d): after a steer during AskUserQuestion, answering the stale card failed delivery. The question-only fix in #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.