›_ Claude Code Issues
Claude Code Issues / #73587

[BUG] Desktop app ignores `permissions.allow` rules — prompts for everything, even Claude's own config directory

Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 9 comments · opened Jul 2, 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?

Product: Claude Code Windows desktop app ("local agent mode" sessions)
OS: Windows 11 Pro 10.0.26200 · Plan: Max
First observed: ~2026-06-30 (after an app update — this is a regression). Diagnosed 2026-07-02, re-confirmed same day in a fresh session.

Customer impact — read this first

I am a paying Max customer. This bug cost me two full days of degraded work: at its worst I was giving 12 permission approvals in 10 minutes for a single task. It makes unattended/agentic work — the entire point of the product — impossible, because every run stalls on a prompt nobody is there to answer.

Worse: I had to diagnose Anthropic's bug myself, across multiple sessions, testing rule formats, cleaning junk rules, and reverse-engineering which config the app actually respects. This product is not cheap. I should not be spending my working hours debugging the vendor's permission system.

Bug detail — allow rules in settings.local.json are ignored

  • Rules present in permissions.allow (e.g. Bash, PowerShell, Read(//c/Users/gonza/.claude/**), MCP server names like mcp__claude-in-chrome) do not suppress prompts. The app prompts anyway.
  • Reproduced: a command approved via "Allow always" prompted again when run identically later.
  • "Allow always" saves a rule for the exact full command string, which never re-matches in practice. Result: ~15 junk rules accumulated in days, zero prompts prevented.
  • The only thing the app respects is defaultMode. Setting defaultMode: "dontAsk" was the only effective workaround — a much blunter instrument than the granular allow-list I had configured.

Case 2 (fresh session, dontAsk active): a Read of C:\Users\gonza\.claude\settings.json — Claude Code's own global config file — prompted with "Path is outside allowed working directories", despite the explicit allow rule Read(//c/Users/gonza/.claude/**). So allow rules for paths outside the working dir are ignored too. Workaround: permissions.additionalDirectories — which works, but I only found it after more digging.

Case 3 (live, while preparing this report): my allow list has had mcp__claude-in-chrome (the whole server) for days. The agent used that MCP and I got 5 permission prompts in a row — one per individual tool (tabs_context_mcp, navigate, screenshot, ...). Each "Allow always" saved a rule for that one exact tool; the server has ~80 tools. I was interrupted 5 times in under 2 minutes to approve tools from a server I had already fully authorized — while filing the bug report about this exact bug.

Design feedback: the app should trust its own directories by default

Scoping the agent to approved directories is right — AI should not roam all my disks unprompted. But: Claude Code creates C:\Users\gonza\.claude itself. They are its own files — its config, session history, memory. Then it asks my permission to read the folder it created. Nobody who consciously installed Claude will deny the app access to the app's own folder. It's a permission request with exactly one sane answer, shown thousands of times across your user base.

Related issues (same family, none covers this exact case)

#18160 (allow rules in global settings.json ignored), #73418 (Windows, classifier ignores allow rules for file tools), #36884 (VS Code extension ignores Edit/Write rules), #54856 ("always allow" fails to persist on macOS). This report adds: the Windows desktop app specifically, a regression window (~2026-06-30 app update), MCP server-level rules being ignored per-tool, and the own-config-directory absurdity. The pattern across platforms suggests a systemic problem in how permission rules are evaluated outside the CLI.

What Should Happen?

  1. permissions.allow rules in settings.local.json should actually suppress prompts in the desktop app (tool-level rules like Bash, path rules like Read(//c/...), and MCP server-level rules like mcp__claude-in-chrome covering all of that server's tools).
  2. "Allow always" should save a matchable rule (prefix/pattern or tool-level), not the exact command string.
  3. Claude's own directories (its config dir ~/.claude, its temp/scratchpad) should be trusted by default — no prompt, ever, out of the box. Keep the strict boundary for everything else on disk; that part is correct.
  4. Acknowledgment that this is a regression — it started after an app update ~2026-06-30.

Error Messages/Logs

Permission dialog text when reading Claude's own config dir (rule Read(//c/Users/gonza/.claude/**) present in allow):

¿Permitir que Claude leyó settings.json?
C:\Users\gonza\.claude\settings.json
Path is outside allowed working directories

(Options offered: Denegar / Permitir siempre / Permitir una vez. "Permitir siempre" then saves an exact-path rule that does not generalize.)

Steps to Reproduce

On the Windows desktop app (local agent session):

  1. In the project's .claude/settings.local.json, add explicit allow rules, e.g.:

``json
{
"permissions": {
"allow": [
"Bash",
"PowerShell",
"Read(//c/Users/<user>/.claude/**)",
"mcp__claude-in-chrome"
],
"defaultMode": "dontAsk"
}
}
``

  1. Start a NEW session in the desktop app (so the settings are freshly loaded).
  2. Ask Claude to read C:\Users\<user>\.claude\settings.json (its own global config, covered by the Read(...) rule).

→ Permission prompt appears: "Path is outside allowed working directories". The allow rule is ignored.

  1. Ask Claude to use any tool from an allowed MCP server (e.g. mcp__claude-in-chrome).

→ One prompt per individual tool (tabs_context_mcp, navigate, screenshot, ...), despite the server-level allow rule.

  1. On any prompt, click "Allow always", then have Claude repeat the equivalent action later (different argument, or a different tool of the same server).

→ Prompts again. Inspect settings.local.json: the saved rule is the exact command/tool string, which never re-matches.

Same config works as expected in the CLI. The desktop app only respects defaultMode (and additionalDirectories); the allow list appears to be ignored entirely.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — desktop app auto-updates silently; last working ~2026-06-28

Claude Code Version

Desktop app 1.18286.0.0 (Windows, Store/Appx package) — no standalone claude CLI on PATH; bundled agent version not user-visible

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

  • Environment: Claude Code Windows desktop app (Store/Appx 1.18286.0.0), "local agent mode" sessions — not the CLI. Terminal/Shell = "Other" because there is no terminal involved; Platform = consumer Max subscription (no API key).
  • Model used in the affected sessions: Opus 4.8 and Fable 5 — bug is model-independent (prompts come from the harness/permission layer).
  • The same settings.local.json semantics work in the CLI per docs; the desktop app diverges.
  • Happy to provide the full settings.local.json, the accumulated junk "Allow always" rules, and session timestamps if useful.

View original on GitHub ↗

7 Comments

WLemmermeyer · 1 month ago

Confirming this on the Cowork variant of the Windows desktop app. It started with the update from 2.1.187 → 2.1.197 (around 2026-06-30); permission persistence had worked reliably for weeks before that, so this is a regression for me too.

Details from my own diagnosis:

Neither settings.local.json → permissions.allow nor ~/.claude.json → projects[...].allowedTools is used as a permission source. I populated both (valid JSON, verified after a clean restart) and the approval dialog still fires on every session start.
Allow always only writes to per-session state at %APPDATA%\Roaming\Claude\claude-code-sessions\<project-uuid>\<account-uuid>\local_<session-uuid>.json (fields enabledMcpTools / alwaysAllow). There is no global fallback, so every new session re-prompts from scratch — the toggle does hold within a session, but never carries over.

Related: the concurrent-write angle in #73364 (whole-file read-modify-write on ~/.claude.json reverting allowlists) compounds this.

Environment: Windows 11 Pro, Claude desktop app (Cowork mode), affected build 2.1.197.

milhouse423 · 1 month ago

Same here. Windows 11, desktop ~2.1.198, and the 2.1.187→2.1.197 window seems to match.

Sharing a workaround that appears to work so far in my early use of it:

Launch the session from the terminal CLI (claude in PowerShell/Windows Terminal) at your project root. It honors permissions.allow from settings.local.json, whereas the desktop Code tab doesn't. The useful part is that the state seems to bind at init and carry over. In my case it's a remote session, so I can open that same session in the desktop GUI, and permissions keep working. So terminal-init, then continue in desktop, appears to give both the honored rules and the GUI.

PropellerHead23 · 1 month ago

Same regression on macOS — adding a data point with harness-level evidence, since this build's changelog says it touched exactly this code path.

Environment: macOS 15.5 (Darwin 25.5.0), Claude Desktop 1.20186.1, embedded Claude Code CLI 2.1.205, Claude in Chrome extension 1.0.80.

Symptom (identical to OP): every desktop-spawned session shows a blocking "Allow Claude to use \<Tool\> (claude-in-chrome)?" card once per individual connector tool (Tabs Context, Navigate, Get page text, Read network requests, Computer, …). "Always allow" writes an exact-string rule (e.g. mcp__claude-in-chrome__computer) into the cwd's .claude/settings.local.json, which is never honored in any later session — we've accumulated 19 junk grant files this way across session worktrees.

Evidence that the rules are ignored rather than missing:

  • Sessions verified spawned with --permission-mode bypassPermissions --setting-sources=user,project,local --permission-prompt-tool stdio, plus a hardcoded --allowedTools list containing only mcp__computer-use and mcp__ccd_session__* tools (live ps output).
  • Fresh sessions booted with exact tool-name allow rules present at boot in all three scopes — user ~/.claude/settings.json, project .claude/settings.json path, and project-local .claude/settings.local.json (both server-level mcp__claude-in-chrome, wildcard mcp__claude-in-chrome__*, and exact mcp__claude-in-chrome__<tool> forms) — and still got a card for every claude-in-chrome tool.
  • PreToolUse hooks run and exit 0 for these calls (transcript hook_success records), and the desktop session config shows permissionMode: bypassPermissions — the card is coming from the app's stdio permission handler, not the engine's rule evaluation.
  • Only in-session memory of an "Always allow" click suppresses a repeat card; nothing persists across sessions.

Regression timing on this machine: a controlled test on 2026-07-10 (previous desktop build) drove claude-in-chrome tools (tabs_context_mcp, navigate, mutating computer clicks on a live site) with zero prompts. The prompts-on-every-tool behavior began immediately after the desktop auto-updated to 1.20186.x on 2026-07-11 ~18:20 (ShipIt timestamps). Note the v1.20186.0 changelog entry: "Fixed plugin connectors sometimes missing from the Connectors list and tool permission prompts when they were slow to start" — i.e., this release modified connector tool-permission-prompt handling.

Impact: any browser-automation session requires dozens of Allow-once clicks per task; "Always allow" is a no-op across sessions. CLI-launched (claude in terminal) sessions honor the same allow rules correctly, so this is specific to the desktop spawn path.

PropellerHead23 · 1 month ago

Follow-up on the macOS repro above — workaround findings after systematic testing:

Setting permissions.defaultMode: "dontAsk" in user settings.json suppresses the desktop browser-tool approval cards for the high-frequency tools (tabs_context_mcp, navigate, read_page, get_page_text, computer) — verified across multiple fresh sessions. Two caveats worth noting for whoever picks this up:

  1. The card layer appears to read settings live (an already-running session stopped carding immediately after the file changed), unlike the CLI engine's boot-time snapshot.
  2. list_connected_browsers and select_browser still card under dontAsk with exact allow rules present at every scope (user + project + project-local). If that's an intentional security boundary for browser-connection switching, it would be helpful to have it documented; if not, it's part of this bug.

For anyone else hitting the storm: dontAsk + a widened allow list (so flag-less headless sessions aren't auto-denied) is a workable stopgap; bypassPermissions and server-level/wildcard MCP rules do NOT suppress these cards.

PropellerHead23 · 1 month ago

Cross-referencing two sibling reports of what looks like the same desktop permission-card regression family, to help triage/dedupe:

  • #74715 — Claude-in-Chrome "Always allow" persisted as duration:once (so every fresh session re-prompts per tool)
  • #76238 — MCP allowlisted tools still prompt on fresh session (macOS)

Additional data point beyond the Windows report above: this also reproduces on macOS, desktop 1.20186.1 — regression onset was the 2026-07-11 desktop auto-update (allow rules were honored before it). So the failure is cross-platform and spans both MCP tools and the Chrome-extension surface.

Possibly related: #77352 (desktop ignores bypassPermissions for ccd_session_mgmt tools) was closed as completed on 2026-07-14 — if that fix touched the shared desktop permission-card path, it may address part of this family.

(The permissions.defaultMode: "dontAsk" workaround I posted earlier continues to hold on macOS 1.20186.1.)

PropellerHead23 · 1 month ago

Update from the macOS repro above — still present on the current build, plus one new data point that may help localize it.

Environment: macOS 15.5, Claude Desktop 1.21459.3, embedded Claude Code CLI 2.1.209, Claude in Chrome extension current as of 2026-07-17.

Still reproduces: connector (claude-in-chrome) tool calls prompt per-tool; permissions.allow exact rules + wildcards at every scope (user/project/local) are not consulted for connector tools.

New data point — spawn-mode asymmetry: inspecting the desktop's spawned CLI processes (ps) shows two distinct spawn profiles on the same build:

  • Regular desktop sessions: --permission-mode bypassPermissions --allow-dangerously-skip-permissions → these do NOT card for connector tools on 2.1.209 (verified live today).
  • Sessions originated from the Claude-in-Chrome extension side panel: --permission-mode default (everything else identical, including --setting-sources=user,project,local and --permission-prompt-tool stdio) → these card on every connector tool call, because the connector tools are host-injected (not in --mcp-config) and their adjudication path never consults the settings allow rules.

So the failure seems isolatable to: host-injected connector tools + --permission-prompt-tool stdio adjudication skipping the permissions.allow matcher that regular MCP/built-in tools go through. The --allowedTools list the desktop passes at spawn (which includes only the credential-broker connector tools) IS honored — those five never prompt — which further suggests the rule-matching layer, not the prompt plumbing, is what's bypassed for connector tools.

Workaround we've settled on meanwhile: a PreToolUse hook that denies mcp__claude-in-chrome__* outright and redirects to a local Playwright-based MCP (no host connector layer, so no cards), with a human-gated time-boxed override.

ckeryakes · 1 month ago

The clickity clickity on approving messages between agent sessions makes me feel like a click monkey. I am now looking at using CLI since it does not have this hard gate. I really like the desktop UI so I am really unhappy with the apparent "works as designed" closure of https://github.com/anthropics/claude-code/issues/77352

If I am willing to take the risk, and understand the risk, why can't I do it?

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

This issue appears in the ranked issue list on these topic pages, alongside a backlog trend for the whole topic.

MCP server connection issues →Context window & memory limits →

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems

Browse all Claude Code issue topics →