Project-level skills in .claude/skills/ are now uneditable — protection conflicts with core feature design

Resolved 💬 4 comments Opened Mar 19, 2026 by soliblue Closed Apr 30, 2026

Environment

  • Claude Code version: 2.1.78
  • OS: macOS
  • Permission mode: bypassPermissions (with Write(.claude/**) and Edit(.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: bypassPermissions in global settings
  • The user has explicit Write(.claude/**) and Edit(.claude/**) allow rules in settings.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

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗