Write permission for skill .md files keeps prompting despite settings.local.json authorization

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21080
2. https://github.com/anthropics/claude-code/issues/16762
3. https://github.com/anthropics/claude-code/issues/6850

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

This issue is NOT a duplicate of the referenced issues. Here's why:

Key Differences

| Aspect | This Issue (#21242) | Referenced Issues |
|--------|---------------------|-------------------|
| Tool | Write tool (editing .md files) | Bash commands |
| Working Directory | ~/.claude (Claude Code's own config directory) | Regular project directories |
| Target Files | Skill .md files in ~/.claude/skills/ | Various shell command targets |

Why This May Require Different Handling

The ~/.claude directory is Claude Code's own configuration directory, not a regular project. This special directory:

1. Contains Claude Code's skills, commands, and settings
2. May have different permission handling logic than regular project directories
3. Is accessed via junction/symlink in my setup (.claude/ → ~/.claude)

The Write tool permission for skill .md files keeps prompting despite being saved in settings.local.json, which suggests the permission matching logic may not correctly handle paths within the ~/.claude directory.

Reproduction Context

• Running claude directly in ~/.claude directory
• Editing files like skills/design-plan/skill.md
• Permission granted and saved to settings.local.json
• Next edit to any skill .md file prompts again

This appears to be a Write tool permission issue specific to the ~/.claude directory, not a general Bash command permission issue.

I see this on macos as well.

Additional repro: Edit/Write path-scoped permissions in project settings ignored

Version: Claude Code 2.1.63 (Opus)
Platform: Linux (WSL2), bash

Setup

Project .claude/settings.json:

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

Steps

1. Restart Claude Code (confirmed settings are loaded)
2. Ask Claude to edit any file under .claude/rules/ (e.g., .claude/rules/client-spa.md)
3. Result: Still prompted with the "Do you want to make this edit?" dialog — permission pattern is ignored

Notes

• Read(.claude/**) works fine — only Edit and Write are affected
• The prompt offers "Yes, and allow Claude to edit its own settings for this session" — suggesting .claude/ has hardcoded special-case protection that bypasses the permission matching logic entirely
• Session restart confirmed; this is not a stale-settings issue

I see it on wsl/ubuntu 24

Is there any fix for this yet?
Am seeing this as well.
Claude keeps prompting for edit permission inside the .claude directory. This might be a safeguard due to the special nature of .claude, but this is getting in my way of setting .claude the way I want.

This is driving me insane approving individual edits whenever claude code is writing or updating skills in ~/.claude/skills

It's so annoying

Confirming this behaviour is still present on macOS as of April 2026, not just for skill .md files but for Edit, Write, and Bash operations generally.

Environment

• macOS 26.3.1
• Claude Code 2.1.110

Configuration

My ~/.claude/settings.json includes, among others:

"permissions": {
  "allow": [
    "Edit(~/lucie/**/*.md)",
    "Write(~/lucie/**/*.md)",
    "Read(~/lucie/**)",
    "Bash(mkdir *)",
    "Bash(cp *)",
    "Bash(chmod *)",
    "Bash(mv *)"
  ]
}

Observed behaviour

Despite these patterns matching, "Allow once / Allow always" permission prompts appear routinely for Edit / Write operations on .md files inside ~/lucie/, and for Bash commands like mkdir, cp, chmod on paths within approved directories. The prompts fire as if the allowlist entries were not present.

Impact

I maintain a carefully configured allowlist specifically to avoid interruption during long working sessions. In a typical ~8-hour session I click through ~100+ permission prompts that should have been covered by existing allowlist entries. This is not friction at the margin — it materially degrades the tool's usability for disciplined users.

Related issues

#15921 (Windows) and #27139 (closed as duplicate) describe the same underlying bug.

Workaround adequacy

The April 2026 /less-permission-prompts skill helps at the margin by scanning transcripts and suggesting allowlist entries, but it addresses the symptom (prompts fire) rather than the cause (matching allowlist entries are ignored). On my machine, running that skill produced an allowlist that still doesn't suppress the bulk of prompts, because the entries it adds share the same broken matching as the ones already there.

This has been an open regression for 3+ months. Would be grateful for any acknowledgement from the team on whether this is being triaged.