Project-level skills in .claude/skills/ are now uneditable — protection conflicts with core feature design
Environment
- Claude Code version: 2.1.78
- OS: macOS
- Permission mode:
bypassPermissions(withWrite(.claude/**)andEdit(.claude/**)in allow rules)
Problem
v2.1.77/2.1.78 hardcoded .claude/ as a protected directory, blocking Write and Edit tool calls even when:
- The user has
defaultMode: bypassPermissionsin global settings - The user has explicit
Write(.claude/**)andEdit(.claude/**)allow rules insettings.local.json
This creates a direct conflict with Claude Code's own feature design. Project-level skills are supposed to live at .claude/skills/ — this is documented, first-class behavior. But now Claude cannot create or edit them without triggering a prompt that has no override.
The contradiction
The docs say:
Skills extend what Claude can do. Create a SKILL.md file with instructions... Project skills: .claude/skills/<skill-name>/SKILL.md — This project only.
But Claude can no longer write to .claude/skills/ autonomously, even with explicit user consent via allow rules. The protection defeats the intended workflow entirely.
What makes this worse
Write(.claude/**) and Edit(.claude/**) in permissions.allow have no effect. The user explicitly said "allow writes to .claude/" and Claude Code ignores it. If allow rules can't override this, what are they for?
The only workaround is piping through Bash (sed, cat >) — which is less auditable than a Write tool call and harder for the user to review. The protection is actively pushing the operation into a less visible channel.
Specific use case
I run plans (lightweight ticket files) at .claude/plans/ and skills at .claude/skills/. Every session involves creating, editing, and moving these files. Since 2.1.77, every one of these operations now requires manual approval — in a session where I've already granted blanket permission.
The workaround is moving plans to a plans/ directory at the repo root, which I'm doing. But .claude/skills/ has no equivalent escape hatch — skills are designed to live there.
Proposed fix
Honour explicit allow rules. If a user adds Write(.claude/**) to their allow list, that should be treated as consent. The protection should be a default that explicit allow rules can override — not a hardcoded wall that ignores the permission system entirely.
Alternatively, scope the protection to the files that actually matter: settings.json, settings.local.json, hooks/. Not the entire .claude/ tree including skills, plans, and other user-created content.
Related
- #35646 — same root cause from the bypass mode angle
- #35942 — feature request for opt-in override
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗