### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Summary In Claude Desktop (Windows), sessions launched by the app with --permission-mode default get a classifier ("auto mode") that decides per-tool-call

[BUG] "auto mode cannot determine the safety" false-positive blocks ALL MCP mutating tool calls — settings.json fix doesn't work, Shift+Tab doesn't work either

Status Open

Reported on v2.1.211

Maintainer reply None cached

Activity 0 comments · opened Jul 23, 2026

Preflight Checklist

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

What's Wrong?

Summary
In Claude Desktop (Windows), sessions launched by the app with --permission-mode default get a classifier ("auto mode") that decides per-tool-call whether a call is safe. This classifier is permanently broken/unavailable for MCP tool calls that mutate state — it returns:

"<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool>"
This is not the session's actual model being down (the model responds normally in the same turn). It is the separate classifier model used only by default permission mode. The bug has persisted across multiple app/CLI versions over several days (first seen 2026-07-21, still reproducing 2026-07-23, including inside the main orchestrating session itself, not just subagents).

Environment
Claude Desktop: 1.24012.1.0 (Windows Store package Claude_1.24012.1.0_x64__pzs8sxrjxfjjc)
Embedded Claude Code CLI: seen on 2.1.211, 2.1.215, 2.1.217 — bug reproduces on all three
OS: Windows 11 Pro, build 10.0.26200
Models tried: claude-sonnet-5, claude-opus-4-8, claude-fable-5 — bug reproduces regardless of model
Steps to reproduce
Start a normal chat session in Claude Desktop (do not touch permission mode at session creation — app defaults it to default).
Ask Claude to perform any action that requires a mutating MCP tool call — e.g. open a URL in a connected browser (mcp__claude-in-chrome__tabs_context_mcp with createIfEmpty:true, mcp__claude-in-chrome__navigate, or mcp__Claude_Browser__preview_start).
Call fails immediately with: "<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool>".
Read-only calls on the same tool/server succeed fine in the same session (e.g. tabs_context_mcp with no args passes; tabs_context_mcp{createIfEmpty:true} fails).
What we ruled out
Not an actual model outage — the model keeps responding in the same session while claiming to be "temporarily unavailable."
Not tool-allowlisting — the tool was already present in --allowedTools / settings.local.json allow-list; adding it again has no effect.
Not settings.json permissions.defaultMode — set permissions.defaultMode: "manual" in ~/.claude/settings.json, tested across 3 fresh sessions, zero effect.
Not switching mode mid-session via the UI's Shift+Tab — used Shift+Tab to change the visible mode selector in a running session; verified via Get-CimInstance Win32_Process immediately after that the live process's --permission-mode command-line argument was still default (unchanged). The UI toggle does not appear to reach the already-launched process.
Root cause (as far as we can determine from outside)
Checked via Get-CimInstance Win32_Process -Filter "Name='claude.exe'": the embedded Claude Code CLI process is launched by the desktop app with an explicit --permission-mode default command-line flag, e.g.:

claude.exe --output-format stream-json --verbose --input-format stream-json --effort high
--model claude-sonnet-5 --permission-prompt-tool stdio --allowedTools ...
--setting-sources=user,project,local --permission-mode default --include-partial-messages ...
Sessions observed side-by-side at the same time had different --permission-mode values baked in (default, acceptEdits) — confirming the mode is fixed at process launch and is not something settings.json or an in-session UI toggle can change afterward. Whatever mechanism decides that flag at launch time appears to default to default, and default mode's safety classifier is the thing that's broken/unavailable for MCP mutating calls.

Impact
Any workflow relying on a subagent or session to call a mutating MCP tool (browser navigation, file writes via MCP, etc.) fails 100% of the time when the session was launched in default mode, with no user-facing way to fix it short of somehow getting a new session launched with a different mode — and it's unclear what actually controls that at launch time.

Ask
What determines the --permission-mode flag baked into the process at launch, and why does it default to default even when settings.json says otherwise?
Why is the default-mode safety classifier reporting itself unavailable, and is this expected to self-heal, or is it fully down?
Is there a supported way to force a running desktop-app session into a different permission mode without the classifier issue?

What Should Happen?

Error Messages/Logs

"<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool>"

Steps to Reproduce

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.217.

Claude Code Version

2.1.211, 2.1.215 and 2.1.217.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗