[BUG] --dangerously-skip-permissions does not bypass "edit its own settings" prompt for .claude/ directory writes

[adelfino69]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When running Claude Code with --dangerously-skip-permissions, writes to files inside ~/.claude/ still trigger a permission prompt:

Do you want to make this edit to .md?

1. Yes
   ❯ 2. Yes, and allow Claude to edit its own settings for this session
2. No

This happens every new session, defeating the purpose of the flag.

Steps to Reproduce

1. Configure settings.json with "defaultMode": "bypassPermissions" and "skipDangerousModePermissionPrompt": true
2. Launch with claude --dangerously-skip-permissions
3. Use any skill that writes files to ~/.claude/ (e.g., session-handoff, save-plan, or auto-memory)
4. The "edit its own settings" prompt appears despite the flag

Expected Behavior

--dangerously-skip-permissions should bypass ALL permission prompts, including writes to .claude/ directory. The flag name itself implies full bypass.

Actual Behavior

A hardcoded "protected directory" check for .claude/ overrides the --dangerously-skip-permissions flag. The user must manually approve once per session
(option 2).

Environment

• Claude Code version: 2.1.81
• OS: Windows 11 Pro
• Settings: defaultMode: "bypassPermissions", skipDangerousModePermissionPrompt: true
• Multiple plugins/skills enabled that write to ~/.claude/

Impact

This breaks autonomous workflows and CI/CD usage where no human is present to approve. It also creates friction for power users who have explicitly opted into
full bypass mode.

What Should Happen?

When --dangerously-skip-permissions flag is active, ALL permission prompts should be bypassed — including writes to the .claude/ directory. The flag name
explicitly says "dangerously skip permissions", so no permission check should override it. Currently a hardcoded "protected directory" check for .claude/ still
triggers the "edit its own settings" prompt every session, which defeats the purpose of the flag and breaks autonomous/unattended workflows.

Error Messages/Logs

Steps to Reproduce

1. Set "defaultMode": "bypassPermissions" and "skipDangerousModePermissionPrompt": true in ~/.claude/settings.json
2. Launch Claude Code with claude --dangerously-skip-permissions
3. Trigger any action that writes a file inside ~/.claude/ (e.g., a plugin skill writing a .md file, auto-memory saving to ~/.claude/projects/*/memory/, or
   session-handoff creating a handoff file)
4. A permission prompt appears: "Do you want to make this edit to .md? 1. Yes / 2. Yes, and allow Claude to edit its own settings for this session / 3. No"
5. This happens on every new session, regardless of the flag

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.81 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. Bypass permissions mode still prompts for edits to ~/.claude/settings.json #37029
2. [BUG] --dangerously-skip-permissions does not bypass "modify config files" prompt for ~/.claude/ writes #35718
3. Bug: SKILL.md creation prompts for permission even in bypass mode #36923

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[yurukusa]

Same as #37253 and #37157 — `~/.claude/` is a hardcoded protected directory that even `--dangerously-skip-permissions` won't bypass. This is by design to prevent the model from modifying its own hooks and settings.
Workaround — a PreToolUse hook that auto-approves writes to specific `.claude/` subdirectories:
```bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
[[ "$TOOL" != "Edit" && "$TOOL" != "Write" ]] && exit 0
case "$FILE" in
/.claude/commands/|/.claude/skills/|/.claude/agents/|/.claude/rules/)
jq -n '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":".claude subdirectory auto-approved"}}'
exit 0 ;;
esac
exit 0
```
This selectively allows writes to safe subdirectories while keeping `hooks/` and `settings.json` protected.

[adelfino69]

Additional findings — PreToolUse hooks also cannot bypass this

After investigating the workaround suggested in the comments (PreToolUse hook with permissionDecision: "allow"), I confirmed that it does not work either.

What I tried

1. Created a PreToolUse command hook that returns:

{
  "hookSpecificOutput": {
    "permissionDecision": "allow",
    "permissionDecisionReason": ".claude subdirectory auto-approved"
  }
}

2. Hook was correctly configured in settings.json with matcher Edit|Write
3. jq available, script executable, correct JSON output verified

Result

The "Do you want to make this edit? / Yes, and allow Claude to edit its own settings for this session" prompt still appears despite the hook returning allow.

Root cause analysis

The .claude/ self-edit protection operates at a separate layer from the permission system:

Layer	What controls it	Can be bypassed?
Permission rules	settings.json allow/deny lists	Yes (via --dangerously-skip-permissions)
PreToolUse hooks	Hook scripts returning permissionDecision	Yes (hooks can override)
Built-in self-edit protection	Hardcoded in source	No — nothing bypasses this

The self-edit protection for .claude/ fires after hooks, overriding any permissionDecision: "allow" from PreToolUse hooks. This means:

• --dangerously-skip-permissions → still prompts ❌
• defaultMode: "bypassPermissions" → still prompts ❌
• skipDangerousModePermissionPrompt: true → only skips the initial warning, not per-edit prompts ❌
• PreToolUse hook with permissionDecision: "allow" → still prompts ❌

Impact

This affects all users with plugins/skills that write to ~/.claude/ (auto-memory, session-handoff, save-plan, insights, etc.). The prompt appears every new session, requiring manual approval via option 2.

Suggestion

Either:

1. Make --dangerously-skip-permissions truly bypass everything (the flag name implies this)
2. Or add a setting like "allowSelfEdit": true that explicitly opts into bypassing the self-edit protection
3. Or at minimum, allow PreToolUse hooks to override it — the user has already explicitly configured the hook, showing intent

Environment

• Claude Code: 2.1.81
• OS: Windows 11 Pro
• All permission bypass options configured and verified

[yurukusa]

@adelfino69 Thanks for testing this so thoroughly. Your analysis is correct — my workaround was wrong for the .claude/ self-edit case.
The key finding from your table is that the built-in self-edit protection runs after PreToolUse hooks and overrides the allow decision. So even a correctly configured hook returning permissionDecision: "allow" gets ignored for .claude/ writes.
To clarify for others reading: PreToolUse hooks with permissionDecision do work for overriding protection on .git/ and .vscode/ directories (the other hardcoded protected paths). The .claude/ self-edit check is a separate, unhookable layer that none of the current bypass mechanisms can reach.
Agree that option 1 or 3 from your suggestions would resolve this cleanly.

[saidelike]

Idea... Have you tried adding a permission in your project or globally in the settings.json?

  "permissions": {
    "allow": ["Edit(/.claude/path/to/what/you/want/**)"]
  },

Or using Read(), Write(), etc.

[adelfino69]

I can confirm this doesn't work either. My settings.json already has the most permissive configuration possible:

{
  "permissions": {
    "allow": ["Read", "Edit", "Write", "Glob", "Grep", "..."],
    "defaultMode": "bypassPermissions"
  },
  "skipDangerousModePermissionPrompt": true
}

Edit and Write are allowed without any path restrictions, plus bypassPermissions mode is active. Adding "Edit(~/.claude/**)" would be redundant — unrestricted "Edit" already covers every path.

The self-edit prompt for .claude/ still appears every session.

This confirms @yurukusa's analysis: the .claude/ protection is a hardcoded layer that operates independently of the entire permissions system. No combination of settings can bypass it.