VS Code extension ignores Edit/Write permission rules in settings files

[landon-homeriz]

Bug Description

Edit and Write permission rules configured in .claude/settings.local.json and .claude/settings.json are not respected by the VS Code extension. The permission prompt still appears for every Edit/Write tool call regardless of configuration.

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Code: VS Code extension (latest)
• Shell: bash (Git Bash)

Configuration

.claude/settings.local.json (project-level):

{
  "permissions": {
    "allow": [
      "Write(.claude/**)",
      "Edit(.claude/**)"
    ]
  }
}

.claude/settings.json (project-level):

Also contains Bash permission rules that DO work correctly.

Steps to Reproduce

1. Add Edit(.claude/**) or even Edit(**) to the allow list in .claude/settings.local.json
2. Start a session in VS Code extension
3. Have Claude attempt to edit any file matching the pattern (e.g., .claude/skills/knowledge-ingestor/scripts/store_knowledge.py)
4. Permission prompt still appears asking for approval

Expected Behavior

Edits matching the configured allow patterns should be auto-approved without prompting.

Actual Behavior

Permission prompt appears for every Edit/Write call regardless of configured rules. This happens across all sessions (not limited to restored/stuck sessions). Restarting VS Code does not resolve it.

Notes

• Bash permission rules in the same settings files appear to work correctly
• This affects productivity significantly when sessions need to make many edits
• Tested with both narrow patterns (Edit(.claude/**)) and broad patterns (Edit(**)) — neither is respected
• May be related to Windows path normalization (forward slash patterns vs backslash actual paths)

[landon-homeriz]

Additional context: My global ~/.claude/settings.json already has ALL three bypass mechanisms enabled simultaneously:

1. "defaultMode": "bypassPermissions"
2. "skipDangerousModePermissionPrompt": true
3. "Edit(/.claude/skills/knowledge-ingestor/**)" in the allow list

The Edit permission prompt still appears for files under .claude/skills/ — which the docs state should be exempt from protected directory checks.

This appears to be the same regression introduced in v2.1.78 described in #35718, where the protected directory logic overrides all configured bypass mechanisms for .claude/ paths, even for the documented exempt subdirectories (skills, commands, agents).

Environment detail: Windows 11 with Git Bash — Windows path normalization may also be a factor, since .claude/settings.json Edit rules use forward-slash POSIX patterns but actual paths are resolved as C:\Users\...\.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] VSCode Extension: .claude/settings.local.json permissions not respected for Bash/Write/Edit operations (even with bypassPermissions mode) #15921
2. [BUG] allowedTools glob patterns never match Windows backslash paths — no pattern format works #30736
3. [BUG] Permission patterns not working on Windows/WSL - session-level allow ignored #29574

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[yurukusa]

This is likely a path normalization issue on Windows. A few things to try:

1. Check which settings file is actually being loaded:

The VS Code extension may load settings from a different location than the CLI. Run this in the Claude Code terminal panel:

cat ~/.claude/settings.json | jq '.permissions'

vs check your project-level .claude/settings.local.json.

2. Try backslash patterns (Windows-specific):

On Windows, file paths internally use backslashes. The permission matcher might not normalize forward slashes:

{
  "permissions": {
    "allow": [
      "Edit",
      "Write"
    ]
  }
}

Start broad — if "Edit" (no pattern) works but "Edit(**)" doesn't, it's definitely a glob pattern issue on Windows.

3. Use user-level settings instead of project-level:

Put the rule in ~/.claude/settings.json (user-level) rather than .claude/settings.local.json (project-level). The VS Code extension may not load project-level settings in all launch contexts.

4. Workaround with hooks:

If permission rules aren't working, a PermissionRequest hook can auto-approve Edit/Write operations:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty')
if [[ "$TOOL" == "Edit" || "$TOOL" == "Write" ]]; then
    jq -n '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","permissionDecision":"allow"}}'
fi

The Bash permission rules working but Edit/Write not working strongly suggests this is specific to how the VS Code extension handles non-Bash tool permission patterns on Windows.