[BUG] Desktop App (Cowork/local agent mode): AskUserQuestion never renders — hangs until session stop auto-denies (regression since 2026-06-03; re-filing locked #26940)

Confirming this regression persists on the latest build, with a slightly different surface symptom (overlaps #27353).

Environment

• Claude Desktop (macOS): 1.11187.4
• Claude Code: 2.1.169 (latest, 2026-06-08)
• macOS: 26.4.1 (25E253)
• First observed: ~2026-06-08

Symptom variant

When the agent calls AskUserQuestion mid-task, the Desktop app does not render the interactive modal. It shows Requested + the question header chip, then dumps the raw questions: [...] JSON payload as plain text, and the turn ends with Tool execution was interrupted. The task halts.

The identical flow renders and works correctly in the terminal CLI (claude), so this is specific to the Desktop UI bridge, not Claude Code core.

This is on a newer Desktop build (1.11187.4) than the original report (1.9659.4 / 1.10628.2) and the latest Claude Code (2.1.169) — so it is not fixed as of 2026-06-08.

Repro shape

Sanitized but structurally identical to the failing call: 2 questions, multiSelect: false, 3 options each, long non-ASCII (Korean/CJK) descriptions.

{
  "questions": [
    {
      "question": "범위를 어떻게 설정할까요?",
      "header": "생성 범위",
      "multiSelect": false,
      "options": [
        {"label": "옵션 A 먼저", "description": "가장 안전한 경로로 한 건만 끝까지 검증한 뒤 확장합니다. (긴 한글 설명)"},
        {"label": "중간 규모 6건", "description": "두 축의 조합으로 중간 규모를 진행합니다. (긴 한글 설명)"},
        {"label": "전체 12건 일괄", "description": "가장 공격적으로 전체를 일괄 생성합니다. (긴 한글 설명)"}
      ]
    },
    {
      "question": "링크 처리는 어떻게 할까요?",
      "header": "트래킹 링크",
      "multiSelect": false,
      "options": [
        {"label": "먼저 연동", "description": "생성 전에 파트너 연동을 끝내고 링크를 확보합니다. (긴 한글 설명)"},
        {"label": "링크 없이 생성", "description": "트래킹 없이 먼저 생성하고 이후 부착합니다. (긴 한글 설명)"},
        {"label": "이미 있음", "description": "이미 확보한 링크를 직접 제공합니다. (긴 한글 설명)"}
      ]
    }
  ]
}

CLI renders this fine; only Desktop fails. Happy to attach a screenshot or session logs if useful.

Corroborating datapoint — newer build (Desktop 1.11847.5 / embedded runtime 2.1.170), plus a client-side elimination matrix that supports the server-side framing in the issue body

Following up on my 2026-06-09 comment. The regression persists, and on this newer build the failure signature has moved further upstream, which I think strengthens the "remotely-served frontend / server-evaluated flag" thesis in the original report.

Environment

• Claude Desktop (macOS): 1.11847.5
• Embedded runtime (the binary the app actually launches, per ps): 2.1.170 — auto-updated from 2.1.165 since onset; symptom unchanged across every version in between
• macOS 26.x arm64
• Cowork / local agent mode, 7 plugins loaded (main.log: Passing 7 plugin(s) to SDK), remote-control session

What changed since 2026-06-09

On 1.11187.4 I saw AUQ emit a permission request that never surfaced, then dump raw questions: […] JSON and end with Tool execution was interrupted.

On 1.11847.5 it's quieter and more telling. When the agent calls AskUserQuestion:

• main.log logs no Emitted tool permission request line for AUQ at all — whereas ExitPlanMode on the same day, same machine logs Emitted tool permission request … for ExitPlanMode normally (3×). So this is AUQ-specific, not a generic permission-pipeline outage.
• The renderer log (claude.ai-web.log) contains the string AskUserQuestion zero times, ever.
• The turn closes as healthy cycle (hadFirstResponse=true) — i.e. the runtime thinks everything is fine while the AUQ tool_result is silently dropped, leaving an orphan tool_use. UI shows only Requested → Stopped.

This matches the issue body's "the channel is selectively dead for AUQ only" observation, and #65382's "agent layer stays healthy, only the webview drops state."

Client-side elimination matrix (every lever, all reproduce identically)

| Variable tested | Action | Result |
|---|---|---|
| Embedded runtime version | auto-updated 2.1.165 → 2.1.170 | no change |
| Network / asset fetch | on-host TLS-inspection layer allowlisted 1st-party domains → cold TLS handshake 1.0–3.5s → 0.08–0.17s (~20×) | no change; zero Failed to fetch/QueryClient errors at failure timestamps |
| MCP connector | removed a local MCP server (127.0.0.1) + full restart | no change |
| App restart | Cmd+Q full quit + relaunch | no change |
| Session state | brand-new Cowork session (no accumulated orphans) | no change |

Onset timing supports a staged rollout

My onset is ~2026-06-08/09; the original report's is 2026-06-03. Two machines, different onset dates, identical symptom, no correlated client/binary change on either — consistent with a cohort-staged server-evaluated change rather than anything local. That, plus the fact that no client-side variable above moves the needle, is why I believe the root cause is server-side (remotely-served Cowork frontend code or a server-evaluated feature flag), exactly as the issue body argues with the 06-03 10:15–12:38 UTC change window.

Note on --safe-mode

For anyone tempted to test CLAUDE_CODE_SAFE_MODE=1: it only disables runtime-side customizations (CLAUDE.md/plugins/skills/hooks/MCP). If the broken layer is the remotely-served webview surface, safe mode won't change AUQ rendering — confirmed inert here.

Happy to provide masked log excerpts (permission-emit lines for the AUQ vs ExitPlanMode contrast, the healthy-cycle close, the curl handshake before/after) on request.

Still reproducing on a newer build (Desktop 1.14271.0 / Claude Code 2.1.181, 2026-06-20) — with a host-binary trace that names the mechanism behind @chongwon83's "orphan tool_use," plus one more eliminated lever.

Environment

• Claude Desktop (macOS): 1.14271.0
• Claude Code: 2.1.181 — CLAUDE_CODE_CHILD_SESSION=1, CLAUDE_CODE_ENTRYPOINT=claude-desktop, local agent mode
• macOS Darwin 25.3.0, Apple Silicon
• Tool is enabled: CLAUDE_CODE_ENABLE_ASK_USER_QUESTION_TOOL=true

Same signature as the 1.11187.4 variant: the AUQ call returns [Tool result missing due to internal error] and the turn ends Tool execution was interrupted. CLI renders fine; only the Desktop embedded session fails. So it's unfixed on a build newer than any in this thread.

Host-side trace — what the agent actually receives. @chongwon83's "orphan tool_use / silently dropped tool_result" has an exact counterpart in the host binary. From the 2.1.181 claude binary:

• The error text is an internal constant: z_m = "[Tool result missing due to internal error]".
• It's emitted by the tool_use↔tool_result reconciliation loop, which backfills a synthetic error result for any tool_use id with no matching result:

h = [tool_use ids with no matching tool_result]
h.map(y => ({ type:"tool_result", tool_use_id:y, content:z_m, is_error:true }))

So: renderer never returns an answer → orphan tool_use → host backfills z_m. That's the agent-visible half of the bridge's behavior=deny-at-stop.

One more eliminated lever: user hooks. This machine has PreToolUse + PostToolUse hooks matched to (AskUserQuestion|mcp__.*__AskUserQuestion) installed. Failure is identical with them present, and the host's own log string proves a hook isn't the deny source:

returned permissionDecision=defer in interactive mode; ignoring (defer is print-mode only)

A PreToolUse hook returning defer is ignored in interactive mode — a no-op. Third-party AUQ hooks are ruled out.

Thanks for tracing this to the host binary, @mandosanti06 — the z_m
reconciliation path closes the loop on the orphan tool_use I flagged
earlier. To keep the layers straight: that backfill is the agent-visible
symptom (the host fabricating a tool_result for an id that never got one),
not the root cause. The real failure is upstream — the Desktop embedded
surface never renders the AUQ widget or returns an answer.

Adding independent corroboration that this is server-side, not local.

Every local lever is a null result. The failure persisted unchanged through
all of it:

Runtime: it survived every update in the window — [CCD] Initialized with
version shows 2.1.165 (onset) → 2.1.170 → 2.1.177 → 2.1.181, and I'm now on
2.1.183 (newer than your 2.1.181), still failing.
Network: our IT team allowlisted *.anthropic.com from TLS inspection; cold
asset fetch from assets-proxy.anthropic.com dropped from ~1–3.5s to
sub-100ms — bug unchanged. So the assets-proxy "Failed to fetch" storm
noted earlier in this thread isn't the cause, at least on my side.
Local state: plugins/MCP disabled (incl. a local Figma MCP), IndexedDB
rebuild, full Cmd+Q restart, fresh chat — all unchanged.
Onset timing fits a staged/server rollout. Mine started ~6/8–6/9 (on
2.1.165); the canonical report here is 6/3 with the same binary regressing
mid-instance, no restart. A cohort-based server rollout explains the date
spread; no client-side cause does.

Log signature. Across the logged window, main.log records Emitted tool
permission request for ExitPlanMode (37×), Workflow (2×), and a Chrome MCP
tool (1×) — and zero for AskUserQuestion. The string AskUserQuestion never
appears in the renderer log (claude.ai-web.log) at all; the only hits
anywhere are my own debug session titles. The turn still closes on a
healthy cycle (hadFirstResponse=true). The only background noise is a
startup MaxListenersExceededWarning (11 listeners on $eipc_message$,
AutoUpdater/AppPreferences — present even immediately after a restart, so
not the trigger). So this is a selective silent drop of the AUQ path: the
request is never even emitted to the permission pipeline, yet the agent
layer stays healthy — matching #65382's "only the webview drops state."

On the hooks lever: my setup matches yours exactly — same
(AskUserQuestion|mcp__.*__AskUserQuestion) matchers (gstack's
question-preference-hook on PreToolUse, question-log-hook on PostToolUse),
so your defer-ignored observation reproduces on a second machine with the
same hook config. Agreed that PreToolUse defer is ignored in interactive
mode, so it can't be the deny source. One caveat to keep the claim tight —
that eliminates the defer decision specifically, not all hook interference;
a clean repro with hooks fully removed would close it completely.

Net: still reproducing on Desktop 1.14271.0 / Claude Code 2.1.183 as of
2026-06-21, and it lines up with the broader June regression family
(#67474, #67426, #67071, #65620) where assistant text and tool_use content
get dropped from the Desktop/TUI surface. #26940 was the same symptom back
in February before it was closed stale and locked.

Could we get a tracking signal or rough ETA on this? Happy to share
sanitized main.log / claude.ai-web.log excerpts or run a controlled
diagnostic build.

2026년 6월 21일 (일) 오전 1:42, Armando J. Santiago Merle <
@.***>님이 작성:

mandosanti06 left a comment (anthropics/claude-code#65330) <https://l.jumpto.es/l/8cbec3db538c8e715ba1ec193ceabc4046afd13f?u=1438596> Still reproducing on a newer build (Desktop 1.14271.0 / Claude Code 2.1.181, 2026-06-20) — with a host-binary trace that names the mechanism behind @chongwon83 <https://l.jumpto.es/l/6f13c7dafe94f54f7bcbe10dba0c6d40054477db?u=1438596>'s "orphan tool_use," plus one more eliminated lever. Environment - Claude Desktop (macOS): 1.14271.0 - Claude Code: 2.1.181 — CLAUDE_CODE_CHILD_SESSION=1, CLAUDE_CODE_ENTRYPOINT=claude-desktop, local agent mode - macOS Darwin 25.3.0, Apple Silicon - Tool is enabled: CLAUDE_CODE_ENABLE_ASK_USER_QUESTION_TOOL=true Same signature as the 1.11187.4 variant: the AUQ call returns [Tool result missing due to internal error] and the turn ends Tool execution was interrupted. CLI renders fine; only the Desktop embedded session fails. So it's unfixed on a build newer than any in this thread. Host-side trace — what the agent actually receives. @chongwon83 <https://l.jumpto.es/l/fd4b396434143cc8ca74bbcb53d755c95d30c8f4?u=1438596>'s "orphan tool_use / silently dropped tool_result" has an exact counterpart in the host binary. From the 2.1.181 claude binary: - The error text is an internal constant: z_m = "[Tool result missing due to internal error]". - It's emitted by the tool_use↔tool_result reconciliation loop, which backfills a synthetic error result for any tool_use id with no matching result: h = [tool_use ids with no matching tool_result]h.map(y => ({ type:"tool_result", tool_use_id:y, content:z_m, is_error:true })) So: renderer never returns an answer → orphan tool_use → host backfills z_m. That's the agent-visible half of the bridge's behavior=deny-at-stop. One more eliminated lever: user hooks. This machine has PreToolUse + PostToolUse hooks matched to (AskUserQuestion|mcp__.__AskUserQuestion) installed. Failure is identical with them present, and the host's own log string proves a hook isn't the deny source: returned permissionDecision=defer in interactive mode; ignoring (defer is print-mode only) A PreToolUse hook returning defer is ignored in interactive mode — a no-op. Third-party AUQ hooks are ruled out. — Reply to this email directly, view it on GitHub <https://l.jumpto.es/l/4eec58db8f26e369b2716362d6e7d1f955474146?u=1438596>, or unsubscribe <https://l.jumpto.es/l/58e35226710d41ddbba2ecdbec2964cae41645f4?u=1438596> . You are receiving this because you were mentioned.Message ID: @.**>

Bump — still fully reproducible on latest as of 2026-06-24: Claude Desktop 1.15200.0 / Claude Code 2.1.185 (and every build since the first report). No change.

This is 21 days since onset (~2026-06-03) with no maintainer acknowledgment here or on any duplicate (#67474, #67426, #67071, #65620 — all OPEN, same root cause).

Triage shortcuts:

• Scope: Desktop "Claude Code" / Cowork only. Terminal CLI on the same machine is fine.
• Render path never fires: main.log emits Emitted tool permission request for ExitPlanMode but zero for AskUserQuestion; renderer logs (claude.ai-web.log, cowork_vm_node.log) contain zero "AskUserQuestion" strings. The "[Tool result missing due to internal error]" message is a downstream reconciliation back-fill of the orphaned tool_use — a symptom, not the cause.
• Server-side signal: no client update coincided with onset and onset dates differ per user (staged-rollout cohorts) → server-served frontend bundle or feature flag, not the installed binary.

Could a maintainer please acknowledge + assign triage, and confirm whether this is fixable / rollback-able server-side without a client release? Full logs available. 🙏

Confirming this is still broken on the latest build.

AskUserQuestion silently fails to render in the macOS desktop app — the question never reaches the webview and the call returns no response.

Environment

• Claude Desktop: 1.15962.1
• Claude Code: 2.1.187
• macOS: 26.5.1

Regression window (from my own logs)

• Last KNOWN-GOOD: 2026-06-23 18:37 UTC — log shows Emitted tool permission request … for AskUserQuestion, followed by Received permission response … once (tool: AskUserQuestion) and tool_calls: [{ tool_name: 'AskUserQuestion', approved: true }].
• BROKEN: 2026-06-27 — repeated AskUserQuestion calls produce zero Emitted tool permission request … for AskUserQuestion lines in ~/Library/Logs/Claude/main.log. The request is dropped before it ever reaches the renderer. Other tools (ExitPlanMode, MCP tools) still emit permission requests normally in the same sessions.

Ruled out as cause

• A separate MCP server (Grafana) was hard-crashing session setup 149×/day (Cannot use 'in' operator to search for 'properties' in true in createProxyServers → setupMcpAndPlugins → warmSession). I disabled it and confirmed 0 crashes on relaunch. AskUserQuestion still fails to render, so the MCP crash was unrelated to this bug.
• App fully quit + relaunched (Cmd+Q): no effect.

This matches the server-side-regression thesis in this thread: the agent session is healthy, only the AskUserQuestion render path is suppressed.

재현 (2026-07-05, Desktop app)

AskUserQuestion 호출 시 여전히 미렌더 — 모달이 뜨지 않고 다음 에러로 즉시 실패:

[Tool result missing due to internal error]

같은 세션에서 두 번 연속 재현 (동일 증상, 다른 질문 내용). 워크어라운드로 평문 질문 전환 후 정상 진행.

Still broken on 2026-07-23. Posting a full local-elimination matrix, since this thread has gone 18 days without maintainer response and the sibling report #65382 was just auto-closed as stale on 2026-07-21 without ever being fixed.

Environment

• Claude Desktop: 1.15962.1
• Claude Code: 2.1.187 / 2.1.217 (embedded)
• macOS: 26.5.1
• Cowork gates applied to this account 2026-06-23 10:58 UTC (cowork_plugin_host_ops=true, claudeai_cowork_backend_marketplaces=true)

Symptom (unchanged, matches @chongwon83's 2026-07-05 report verbatim)

Every AskUserQuestion call fails immediately with:

[Tool result missing due to internal error]

No modal renders. In ~/Library/Logs/Claude/main.log there are zero Emitted tool permission request … for AskUserQuestion lines, while ExitPlanMode and MCP tools emit and render normally in the same sessions. The request is dropped before it reaches the renderer.

Regression window from my logs

• Last known-good: 2026-06-23 18:37 UTC — Emitted tool permission request … for AskUserQuestion, then Received permission response … once, then tool_calls: [{ tool_name: 'AskUserQuestion', approved: true }].
• Broken continuously since. ~4 weeks.

Local causes eliminated (each verified in logs, not assumed)

| Lever tested | Result |
|---|---|
| Soft restart (Cmd+Q + relaunch) | no change |
| Clean restart — all Claude Helper processes killed first | no change |
| Crashing Grafana MCP disabled (was failing createProxyServers → setupMcpAndPlugins → warmSession 256×, Cannot use 'in' operator to search for 'properties' in true) | crashes 256 → 0; AUQ still fails |
| All other MCP servers | build proxies cleanly; sessions warmed successfully |
| MCP tool-count / overload (250 → ~200 tools; 56 child procs / 5.7 GB cleared) | no change |
| VPN disabled — assets-proxy.anthropic.com DNS 3.08s → 0.02s, vendor bundles now HTTP 200 (had 463 TypeError: Failed to fetch) | no change |

So the Failed to fetch storm and the MCP crash were real but independent bugs. With every one of them fixed and a fully clean process tree, AskUserQuestion still never renders. There is no remaining client-side lever.

Ask: this is labeled bug / regression / area:cowork / area:desktop / platform:macos and has had no maintainer acknowledgment in the ~7 weeks since onset. Please either fix the AUQ render path in the Cowork/local-agent SDK adapter, or provide a supported way to opt an account out of the Cowork cohort. Given #65382 was auto-closed as stale rather than resolved, flagging explicitly that this is not inactive — it reproduces on the newest build today.

Workaround for anyone landing here: plain-text questions work, and the standalone claude terminal CLI renders interactive prompts normally (different render path).