claude-code - 💡(How to fix) Fix [BUG] Cowork Desktop (macOS): AskUserQuestion card never reaches renderer; yellow-dot badge shows pending but no UI; on app quit, pending request silently resolves as "Dismissed" [2 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

In Cowork mode on Claude Desktop (macOS, Apple Silicon), AskUserQuestion calls from the main session fire on the main process and light up the yellow-dot "needs input" badge on the session in the sidebar, but the question card never reaches the renderer process. Opening the affected session shows no question, no card, no answer UI, and no text fallback. The pending tool permission request sits unanswered for ten to fifty-plus minutes. The user eventually quits Claude Desktop to recover. The on-quit cleanup then resolves every pending AskUserQuestion permission request with behavior=deny. After relaunch, the session view shows the original question retroactively, with "Dismissed" recorded as the answer, even though the user never saw the prompt and never clicked anything.

Two coupled failures are involved.

Primary failure (renderer delivery): the main process emits the permission request and updates the badge, but ~/Library/Logs/Claude/claude.ai-web.log has zero references to either "AskUserQuestion" or "permission" across the same window where the main log shows over 900 references. The renderer never receives the card payload at all.

Secondary failure (on-quit cleanup): pending AUQ permissions are force-resolved as behavior=deny by the lam-session-stop-all cleanup, and the UI subsequently labels that outcome "Dismissed" in the post-restart view, which is indistinguishable from an explicit user dismissal.

Thirty-five instances of the silent auto-deny were captured in roughly eight days of normal use across one user's session pool. Concrete log evidence is in the Error Messages/Logs section below. Full log files are attached in Additional Information.

What Should Happen?

The AskUserQuestion card payload should reliably reach the renderer in Cowork sessions. The yellow-dot session badge and a rendered card in the conversation must be consistent: if one is set, the other must paint. If the renderer cannot mount the card for any reason, the badge should not be silently converted to "answered" by the quit cleanup.

At a minimum, on-quit resolution of pending AskUserQuestion permissions should record a distinct status (cancelled, app-quit, expired) so the user can tell the difference between an explicit dismissal and a force-resolution during shutdown.

Ideally, pending AskUserQuestion requests should survive an app restart and re-present on relaunch instead of being permanently force-denied.

Error Messages/Logs

Full log files are attached in Additional Information: main.log, main1.log, claude.ai-web.log, coworkd.log from ~/Library/Logs/Claude/. Together they span roughly 2026-05-05 through 2026-05-13.

Three distinct evidence patterns appear:

1) Renderer never sees the AskUserQuestion call.

grep -i "AskUserQuestion\|permission" ~/Library/Logs/Claude/claude.ai-web.log returns zero matches across a window in which main.log shows over 900 references to AskUserQuestion. The renderer process has no record that any AUQ call ever occurred in any session.

2) Permission requests are emitted, never receive a user response, then are force-denied during quit cleanup.

Example one (10 minute gap between emit and force-deny):

  main.log:773   2026-05-12 16:38:37 [info] Emitted tool permission request 38475f56-... for AskUserQuestion in session local_d1aa1ed9-...
  ... no "Received permission response" line for this UUID anywhere in the log ...
  main.log:858   2026-05-12 16:48:04 [info] beforeQuit: handler fired, going down
  main.log:869   2026-05-12 16:48:04 [info] Firing lam_session_app_quit for session local_d1aa1ed9-...
  main.log:874   2026-05-12 16:48:04 [info] Stopping session local_d1aa1ed9-...
  main.log:875   2026-05-12 16:48:04 [info] [Lifecycle] Session local_d1aa1ed9-...: running → stopping
  main.log:876   2026-05-12 16:48:04 [info] Bridge resolving permission 38475f56-...: behavior=deny (tool: AskUserQuestion)
  main.log:877   2026-05-12 16:48:04 [info] [Lifecycle] Session local_d1aa1ed9-...: stopping → idle

Example two (51 minute gap):

  main.log:14717  2026-05-12 22:43:10 [info] Emitted tool permission request c492463b-... for AskUserQuestion in session local_042077b2-...
  ... no "Received permission response" line for this UUID anywhere in the log ...
  main.log:16361  2026-05-12 23:34:51 [info] Bridge resolving permission c492463b-...: behavior=deny (tool: AskUserQuestion)

3) The auto-deny always coincides with beforeQuit.

Every "Bridge resolving permission ...: behavior=deny (tool: AskUserQuestion)" event in both attached log files lands at exactly the timestamp of a "beforeQuit: handler fired" event, interleaved with the per-session running → stopping → idle lifecycle transitions of every active LAM session at quit time. The cleanup pathway is the lone cause of behavior=deny resolution for AskUserQuestion in these logs.

For contrast, the healthy path also appears in the same logs:

  2026-05-12 16:29:05 [info] Emitted tool permission request 7f63ffe6-... for AskUserQuestion in session local_fe429b49-...
  2026-05-12 16:30:03 [info] Received permission response for 7f63ffe6-...: once (tool: AskUserQuestion)

"Emitted" followed within seconds by "Received permission response: once" is the working path. "Emitted" followed by no response and a later "behavior=deny" at quit time is the broken path. Both paths appear in the same sessions, sometimes across consecutive AUQ calls.

Steps to Reproduce

1. Run Cowork on macOS Apple Silicon with multiple parallel sessions. In the failing case the user typically has eight to fifteen concurrent captain sessions, each of which calls AskUserQuestion at intermediate approval gates.
2. Wait for any one of them to issue an AskUserQuestion call.
3. Observe: a yellow-dot "needs input" badge appears on the session in the sidebar.
4. Click the session. No question card and no answer UI render in the conversation. The conversation looks idle. No text fallback appears.
5. Quit Claude Desktop (Cmd+Q).
6. Relaunch and reopen the same session. The question card materializes in the transcript with "Dismissed" recorded as the answer.

Reproducibility: intermittent but frequent. Thirty-five instances captured in roughly eight days of normal use across one user's session pool.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude 1.7196.0 (2dbd78) 2026-05-12T05:34:40.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Frequency Across Eight Days

Combined across main.log and main1.log (both attached), the silent auto-deny pattern fires in the following clusters. Every cluster timestamp matches a beforeQuit: handler fired event.

Total: 35 silent AskUserQuestion auto-denies across roughly eight days. Matches the user-reported frequency of multiple events per hour during heavy use.

Unique Signature (Why This Is Not A Duplicate)

The four-way combination characterizing this bug:

1. The yellow-dot session badge does fire on the affected session, so the main process knows input is needed.
2. The renderer process never receives the AskUserQuestion payload, verified by zero hits for "AskUserQuestion" or "permission" in claude.ai-web.log across the same window where the main process has over 900 references.
3. The pending request can sit unanswered for tens of minutes, verified by 10 to 51 minute gaps between Emitted and the eventual Bridge resolving permission.
4. The quit-cleanup path force-resolves pending AskUserQuestion requests with behavior=deny, which surfaces in the post-restart UI as "Dismissed". Verified at thirteen distinct quit timestamps spanning eight days, every one of them coincident with beforeQuit: handler fired.

The closest existing report is #33564, which covers parts of (1) and (2) on macOS Cowork but reports a text-fallback behavior rather than a silent-and-then-Dismissed behavior, contains no evidence of the on-quit cleanup path, and was closed as not planned with the stale label.

Other related but distinct reports:

• #33625 covers Remote Control on mobile (different transport).
• #29547 covers the plugin-skill alwaysAllowRules early-return path and was fixed.
• #29733 and #29530 cover CLI / TUI variants.
• #44776 covers Cowork task-switch render-drop for ordinary assistant content, not AskUserQuestion cards.
• #50728 covers the Python Agent SDK in no-TTY environments.
• #57658 covers AskUserQuestion originating inside spawned subagents.

The combination (1) + (2) + (3) + (4), with the specific "Bridge resolving permission ...: behavior=deny (tool: AskUserQuestion)" log signature firing exclusively during beforeQuit cleanup, is not captured by any of these existing reports.

Suspect Layers

Two suspect layers from the evidence:

• The main-to-renderer transport for the AskUserQuestion permission card payload. The main process logs "Emitted tool permission request ... for AskUserQuestion", but the renderer never logs receiving it. The session-badge channel and the card-payload channel appear to be decoupled, and the card channel is racy. A focus-state coupling on the card-delivery channel, analogous to the renderer dropout pattern in #44776 for ordinary assistant content, would explain why most AskUserQuestion calls render fine and a meaningful fraction are silently dropped (those calls land while the relevant session pane is not the foreground tab).

• The on-quit lam-session-stop-all cleanup path. Force-resolving pending permissions as behavior=deny and labeling the result "Dismissed" in the UI is destructive when combined with the renderer-delivery failure: the user never had the opportunity to answer, but the answer of record is treated as theirs. A safer cleanup would either preserve the pending state across restart so the question re-presents, or label the outcome as "cancelled by app quit" so it cannot be confused with an explicit dismissal.

Impact

Captain workflows in Cowork use AskUserQuestion as a synchronous approval gate between substantive steps (pre-dispatch scope confirmation, canonical promotion approval, and so on). When the AskUserQuestion card fails to render and the cleanup later force-denies the pending request, the captain proceeds with default behavior the user never approved. Lost work, wasted subagent dispatches, and document promotions advancing without intended scope confirmation are all observed consequences. The only existing recovery path requires quitting Claude Desktop, which is itself the trigger that converts the invisible-pending state into a permanent silent denial. There is currently no way to recover the unanswered question; the user has to be told manually what the answer would have been on the next turn.

Workaround

None that preserves the original question. Restarting Claude Desktop surfaces the missed question post hoc with "Dismissed" already recorded, so the user can read what was asked but cannot answer it in the original turn. The captain must be told manually what the answer would have been on the following user turn.

Attached Log Files

• main.log: roughly 2026-05-12 18:00 through 2026-05-13 09:30. Contains 16 of the 35 silent auto-deny events plus the corresponding Emitted events and beforeQuit cleanup traces.
• main1.log: roughly 2026-05-05 through 2026-05-12 (older file, rotated). Contains the remaining 19 silent auto-deny events plus the corresponding Emitted events and beforeQuit cleanup traces.
• claude.ai-web.log: renderer-side log covering the same period. Contains zero references to AskUserQuestion or permission, confirming the renderer-delivery failure.
• coworkd.log: Cowork daemon log, attached for completeness.

main.log claude.ai-web.log coworkd.log main1.log