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

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

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."
While the command runs, type a follow-up and press Enter. With the default follow-up behaviour it is queued.
When the question appears, click Steer on the queued message.
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):

05:45:16.671 outgoing prompt.offer {"content":"PROBE2: queued before the question, steered while it is pending.","priority":"now"}
05:45:16.704 incoming tool_result {"content":"Tool permission request aborted","is_error":true,"tool_use_id":"toolu_0149MNMxsZ7jF7UxaZcK6of1"}
05:45:21.016 incoming assistant thinking: "…the color question got aborted before you answered… I'll ask it again."
05: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.

[Bug]: Incoming agent questions replace an unfinished message and redirect subsequent typing #11116: found while verifying the fix, where a message can be sent while a question is pending.
fix(server): show when an answer's delivery to the provider fails #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

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

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

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:

In Claude thread A, ask a color question with Red and Blue choices and wait for the card.
From thread B, call t3_thread_send to A with mode: auto and a neutral follow-up while the question waits.
Observe the immediate steering and aborted tool result, then answer the original card.
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.

Navigation Menu

Repository navigation

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

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Related

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Related

Activity

WhiteWarrior625 commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions