`.claude/skills/` edits prompt for permission despite being documented as exempt (regression in 2.1.79)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/36396
2. https://github.com/anthropics/claude-code/issues/36155
3. https://github.com/anthropics/claude-code/issues/35646

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

Workaround confirmed: PermissionRequest hook

The Edit(.claude/**) / Write(.claude/**) allow-list approach mentioned in the issue does not work — the hardcoded protected-directory check fires before the allow-list is consulted (separate layer).

What works: PermissionRequest hook

Added to settings.local.json:

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/permission-auto-approve.sh",
            "timeout": 3
          }
        ]
      }
    ]
  }
}

Hook script (permission-auto-approve.sh):

#!/usr/bin/env bash
set -uo pipefail
input="$(cat)"
file_path=$(printf '%s' "$input" | jq -r '.tool_input.file_path // empty' 2>/dev/null)

# Auto-approve .claude/ writes except settings files
if [[ -n "$file_path" && "$file_path" == */.claude/* && "$file_path" != */.claude/settings* ]]; then
  printf '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","decision":{"behavior":"allow"}}}'
fi

Test results (20/20)

Main agent — PermissionRequest hook (10/10 PASS):

• .claude/skills/, .claude/hooks/, .claude/rules/, .claude/agents/ — auto-approved
• .claude/settings* — correctly blocked (prompt still appears)
• Regular files — unaffected
• Edge cases (empty path, malformed JSON, deep nesting) — handled safely
• Live test: Edit tool on .claude/skills/ file — no prompt

Sub-agent — Bash writes (10/10 PASS):

• PermissionRequest hooks do not fire for sub-agents
• Workaround: sub-agents use Bash (cat >, sed -i, tee, etc.) instead of Edit/Write
• All .claude/ subdirectories writable via Bash without prompts

Limitations

| Scope | Works? | Note |
|-------|--------|------|
| Main agent (CLI terminal) | ✅ | PermissionRequest hook |
| Sub-agents | ⚠️ | Bash only (#23983) |
| VS Code extension | ❌ | PermissionRequest hooks don't fire (#35942) |
| -p (non-interactive) mode | ❓ | Untested |

Credit: approach from #36044 (@echthesia).

+1 — Hitting this exact issue. I have an umbrella workspace with multiple Areas, each with their own .claude/skills/ directories (e.g., ~/Documents/Antigravity/Areas/YouTube/.claude/skills/foo/SKILL.md).

The /.claude/ path pattern match triggers the protection on every project-level .claude/skills/ edit, not just ~/.claude/. This makes bypass permissions mode unusable for any workflow that programmatically updates skills.

Environment:

• Claude Code v2.1.91
• macOS
• bypassPermissions mode with explicit Edit(.claude/**) and Write(.claude/**) allow rules — neither overrides the hardcoded protection

The two issues as I understand them:

1. The documented .claude/skills/ exemption was never implemented (only commands/ and agents/ are exempted)
2. The protection matches /.claude/ anywhere in the path, so project-level .claude/ dirs get the same treatment as ~/.claude/

Both need to be fixed — even if the skills exemption worked, it still shouldn't be protecting project-level .claude/ directories the same way it protects the root config.

This issue is preventing the full use of the Skills feature.
There are several types of documents that one might want to update in a collated skill folder, such as JSON state trackers or perhaps other ancillary markdown prompts.

This is blocking significant work and certainly want to stay up-to-date when the bypassPermissions finally actually does indeed _bypass permissions_.

This regression is such bullshit. I can't get any combination of hooks and permissions to overwrite this embedded claude code behavior.

The only real fix that I found is just write a script to force overwrite what's in the ~/.claude from what you have somewhere else in version control.

Update: The .claude/ protection is even more aggressive than I thought. It doesn't just block ~/.claude/ — it blocks any path containing .claude/ anywhere in the filesystem.

I just tested ~/dotfiles/test/.claude/test.txt and got two permission prompts (one for Read, one for Edit), despite having Edit(/Users/jameshounshell/dotfiles/**) in my allowlist.

So if you happen to have a directory named .claude/ anywhere in your repo structure — maybe you're version-controlling Claude configs, maybe you're building tooling around Claude, maybe you just like the name — Claude Code will block every read and write operation to any file inside it, regardless of wildcards, regardless of permissions, regardless of common sense.

The only workaround: don't use the name .claude/ anywhere. Ever. For anything. Because apparently it's a reserved keyword for the entire filesystem.

I ran into the same issue trying to let Claude use a temp directory at ~/.claude/tmp to keep claude's scratchwork in one place while working on various things across multiple projects. I naively tried to grant permissions to ~/.claude/tmp/** by adding it to the allow list for the Read and Edit tools only to discover the strict guard against edits to everything within ~/.claude that takes precedence. I also rely on Claude self-enhancing skills, but don't yet have an automated workflow so I hadn't encountered that friction. That said, while I think the higher-level restriction is warranted, users should still be able to override those permission paths at their own peril. I can move my temp directory or experiment with a permission hook, but enabling the ability to self-edit skills should be a simple toggle and merits a mention in the permission docs.

Pretty glaring bug but unfortunately it'll be several months before it's even acknowledged ☹️

ai 만드는 회사가 이런 버그도 못 고치다니...

This is still an issue.