[BUG] `AskUserQuestion` breaks after a web/async session resume - either aborts instantly ("Tool permission stream closed before response received") or must be answered 2–7× before it registers

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Claude Code for web (the cloud/async product at claude.ai/code, where sessions run in a remote container and can be suspended and resumed), AskUserQuestion breaks after a session has gone idle / been suspended and resumed. It fails in one of two ways, and I hit both:

• Mode A — instant abort: the tool call fails immediately with "Tool permission request failed: AbortError: Tool permission stream closed before response received", and my answer never reaches the model. The chips may still render, so I can click an option or type a reply, but the call has already aborted, so my input silently vanishes — it just looks like my answer disappeared. Retry fails identically.

• Mode B — re-ask loop: the same question is re-presented after I answer. I answer again, it reappears, and it typically takes 2–7 attempts before the answer sticks and the run continues. (This is #70648.)

Which mode I get varies by occurrence; the common trigger is always an idle/suspend gap before I answer. In a fresh session, or when I answer promptly before the session goes idle, AskUserQuestion works on the first try every time.

What Should Happen?

Answering an AskUserQuestion once should register the answer and continue the run, regardless of how long the session was idle before I answered. On resume, the interactive permission/answer back-channel should be re-established (or lazily re-established on demand) so the tool renders, waits, and returns my answer exactly once. A pending question should be recognized as already-presented after reconnect — not re-delivered against a stale context (Mode B), and not aborted before my answer can land (Mode A). If the channel genuinely can't be restored, the tool should surface a catchable error so the agent can fall back to an inline text question — never silently drop my input.

Error Messages/Logs

Tool permission request failed: AbortError: Tool permission stream closed before response received

(Mode A only. Mode B produces no error — the prompt simply reappears until an answer sticks.)

Steps to Reproduce

1. Start a session at claude.ai/code (cloud/async).
2. Get the assistant to a point where its next action is an AskUserQuestion (the multiple-choice chips) — e.g. give it a task that will make it ask a clarifying question.
3. Let the session go idle / be suspended long enough that the connection drops (step away, lock the screen, switch tabs, or resume it later). Confirm resume via the injected "Resumed session" / "Continue from where you left off" turns in the transcript.
4. Come back and answer by selecting an option.
5. Observe one of:

• Mode A: the tool aborts instantly with the error above; retry fails identically; my answer never lands.
• Mode B: the same question is re-presented; I must answer 2–7 times before it registers.

Control (confirms idle/resume is the trigger): repeat steps 1–2 but answer the prompt immediately, without going idle. It registers on the first try every time. Both failure modes only appear when there's an idle/resume gap before answering. Neither reproduces on a purely local/CLI session.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — Claude Code for web (cloud/async at claude.ai/code). No CLI version string available; claude --version doesn't apply to the web surface.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Surface: Claude Code Web / cloud (remote) session. "Platform: Anthropic API", "OS", and "Terminal: Other" above reflect the browser's host machine — the actual surface is the web/cloud app, not the CLI. Does NOT reproduce on purely local/CLI sessions.

Likely root cause (hypothesis): AskUserQuestion is a blocking call held open while it waits for input, and it needs a live interactive back-channel to the client to render options and return the answer. Cloud sessions run in ephemeral containers behind a WebSocket; on idle the connection drops and the container suspends. On resume that channel isn't correctly re-bound to the pending call — so the call either aborts (Mode A) or is re-delivered against a stale/torn-down context (Mode B). Looks like the shared permission-channel infrastructure implicated in #59024 and #59707, combined with the cloud idle-disconnect / stale-reconnect handling in #70648.

Related issues:

• #70648 — web/cloud + idle/resume + AskUserQuestion re-ask loop (Mode B); closed as duplicate. This report consolidates it with the instant-abort variant.
• #59024 — same "permission stream closed before response received" string, VS Code.
• #59707 — same error string, Cowork; argues it's shared permission-channel infrastructure.
• #44435 — same error string with a SessionStart:resume race (different root cause).
• anthropic-sdk-typescript #854 — same error string from a ~60s permission-wait timeout.
• #23081 — retry after connection loss reuses a stale connection pool (related reconnect state).
• #47841 — Claude Code Web stream idle-timeout (related web idle disconnect).

Workarounds (but not really) I've found:

• Answering the prompt promptly, before the session goes idle, avoids both modes.
• Starting a fresh session (rather than resuming) for question-heavy work avoids it.
• Having the assistant ask clarifying questions as plain text instead of AskUserQuestion in resumed sessions sidesteps it entirely.