iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🔐

--dangerously-skip-permissions isn't the ultimate solution: Why you should use 'auto mode' for skill development

に公開
AI
設定
Anthropic
Claude Code
tech

Permission Dialogs Never Stop During Skill Development

This was the first hurdle I encountered when I started building skills with Claude Code. Every time I tried to create a new skill, edit one, or delete one, the permission dialog would pop up over and over again in every session.

It happens just by creating a directory for a skill.

Permission dialog when creating a skill directory

It happens every time SKILL.md is written. As option 2, Yes, and allow Claude to edit its own settings for this session, states, even if you grant permission, it is treated as being valid "only for this session," and you are asked again from scratch next time.

Permission dialog when writing the skill itself

It is the same even when you try to delete a skill that is no longer needed.

Permission dialog when deleting a skill

I couldn't make any real progress because I was stuck in a loop of clicking "Yes." Moreover, starting a new session meant starting from zero again. Nurturing a skill had become a game of clicking permission buttons.

After spending three full hours investigating this issue, I finally found the solution: starting with --permission-mode auto. This article is the record of that investigation and the conclusion.

A List of Things I Tried That Didn't Work

To give you the conclusion first, file operations under .claude/skills/ are treated as "protected paths" in Claude Code, and for write-related operations, security protection is prioritized above all else. Therefore, among the methods commonly cited as ways to "remove all permission prompts," most do not work for .claude/skills/.

Here is a list of the specific methods I tried that failed.

1. Setting defaultMode: "bypassPermissions" in settings.json

If you put the following in .claude/settings.json, permission prompts will stop appearing for ordinary file edits.

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

However, this does not work for editing or deleting files under .claude/skills/. The permission dialogs continue to appear.

2. Adding Write(.claude/**) / Edit(.claude/**) to allow 

{
  "permissions": {
    "allow": [
      "Write(.claude/**)",
      "Edit(.claude/**)"
    ]
  }
}

This also doesn't work. Even if you explicitly allow the path, the write prompts for .claude/skills/ keep popping up.

3. Starting with the --dangerously-skip-permissions flag

This mode is generally treated as the strongest option. It is also known as the "YOLO mode."

claude --dangerously-skip-permissions
# Or the new flag
claude --permission-mode bypassPermissions

Even with this, the write prompts for .claude/skills/ do not disappear. Faced with the reality that the mode I thought was the strongest didn't work, I initially doubted whether I had made a mistake in my configuration.

4. Auto-allow via PermissionRequest hook

This approach involves setting a PermissionRequest hook in settings.json to return a JSON that automatically allows access under .claude/skills/.

{
  "hooks": {
    "PermissionRequest": [{
      "matcher": "Write|Edit|Bash",
      "hooks": [{
        "type": "command",
        "command": "jq -e '(.tool_input.file_path // .tool_input.command // \"\") | test(\"\\\\.claude/skills/\")' >/dev/null 2>&1 && echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PermissionRequest\",\"permissionDecision\":\"allow\"}}' || true"
      }]
    }]
  }
}

I confirmed via pipe-test that the command alone returned allow, but during actual tool invocation, protection is applied at a layer before the hook, so the prompts continue to appear.

Official Documentation Backs This Up

When I returned to the official documentation after all my attempts failed, I found the following statement in Choose a permission mode:

Regardless of mode, writes to protected paths are never auto-approved, guarding repository state and Claude's own configuration against accidental corruption.

In other words, "Regardless of mode, writes to protected paths are never auto-approved." The .claude directory is included among these protected paths.

The documentation also states that .claude/commands/, .claude/agents/, .claude/skills/, and .claude/worktrees/ should be treated as exceptions (not subject to protection). However, in actual practice, protection is still active for .claude/skills/, and prompts appear.

This has been reported multiple times in GitHub issues:

  • Issue #36497: .claude/skills/ edits prompt for permission despite being documented as exempt (regression in 2.1.79)
  • Issue #37157: bypassPermissions v2.1.81: .claude/skills/ not exempt from protected directory prompt despite documentation
  • Issue #38806: Allow bypassPermissions mode to fully bypass .claude/ directory protections

It is highly likely that a regression since v2.1.79 has caused the skill exemption to stop working. At the very least, the documentation and the actual implementation remain out of sync.

The Solution: Start in auto mode

After trying various things, the only solution I found was to start with --permission-mode auto.

claude --permission-mode auto

When you execute a write operation to the skill directory while started in this mode, it goes through without a permission prompt.

I usually launched Claude Code using an alias named yolo.

# Before
alias yolo="claude --dangerously-skip-permissions"

# After
alias yolo="claude --permission-mode auto"

The moment I switched to this, the stress of skill development almost entirely disappeared.

Constraints of auto mode

It is not a silver bullet. It has the following constraints:

Item Content
Plan Must be Max / Team / Enterprise / API
Model Must be Opus 4.6 or later
Response speed Can feel slightly slower in some scenes because a classifier is inserted

You cannot use this with the Pro plan or Haiku. This is the biggest constraint, and the frustration of "I just want to turn off the permission prompt, why is it tied to a plan?" remains. However, I think choosing Max is a realistic option if you are serious about building skills.

Bypass and Auto are Designed Differently

Interestingly, while bypass and auto might look like "modes that permit everything," their design philosophies are completely different:

  • bypassPermissions: Designed to bypass the evaluation layer of permission rules (allow/deny/ask) written by the user. However, protection for protected paths remains because it operates at a separate layer.
  • auto mode: Designed so that Anthropic's safety classifier makes dynamic judgments. Protection for protected paths can also be treated as a target for classifier evaluation.

Intuitively, one might think "bypass, which skips everything, is stronger." But for protected paths, auto, which can dynamically allow operations via classifier evaluation, is more effective. This asymmetry was the reason it took me 3 hours to resolve the issue, as I initially trusted bypass completely.

The official Auto Mode for Claude Code article also explains that auto mode functions through a two-layer defense consisting of a transcript classifier and a prompt-injection probe. Having this classifier layer is what makes it possible to handle protected paths.

Summary

  • Writes under .claude/skills/ are not passed through by bypassPermissions, --dangerously-skip-permissions, allow rules, or PermissionRequest hooks.
  • This is highly likely a regression since v2.1.79, and there is a discrepancy between the official documentation and the implementation.
  • The only method that works at present is launching with claude --permission-mode auto.
  • However, a Max plan or higher is required.
  • If you cannot subscribe to the plan, a realistic workaround is to add a +1 to GitHub Issue #38806 to increase its priority.

If you are serious about developing skills, you should switch to launching in auto mode. The moment I switched, I was freed from the battle with permission dialogs.

References

Discussion