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

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.