claude-code - 💡(How to fix) Fix [BUG] Remote Control session in-browser failed to render AskUserQuestion UI - session is now completely stuck [1 participants]

Preflight Checklist

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

What's Wrong?

Summary

Using /remote-control from a browser, AskUserQuestion has rendered correctly for me many times. In a single instance, it failed to render, and the session is now permanently wedged — Claude is waiting on an answer I have no way to provide from the browser side.

I want to flag this less as "AskUserQuestion is broken" (it is not, in my experience) and more as: a single transient render failure is enough to nuke a remote-control session, because there is no cancel/abort affordance for a pending tool prompt.

What Should Happen?

Either of these would have made this recoverable from the browser:

• A "cancel pending question" / "abort tool call" affordance in the remote-control UI, usable when a tool prompt fails to render or the user otherwise needs to bail out.
• A way to forcibly send a new user message that supersedes the pending tool-prompt wait.

The first feels like the more general fix and would also cover similar classes of stuck-state bugs (see "Related" below).

Error Messages/Logs

Steps to Reproduce

What I think may have happened

I cannot confirm cause and effect. What I know:

• AskUserQuestion has worked correctly across many prior turns in this and other sessions.
• Around the moment of the failure, I sent a message to the session.
• I do not know whether my message went out before, after, or concurrent with an AskUserQuestion call from the agent.

A plausible (but unverified) hypothesis: a race between a client-sent user message and an agent-initiated AskUserQuestion, where one side ends up waiting on the other. I'm not asserting this is the cause — just naming it as the only nearby anomaly I can point at. It could equally be an unrelated render glitch.

Why this is worth filing regardless of root cause

Even if the underlying render/race bug is rare, the lack of any escape hatch turns a transient failure into total session loss. The only documented recovery is to kill the host-side claude process and /resume, which requires physical access to the host machine. I'm currently 3 days away from that host, and the session is unusable until I return.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related

This is a new instance of a recurring "remote-control UI gets stuck with no escape" pattern, not a duplicate of any of the below:

• #54922 — same wedge shape, but triggered by a permission prompt ("allow for session" option) on Linux. Different tool, different trigger.
• #53630 — MCP permission popup never renders in Claude-in-Chrome (closed completed). Adjacent shape, different surface and tool.
• #54528, #53470 — cloud-container setup hangs with no cancel option. Different trigger; same missing escape hatch.

A generic "cancel pending tool prompt from the remote-control UI" affordance would mitigate this whole class regardless of which underlying render/race bug caused any individual wedge.

Here's a screenshot of the stuck session: <img width="1002" height="642" alt="Image" src="https://github.com/user-attachments/assets/de6036ae-197c-4e57-87ad-e5cd489fe0bd" />

Regarding the screenshot: -Yes I have tried clicking the "⌄" chevron next to "Asking Next step"- nothing happens -Yes I have tried refreshing the browser -Yes I have tried hard refreshing the browser -Yes I have tried a different browser -Yes I have tried a different device

Furthermore, I have a second terminal running on the host machine, also being remote controlled - that session is fine and still responsive, so there is no issue on the host device. This is a specific AskUserQuestion bug.