[BUG] Desktop macOS host sessions: AskUserQuestion permission request is never emitted — every call orphans the tool_use and aborts the turn

Environment

• Claude Desktop 1.24012.1, macOS (Apple Silicon), Darwin 24.5.0
• Claude Code SDK 2.1.217 (desktop-pinned), session spawned with --permission-prompt-tool stdio, CLAUDE_CODE_CHILD_SESSION=1, entrypoint claude-desktop
• Reproduced 7/7 times across: app restart, plan mode on/off, minimal single-question payload, solo (unbatched) tool_use
• Re-verified 2026-07-27 (3 days after first repro, same app/SDK versions): raw call with all user hooks removed from the AUQ matcher fails identically; main1.log gained 641 lines during the test window with zero AskUserQuestion/permission entries

Symptom

Every AskUserQuestion call in a Desktop host session (local agent mode on the macOS
filesystem, not Cowork VM) fails instantly. UI shows Asked <header> — Stopped / Tool execution
was interrupted and renders the raw questions JSON as text. The model receives
[Tool result missing due to internal error]. All other tools work normally in the same session.

Evidence (from local logs + session transcript)

1. The permission request is never emitted for AUQ, only for other tools. In the same session,

main.log shows Emitted tool permission request … for Bash in session local_f03ddb40…
seconds around the failing AUQ calls — but there is zero Emitted … for AskUserQuestion
for this session.

1. Perfect host/VM split across the whole log history: 106 Emitted … for AskUserQuestion

lines exist; all 17 distinct sessions are Cowork-VM sessions (Starting local session … in
/home/…). No host session (in /Users/…) has ever emitted one.

1. Transcript: all 6 AUQ tool_use blocks have no tool_result at all (not even an error

result). The PreToolUse hook pipeline completes normally (hook_success, then
hook_deferred_tool), after which the trail ends. The [Tool result missing…] string is
synthesized later by ensureToolResultPairing when the orphaned call is repaired
(binary references inc-4977 for this repair path).

1. No [CCD] Auto-denying, no desktop_ccd_permission_auto_denied, no

Bridge/Dispatch child session: disabling renderer-dependent tools lines for this session —
the documented deny/disable paths did not fire (or did not log).

1. Ruled out locally: user hooks (pipe-tested, return valid defer), plan mode, payload shape,

batching (#60042 — calls were solo), Node version (#36048 — Node 26), app restart.

Expected

Either the AUQ permission request reaches the renderer and the question card renders (as in
Cowork VM sessions), or the call fails cleanly with a paired error tool_result so the model
can fall back to asking in prose — instead of an orphaned tool_use plus turn abort.

Related

#58750 (Cowork: card never reaches renderer — but there the request IS emitted), #62159 (dup),
#26940, #59707, #12672, #46767. This report adds: on host sessions the failure is earlier —
the request never reaches the emit step at all — and it is 100% deterministic, not flaky.

Workaround we deployed

A PreToolUse hook that denies AskUserQuestion with an instruction to ask in prose when
CLAUDE_CODE_ENTRYPOINT=claude-desktop — converts the orphaned-call/turn-abort into a clean,
paired deny. Confirmed working.