Skill(name) allow-list + bypassPermissions do not suppress the interactive skill-use prompt

[DOCUMENT_TYPE: internal]
<!-- Staging file for gh issue create --body-file; not itself a client deliverable. -->

Summary

Skill(<name>) allow-list entries in settings.local.json, combined with defaultMode: "bypassPermissions", do not reliably suppress the interactive "Use skill?" confirmation prompt for the Skill tool. Separately, on the same session, writes into .claude/hooks/ are blocked outright by a "Self-Modification" classifier layer regardless of bypassPermissions, matching prior closed reports.

This is a fresh repro on a current version, filed because the closest prior reports (#37939, #37745, #41526, #51571, #41259, #21080) were all closed as duplicate/not-planned/stale without the underlying behavior being fixed, and none is an exact match for Skill-tool invocation specifically (most are about SKILL.md file edits).

Environment

• Claude Code version: 2.1.282
• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell (primary)

Repro 1: Skill invocation prompt ignores allow-list + bypassPermissions

.claude/settings.local.json contains:

{
  "permissions": {
    "allow": [
      "Skill(session-report-artifact)"
    ],
    "defaultMode": "bypassPermissions"
  }
}

Invoking Skill(session-report-artifact) still produces an interactive confirmation dialog:

Use skill "session-report-artifact"?
Claude may use instructions, code, or files from this Skill.
Do you want to proceed?
1. Yes
2. Yes, and don't ask again for session-report-artifact in <project path>
3. No

This is not the skill's first-ever invocation in this project -- the allow entry already existed in settings.local.json from a prior session's "don't ask again" selection, confirmed by reading the file directly before the prompt fired again.

Checked before filing, not assumed:

• ~/.claude.json's per-project allowedTools array is empty for this project (and every other project/worktree entry in the same file), ruling out a stale separate permission cache as the cause.
• The user-level ~/.claude/settings.json has no Skill entry at all, wildcard or otherwise, so the project-level Skill(name) entries are the only mechanism granting skill permissions, and the specific skill in question was already present there.

Repro 2: .claude/hooks/ writes blocked regardless of bypass mode (Self-Modification classifier)

With the same bypassPermissions config active, both Write (creating a new file under .claude/hooks/) and Bash/PowerShell (Test-Path against a path under the same directory) were denied outright by a distinct layer, surfaced as:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Self-Modification].
...
To allow this type of action in the future, the user can add a Bash permission rule to their settings.

This matches the exact shape of #37939 ("writes to .claude/ directory still prompt regardless of bypass mode, including paths that should be exempt") -- except here it's an outright denial rather than a prompt, and it blocks a bare read-only existence check (Test-Path) on the same path, not just writes.

Why filing fresh instead of commenting on the closed issues

• #37939, #37745 -- closed NOT_PLANNED, same .claude/ self-modification family, but about writes/hook-reset, not Skill-tool invocation specifically.
• #41526, #51571 -- closed DUPLICATE, about SKILL.md file edits prompting despite bypass mode, not Skill invocation.
• #41259 -- closed NOT_PLANNED, general settings.local.json desync after an Edit tool modifies it.
• #21080 -- closed NOT_PLANNED, general "don't ask again" not persisting across sessions.

None of these five is a clean match for "an already-allowlisted Skill tool invocation still prompts on a later session." This report is scoped to that specific gap, with a current-version repro, plus a second, related repro (Repro 2) showing the adjacent .claude/ self-modification block is still live today, six months after #37939 was filed.

Expected behavior

A Skill(<name>) entry in permissions.allow, or defaultMode: "bypassPermissions", should suppress the interactive confirmation for that skill's invocation in all future sessions for that project, consistent with how other tool types' allow-list entries behave.