bypassPermissions .claude/skills/ safeguard: Edit tool not covered by exemption, and session allows are ignored

Two related issues with the .claude/ safeguard in bypassPermissions mode.

Background

Per the permissions docs:

bypassPermissions mode skips permission prompts. Writes to .git, .claude, .vscode, .idea, and .husky directories still prompt for confirmation to prevent accidental corruption of repository state, editor configuration, and git hooks. Writes to .claude/commands, .claude/agents, and .claude/skills are exempt and do not prompt, because Claude routinely writes there when creating skills, subagents, and commands.

---

Bug 1: .claude/skills/ exemption doesn't apply to the Edit tool

Repro:

1. defaultMode: "bypassPermissions" in ~/.claude/settings.json
2. Additionally have a broad persistent allow like Edit(/Users/<me>/**) in the same settings file
3. Call the Edit tool on an existing <project>/.claude/skills/<skill-name>/SKILL.md

Expected: edit goes through silently (per the documented exemption).
Actual: permission prompt appears.

**Workarounds that do not prompt:**

• Bash with printf '...' >> <file> on the same path (direct shell write)
• Presumably Write for a full file rewrite

So the .claude/{commands,agents,skills} exemption appears to only cover the Write tool (creating/overwriting files), not the Edit tool (modifying existing files). Expected behavior is that Edit on these paths should be equally exempt — Claude routinely modifies (not just creates) skill/agent/command files once they exist.

---

Bug 2: User-granted session allows don't override the .claude/ safeguard

When the prompt from Bug 1 appears, the user chose "Yes, don't ask again for this session" (the standard option-2). The expectation: the session-level allow rule satisfies subsequent checks, so the next Edit on the same file goes through silently.

Actual: the very next Edit on the same file prompts again immediately, with no change in Claude's behavior from before option-2 was chosen.

This strongly suggests the .claude/ safeguard is evaluated before any allowlist check — so session allows (and possibly even explicit persistent allows in settings.json) cannot suppress it.

This isn't documented anywhere, and it contradicts the general contract of "don't ask again for this session," which everywhere else in the tool persists the allow for the session's lifetime.

Suggested fixes (either/both):

• Make "don't ask again" actually work on safeguarded paths (evaluate allow rules above the safeguard).
• Or: don't offer the "don't ask again" option on safeguarded paths if it's going to be silently ignored — it's confusing UX.

---

Environment

• macOS 15.4 (Darwin 25.4.0)
• Claude Code running Opus 4.7