[BUG] Desktop Code tab (Auto mode): permission prompt never renders — call hangs then is silently killed as "cancelled" on the next message

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported with this exact mechanism yet (related: #92053, #85588, #92817, #86478)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

In the Claude Desktop app's Code tab, running in Auto permission mode, some tool calls that need classifier escalation to a user-approval prompt never render that prompt anywhere in the UI — no card, no notification, nothing on screen. The call just sits "running." The instant the user sends their next chat message, the pending call is killed and reported to the model as:

The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed.

This is not a real user decision — the user never saw anything to approve or deny. The transcript records toolDenialKind: "cancelled", distinct from a real classifier deny (which carries a bracketed reason like [Self-Modification]).

Two things make this worse than a simple missing dialog:

1. It's non-deterministic per call, not purely command-pattern-based. A grep invocation that matched an existing project allow rule (Bash(grep:*) in .claude/settings.local.json) was silently escalated and killed, even though near-identical grep calls against the same file had succeeded moments earlier in the same session/turn.
2. Toggling "Bypass Permissions" on an already-running session makes it worse, silently. main.log shows the app accepting the UI toggle and writing config, immediately followed by:

``
[error] [CCD] Failed to set permission mode for session <id>: Cannot set permission
mode to bypassPermissions because the session was not launched with
--dangerously-skip-permissions
``
The UI still shows "Bypass Permissions" as selected, but the running CLI process keeps enforcing its original (stricter) mode — so the user believes they're unblocked and are not, and any subsequent escalated call hits the same invisible-prompt failure above. Confirmed 3x same day across 3 different sessions.

What Should Happen?

1. Every classifier-escalated tool call must render a visible approval prompt in the Desktop UI — no silent hangs.
2. If a mode switch (e.g. to bypassPermissions) fails server-side, the UI must not show the mode as active — surface the actual error to the user instead of silently keeping the old mode.
3. A killed-by-race tool call should never be reported to the model as a user refusal; it should use an honest "did not complete" message (same class of fix requested in #92053).

Error Messages/Logs

// Failed bypass-mode switch (repeated 3x, 3 different sessions, same day):
2026-09-14 16:16:34 [info] [CCD] LocalSessions.setPermissionMode: sessionId=local_0dcc1e23-9cb2-4097-bdc6-4ae27cc786d5, mode=bypassPermissions
2026-09-14 16:16:34 [info] Config file written
2026-09-14 16:16:34 [error] [CCD] Failed to set permission mode for session local_0dcc1e23-9cb2-4097-bdc6-4ae27cc786d5: Cannot set permission mode to bypassPermissions because the session was not launched with --dangerously-skip-permissions

// Live repro: a Bash(grep) call matching an existing allow rule, silently killed
// the instant a follow-up chat message was sent. No "Emitted tool permission
// request" line for this call in main.log at all (contrast with a normal prompt,
// which does log that line + a matching respondToToolPermission response).
// Session local_faf0804f-... — no setPermissionMode call ever made for this
// session (plain default Auto-mode launch), ruling out the bypass-toggle cause.

Steps to Reproduce

1. Open a session in the Desktop Code tab in Auto permission mode (default).
2. Work normally for a while (tens of tool calls); this is intermittent, not per-command-deterministic.
3. Eventually a Bash (or Agent) call sits "running" indefinitely with no approval card shown anywhere.
4. Send any follow-up chat message.
5. The pending call immediately fails with "The user doesn't want to take this action right now," toolDenialKind: "cancelled", even though no prompt was ever shown to approve or deny.

Separately, to reproduce the bypass-mode issue:

1. Start a session in Auto mode, let it run past the first message.
2. Toggle the session's permission mode to "Bypass Permissions" via the Desktop UI.
3. Check ~/Library/Logs/Claude/main.log for Failed to set permission mode — the UI shows bypass as active, but the underlying CLI process rejects the switch and keeps enforcing the original mode.

Claude Model

N/A — reproduced across models, this is a permission/UI-layer bug

Is this a regression?

Unknown

Claude Code Version

CLI/core 2.1.270; Desktop app 1.52386.6

Platform

Claude Desktop app (Code tab)

Operating System

macOS (Darwin 25.6.0)

Terminal/Shell

N/A (Desktop app, not terminal)

Additional Information

Related open issues describing adjacent parts of the same failure family, none an exact duplicate of this specific mechanism:

• #92053 — same toolDenialKind: "cancelled" / same refusal string, different trigger (session backgrounding/channel loss rather than a missing UI prompt)
• #85588 — "Auto mode silently denies tool actions; denials never surface to the user" (classifier hard-deny, not an unrendered-then-cancelled prompt)
• #92817 — "Bypass all permissions setting not respected during operations" (matches the mid-session toggle failure here, without the specific launch-flag error text)
• #86478 — "bypassPermissions defaultMode and --permission-mode flag ignored; session stays in auto mode"