[BUG] AskUserQuestion form destroyed by window resize (Claude Desktop app)

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?

In the Claude Desktop app on macOS, an AskUserQuestion form is destroyed when the
application window is resized, and there is no way to get it back. The turn stays
open waiting on an answer to a form that no longer exists on screen. The session is
effectively stuck: the assistant is waiting for input the user cannot give.

This happened twice in one working session, both times for the same reason — and the
reason matters, because it makes the bug self-inflicting:

1. The form renders and occupies a large share of the readable area.
2. The explanatory text the form is asking about is above the form, and is now

unreachable — you cannot scroll back past the form to read it.

1. So you enlarge the window in order to read it.
2. The act of enlarging the window destroys the form.

In other words, the natural remedy for the layout problem triggers the state-loss
defect. That second-order relationship is why I am filing this as one report.

There is no recovery path from either side. The user cannot redisplay a pending
question. The assistant cannot redisplay it either — there is no "re-show" operation
available to it; the only thing it can do is issue a brand new form, which is not the
same call and, in my session, did not render at all (see below). I asked three times
in plain text for the form to be shown again and there was no mechanism by which that
request could be satisfied.

Second, possibly related symptom. After the above had happened and I had sent
interrupt messages in the same turn, a subsequent, deliberately very small form
(one question, three short options) never rendered at all — no form, no error, and
the turn ended up cancelled. This is worth noting because it rules out "the form was
too large to display" as the explanation for that instance, and points instead at the
form being torn down rather than mis-laid-out.

What Should Happen?

1. The form must survive a window resize. A re-layout should re-render the pending

question, not discard it.

1. If it cannot survive, it must be recoverable — the pending question should

re-appear automatically once the layout settles, or there should be an explicit way
to recall the outstanding question (a control in the UI, and/or the ability for the
assistant to re-present it).

1. The turn should not be left waiting on a form that no longer exists. If the form

is genuinely gone, the tool call should fail visibly so the assistant can fall back
to asking in plain text, rather than both parties waiting on each other.

Error Messages/Logs

None. No error is shown in the UI when the form disappears. That is part of the
problem — the failure is silent and looks like the assistant has simply stopped.

Steps to Reproduce

1. Open a session in the Claude Desktop app on macOS.
2. Get the assistant to ask a multiple-choice question via AskUserQuestion — e.g.

*"Give me a few paragraphs comparing three approaches, then ask me which one to
take as a multiple-choice question with option descriptions."*

1. When the form appears, note that it covers much of the readable area and that you

cannot scroll back above it to re-read the explanation.

1. Resize the application window (I enlarged it) while the form is displayed.
2. The form disappears. The turn remains open, waiting for an answer. There is no way

to bring the form back, and no error is shown.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.212 (Claude Code)

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Which terminal are you using?
Claude Desktop app — not a terminal session
Claude 1.28929.0 (d1a6bc) 2026-08-11T18:58:06.000Z
On existing issues, and why I do not believe this is a duplicate.

• #61665 is the closest existing report: the AskUserQuestion UI disappears with no

ability to respawn it, leaving the agent "paused in an incomplete state." It is the
same failure class, but a different surface and a different trigger — the VS Code
extension, and moving the chat tab into a new window. This report is the desktop
app, triggered by an ordinary window resize, which is a far more common action.
Note that #61665's reporter also performed his window operation *because the form was
covering the chat* — the same causal chain described above, from a different user.

• #64776 (closed as not planned), #62390, and per that reporter #23862 and

#57142, all describe the layout complaint: the question panel hides the message.
I am not re-filing that. This report is about state loss and a stalled turn, which
is a functional defect rather than a layout preference. The layout issue appears here
only as the thing that makes users resize the window in the first place.

Impact. For workflows where the assistant is instructed to route decisions through
AskUserQuestion, this is not cosmetic. In my session it cost several exchanges, and
the working fallback was to abandon the tool entirely and have the assistant ask in
plain prose — which loses the structured-choice UI the tool exists to provide.