[BUG] AskUserQuestion tool call consistently interrupted ("Tool execution was interrupted")

Reproduced on macOS, so this is not Windows-only. Suggest dropping platform:windows (or adding platform:macos) and removing stale.

Environment

• macOS 15 (Darwin 25.6.0), Apple Silicon
• Claude Code 2.1.234, running as the Claude Code session inside the Claude desktop app (not Cowork/LAM, so this is distinct from #58750)
• Model: Opus 5

Symptom is identical to the original report: the widget never renders, the model receives [Tool result missing due to internal error], and the UI shows "Tool execution was interrupted."

Forensics, which the original report did not have:

1. The call is emitted but never answered. In the session JSONL, the AskUserQuestion tool_use block is written, and there is no matching tool_result block at all. The transcript jumps straight to the next tool call:

2026-08-19T13:31:21.215Z  tool_use  AskUserQuestion
2026-08-19T13:33:39.057Z  tool_use  Bash

So the CLI emitted the call and the host never returned a result. It is not a malformed answer, it is a missing one.

1. The host never opened the permission channel. The desktop app routes AskUserQuestion through the tool-permission transport. In ~/Library/Logs/Claude/main.log, working calls look like this:

19:56:06 [info] Emitted tool permission request c1c1250e-... for AskUserQuestion in session local_5f169b30-...
20:07:44 [info] Received permission response for c1c1250e-...: once (tool: AskUserQuestion)

On the day of the failing run there are 9,465 log lines and zero Emitted tool permission request ... for AskUserQuestion. The last successful ones are from the previous day, and all of them are in local_* agent-mode sessions.

1. The failing session runs non-interactively with permissions skipped. Process args for the session that failed:

claude --output-format stream-json --input-format stream-json \
       --permission-prompt-tool stdio --permission-mode auto \
       --allow-dangerously-skip-permissions ...

The working local_* sessions from the day before go through the permission-request path; this one does not. That looks like the discriminator: when the permission channel is bypassed, AskUserQuestion has no transport left and its result is simply never produced.

1. PostToolUse does not fire on this path, so hook-based fallbacks cannot catch it. Because no tool_result is ever written, a PostToolUse hook matching AskUserQuestion is never invoked. Anything relying on that hook to detect the failure and degrade gracefully is silently dead. Worth confirming whether that is intended.

Impact: any skill or flow that opens with a clarifying question stalls, and the failure is invisible to hooks, so it cannot be worked around locally. The only workaround is to stop calling the tool and render decisions as prose.

Historical rate on this machine, across local transcripts: 380 AskUserQuestion calls, 374 returned normally. The failures cluster in this surface, plus two older AbortError: Tool permission stream closed before response received, which looks like the same missing-transport failure caught at a different point.

Follow-up negative result, since it rules out the most obvious first guess.

A full app restart does not fix it. I quit the desktop app entirely (not just closing the window), relaunched, confirmed a fresh CLI process, and called AskUserQuestion again in a new session. Identical failure: [Tool result missing due to internal error], no widget, no tool_result block in the JSONL.

Critically, after the restart ~/Library/Logs/Claude/main.log still shows the same 12 Emitted tool permission request ... for AskUserQuestion entries it had before, all from earlier local_* agent-mode sessions. Not one new request was emitted for either failing call. So the host is not losing the response, it never opens the channel in the first place.

This matters because it points away from renderer or IPC state, which is where the sibling Cowork report #58750 leads. Fresh processes, fresh renderer, same failure. Whatever is missing is in the routing decision for this session type, not in leftover state.

Local misconfiguration is also ruled out: the failing session is launched without --disallowedTools AskUserQuestion, while the app's own background sessions on the same machine are launched with it. The tool is enabled in exactly the session where it never returns.

Controlled comparison on the same machine, same day: Cowork works, Claude Code does not.

This narrows the surface considerably, so it is worth recording precisely.

On 2026-08-19, on one macOS machine, one app install, one account:

| Time | Surface | Session id | Emitted tool permission request ... for AskUserQuestion in main.log | Result |
|---|---|---|---|---|
| 13:31 | Claude Code in the desktop app | 55114259-... (plain uuid) | absent | failed, [Tool result missing due to internal error] |
| 15:35 | Claude Code in the desktop app, after a full app restart | plain uuid | absent | failed, identical |
| 22:22 | Cowork | local_6d59b5e4-... | present, response received 22:45 | worked normally |

That 22:22 entry is the only AskUserQuestion dispatched in the entire day's log.

Two things follow.

1. It is not the app, the account, the OS, or the install. Same binary, same user, same machine, hours apart. Only the session type differs. Whatever is broken lives in the Claude Code session path specifically, not anywhere shared.

2. Every dispatch I can find in these logs, working or not, correlates with the session id prefix. All emissions come from local_* sessions (agent-mode / Cowork). Sessions identified by a plain uuid never emit. I cannot see the app's internals to say whether the request handler is genuinely keyed on session type or whether that is coincidence, but the correlation is clean across every sample I have.

This also supplies the positive control for the log-line signal I described in my comment on #46767. There I only had the negative half, the line's absence on failures. Here the same line appears on a success and is absent on failures, same day, same machine. It is a reliable dispatch indicator.

Incidentally, the 22:22 question was answered 23 minutes later and still returned fine, so no timeout is involved. That rules out the timeout-and-dismiss behaviour discussed elsewhere.

Some observations from the shipped desktop app bundle (Claude.app/Contents/Resources/app.asar, app 1.32885.1) that may point at where to look. Offered as a pointer, not a diagnosis: the code is minified and I could not run the CLI standalone to confirm, so treat the hypothesis at the end as unproven.

There are two permission managers, not one. Both emit the identical Emitted tool permission request ... for ${tool} in session ${id} line, but they are distinct code paths, distinguishable by their telemetry:

• one tags lam_tool_permission_requested with session_type: p ?? 'cowork' (the agent-mode / Cowork manager, logging as [LocalAgentModeSessionManager])
• the other tags it with a literal session_type: 'ccd' (the Claude Code Desktop manager, logging as [CCD] / [LocalSessionManager])

This matters for the log evidence in my earlier comment: the CCD manager exists and does emit for other tools, so the missing line on failing AskUserQuestion calls means that code is never reached, rather than the surface having no permission plumbing at all.

The CCD handleToolPermission has several early returns before the emit. Reading them in order: a session-permission-rules allow, an alwaysAllowedReasons cache hit (desktop_ccd_permission_decisionreason_cache_hit), a scheduled-task auto-approve, and a remote-dispatch auto-deny. At least two of these are guarded by a tool-name predicate (minified, so I cannot name it) that appears to exempt certain tools from being auto-resolved. Whatever that predicate covers, AskUserQuestion in this configuration is not getting as far as the emit.

The asymmetry that looks most suspicious. The app already has the concept of tools that cannot work without a renderer. In the Cowork manager there is an explicit branch:

[LocalAgentModeSessionManager] ${bridge ? 'Bridge' : 'Dispatch child'} session: disabling renderer-dependent tools

which appends a predefined list to disallowedTools for sessions that have no renderer attached. The CCD spawn path has no equivalent. The only place it touches AskUserQuestion is:

i.scheduledTaskId && (L.disallowedTools = ['AskUserQuestion'])

So the "this session cannot render, do not offer renderer-dependent tools" protection exists on one path and not the other, and on the CCD path AskUserQuestion stays enabled in exactly the session type where it never renders. That is consistent with what I observe from the outside: the tool is advertised to the model, the model calls it, and nothing downstream can service the call.

Where the sentinel is produced. In the CLI binary, [Tool result missing due to internal error] sits inside the block of permission-outcome strings, adjacent to User rejected tool use and Permission for this action was denied by the Claude Code auto mode classifier. So it is emitted on the permission/tool-result path, not from a generic error handler.

Unproven hypothesis: in a CCD session the AskUserQuestion request is resolved or dropped before the emit, no card is ever created, and the CLI (running headless under --output-format stream-json) has no way to render the question itself, so no result is produced. This fits every external observation: fully deterministic, no log line, unaffected by a full app restart, and working normally in Cowork on the same machine minutes apart.

I could not close the loop empirically. Running either CLI standalone with the same flags fails at Failed to authenticate: OAuth session expired and could not be refreshed, since the app injects the host auth token, so I could not observe whether the CLI emits a control_request for AskUserQuestion under these flags. That single observation would settle whether this is a CLI dispatch problem or a host handling problem. If someone with a working harness can check it, that seems like the fastest next step.

Root cause found and filed as #88087, with the exact function in the app bundle and a proposed fix on both sides.

Short version: the CLI surfaces AskUserQuestion as a request_user_dialog of kind permission_ask_user_question, and the desktop app's CCD UserDialogBroker hard-cancels every dialog kind except refusal_fallback_prompt (first line of createOnUserDialog). Instant {behavior:'cancelled'}, no log, no card, tool aborts, no tool_result, sentinel synthesized. Fully deterministic, which matches this thread exactly.

Since the new issue carries the diagnosis, maintainers may prefer to track there and close this one as a duplicate; the forensic history (macOS repro, restart test, Cowork-works-CCD-fails comparison) lives in this thread's comments.