[BUG] Cowork (macOS): pending AskUserQuestion dialogue is lost when the user switches to another chat or artifact view, with no respawn path, and the agent is told the user rejected it

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 Cowork mode on the Claude desktop app (macOS), an AskUserQuestion dialogue renders correctly, but if the user clicks into another chat in the sidebar, or into an artifact window, before answering, the dialogue is gone when they return. There is no UI element to reopen it and it is not re-rendered from transcript state.

Worse, the agent side receives a response equivalent to "the user doesn't want to proceed with this tool use". A view teardown is being reported to the model as a deliberate user rejection. The user never saw an option to decline; they clicked into another view. The agent then behaves as if the question was refused, which is false, and the user has to notice the dialogue is missing and ask the agent to re-issue it.

Re-issuing works every time: an identical AskUserQuestion call sent fresh renders and completes normally. So the tool and payload are fine; the pending dialogue's lifecycle is tied to the live view and does not survive navigation.

Observed repeatedly across two sessions on this account (four or more occurrences), always after a view switch while a dialogue was pending. An earlier session on 08/08 logged the agent-side error "AbortError: permission stream closed" on two consecutive calls with the same user-side symptom.

This is distinct from the closest existing reports:

• #61665: same loss mechanism (view change kills the dialogue, no respawn path) but filed for the VS Code extension moving a chat tab to a new window. This report shows the same defect on the Cowork desktop surface with an ordinary chat switch, no window management involved.
• #59707: Cowork macOS, but there the dialogue never renders at all. Here it renders and is then lost.
• #58750: Cowork macOS, card never reaches the renderer; on app quit the pending request resolves as "Dismissed". Consistent with the same lifecycle defect, different trigger.
• #60042: AskUserQuestion failing when batched with other tool calls. Also encountered on this account and avoided by dispatching solo; the occurrences reported here were solo calls.

What Should Happen?

Any of, in order of preference:

1. The pending dialogue persists in the transcript like ordinary messages and re-renders when the user returns to the session.
2. The dialogue respawns automatically on view restore, or the session shows a visible "question waiting" affordance that reopens it.
3. At minimum, the agent receives a distinct, truthful signal ("dialogue dismissed by view change, no user input") so it can re-issue automatically, rather than a response indistinguishable from the user deliberately declining.

Error Messages/Logs

User-facing: dialogue rendered, then absent after switching views. No error, no toast, no pending indicator.
Agent-facing (16/08 occurrences): the tool call resolves as a user rejection ("The user doesn't want to proceed with this tool use") despite no user input.
Agent-facing (08/08 occurrences, same user-side symptom): AbortError: permission stream closed

Steps to Reproduce

1. Open a Cowork session on macOS with at least one other chat in the sidebar (or a live artifact such as a dashboard).
2. Have the agent call AskUserQuestion, dispatched solo (not batched with other tool calls, to exclude #60042).
3. Confirm the dialogue renders.
4. Without answering, click into another chat or the artifact window.
5. Click back into the original session.
6. Observe: the dialogue is gone, nothing reopens it, and the agent has received a rejection-shaped response.
7. Ask the agent to re-issue the question: the fresh call renders and completes normally.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

n/a (Cowork in the Claude Desktop app, macOS; client version not visible from inside the session)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

The rejection masquerade is the part worth prioritising even if the persistence fix is larger: the model is being given false information about user intent. Agent workflows that treat a rejection as a meaningful answer (skip this step, do not ask again) will silently take the wrong branch after every accidental view switch.

The duplicate detector surfaces #65382, which is related but distinct: there the webview loses connectivity, the dialogue never renders, and the bridge auto-denies pending requests on session stop (its logs show "Bridge resolving permission: behavior=deny (tool: AskUserQuestion)"). That bridge auto-deny looks like the same mechanism behind the rejection-shaped response reported here, but in this report the connection is healthy, the dialogue renders successfully, and the trigger is an ordinary chat or artifact switch with no app restart needed. Cross-references: #61665 (same loss-on-view-change, VS Code surface), #59707 (Cowork, never renders), #58750 (Cowork, pending resolves as Dismissed on quit), #60042 (parallel-batch failure, excluded here by solo dispatch).

Model in the affected sessions: Claude Fable 5 (16/08 occurrences) and Opus 5 (08/08 occurrences), same account.