Desktop app (Code tab, WSL2): Edit/Read allow rules in project .claude/settings.json not applied in Manual mode; same rules work in terminal CLI 2.1.278

Summary

In the Claude Desktop app's Code tab (WSL2), Edit(...) and Read(...) allow rules in the project's .claude/settings.json are not applied: matching edits and reads still prompt in Manual mode. The same rule file, in the same checkout, works as documented in the terminal CLI. Bash ask rules from the same file are honoured in the desktop app, so the file is being read.

Environment

• Claude Desktop 2.2553.1 on Windows 10, Code tab → WSL2 Ubuntu 24.04
• Bundled Claude Code 2.1.275 (CLAUDE_CODE_ENTRYPOINT=claude-desktop, CLAUDE_CODE_EXECPATH=~/.claude/remote/ccd-cli/2.1.275), Agent SDK 0.3.275
• Permission mode: Manual ("defaultMode": "default" in project settings)
• Sandbox enabled (bubblewrap), autoAllowBashIfSandboxed: true, failIfUnavailable: true
• Setting sources: user, project, local
• Control: terminal CLI 2.1.278 (native install, ~/.local/bin/claude), same machine, same checkout, Claude Max login

Project .claude/settings.json (relevant part)

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Edit(/CURRENT_STATE.md)",
      "Edit(/docs/vendor/**)",
      "Edit(/tasks/**)",
      "Read(~/.claude/settings.json)"
    ]
  }
}

(Plus Bash and WebFetch allow rules, and Bash ask/deny rules, omitted here.)

Observed in the desktop app

1. The Edit tool on CURRENT_STATE.md (project root) prompts "Allow Claude to edit …?" with buttons Deny / Always allow / Allow once — three times across two sessions, including the very first edit of a freshly started session (so not a stale in-process cache).
2. The Read tool on ~/.claude/settings.json prompts "Allow Claude to read settings.json? Path is outside allowed working directories", although an exact-path allow rule exists.
3. Bash ask rules from the same file (e.g. Bash(git branch -D *)) are honoured — the prompt appears exactly when expected.
4. The sandbox's writable-path list is derived from the same Edit rules (files named in single-file Edit allow rules appear as individually mounted paths), so the rules are parsed.
5. Always allow on the Edit prompt switches the session to Accept-edits mode (status bar changes from "Manual" to "accept edits") and writes nothing to .claude/settings.local.json; Always allow on the Read prompt writes nothing and suppresses only later reads in that session.

Control in the terminal CLI (2.1.278)

Same checkout, same settings files, Manual mode ("manual mode on" in the status bar), Claude Max login. Prompt: "add one blank line at the end of tasks/open/.md". The Edit under Edit(/tasks/**) ran with no permission prompt.

Expected

Per https://code.claude.com/docs/en/permissions ("Read and Edit", "Manage permissions"): a matching Edit/Read allow rule in project settings pre-approves the edit/read in Manual mode. CURRENT_STATE.md is not a protected path.

Question

Is there a desktop-app-side permission layer that consults only the working-directory check and not settings-file allow rules for the file tools? Or is this a 2.1.275 defect fixed by 2.1.278 (we could not update the desktop's bundled CLI to test)? Either answer would help.

Possibly related: a report about scheduled Routines re-prompting despite Write(...) allow rules in user settings — but note that report uses Write(...) rules, which the docs say are accepted but never consulted; this one uses Edit/Read rules that work in the terminal CLI.

Reproduce the permission behavior using the project .claude/settings.json in the Desktop Code tab on WSL2, then compare it with the terminal CLI control described in the issue. Trace how Edit and Read allow rules are evaluated in Manual mode; done means matching rules are honored consistently or the desktop-specific/version limitation is documented.