Repository navigation
bypassPermissions mode still prompts for edits to ~/.claude/ files #37253
Description
Activity
Found 3 possible duplicate issues:
- Bypass permissions mode still prompts for edits to ~/.claude/settings.json #37029
- acceptEdits mode still prompts for files in .claude/ directory (workspace root) #37107
- [BUG] bypassPermissions v2.1.81: .claude/skills/ not exempt from protected directory prompt despite documentation #37157
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
The `~/.claude/` directory is intentionally protected — it's a hardcoded exception in the permission system to prevent the model from modifying its own settings, hooks, and rules (which would be a security concern).
This is by design, not a bug. Even `bypassPermissions` won't bypass this protection because:- Hooks in `~/.claude/hooks/` control what Claude can do
- Settings in `~/.claude/settings.json` define permissions
- If Claude could modify these, it could escalate its own permissions
Workaround: Use a PreToolUse hook that auto-approves edits to specific `~/.claude/` subdirectories you trust:
```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/rules/)
jq -n '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":"custom commands/rules auto-approved"}}'
exit 0
;;
esac
exit 0
```
This selectively allows edits to `commands/` and `rules/` while keeping `hooks/` and `settings.json` protected.
@William-1776 Yes it is on purpose as described in https://code.claude.com/docs/en/permissions#permission-modes
You could maybe add:
"permissions": { "allow": ["Edit(/.claude/path/to/what/you/want/**)"] },
if that is really what you want.
Seeing a related but potentially distinct issue on v2.1.81 Linux. In my case, the file being created is inside the project working directory (not inside .claude/): commands/csw:cleanup.md. Bypass permissions is active per the status bar but the creation prompt still fires. The colon in the filename (csw:cleanup.md) may be a separate trigger — the namespace:command.md naming convention is common for slash commands. Happy to file separately if this is a different code path.
Seeing a related but potentially distinct issue on v2.1.81 Linux. In my case, the file being created is inside the project working directory (not inside .claude/): commands/csw:cleanup.md. Bypass permissions is active per the status bar but the creation prompt still fires. The colon in the filename (csw:cleanup.md) may be a separate trigger — the namespace:command.md naming convention is common for slash commands. Happy to file separately if this is a different code path.
Yes it is different.
Same issue on CLI (not just VS Code)
Experiencing the same behavior on Claude Code CLI with
bypassPermissionsmode.Reproduction
settings.json:
{ "permissions": { "allow": ["Bash"], "defaultMode": "bypassPermissions" }, "skipDangerousModePermissionPrompt": true }Action:
Bash(rm agent.md ...)inside~/.claude/commands/sc/Result:
"Claude requested permissions to edit /Users/.../.claude/commands/sc/agent.md which is a sensitive file."
The
Bashtool is already inpermissions.allow, andbypassPermissionsis active — yet the "sensitive file" guard still fires.Workaround
Adding
PermissionRequesthooks for all three tools that touch files:"PermissionRequest": [ { "matcher": "Edit", "hooks": [{ "type": "command", "command": "echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PermissionRequest\",\"decision\":{\"behavior\":\"allow\"}}}'" }] }, { "matcher": "Write", "hooks": [/* same */] }, { "matcher": "Bash", "hooks": [/* same */] } ]
This defeats the purpose of
bypassPermissions— you shouldn't need to manually re-bypass permissions that are already supposed to be bypassed.Environment
- Claude Code CLI (not VS Code)
- macOS 15 (Darwin 25.4.0)
defaultMode: "bypassPermissions"in~/.claude/settings.json
Same issue here.
macOS 15, VS Code latest, Claude Code extension latest.
bypassPermissionsconfigured in:- VS Code User Settings
- VS Code Workspace Settings (.vscode/settings.json)
- ~/.claude/settings.json (defaultMode: dontAsk)
- .claude/settings.json (project, defaultMode: dontAsk)
Still getting "Make this edit to [file]?" dialog when editing files inside
.claude/skills/.This is very disruptive when using Claude Code for automated workflows — every skill edit requires manual approval despite full bypass configuration.
This being on purpose does NOT make sense at all for memory file edits though... whats the point of having a living memory system if it will need permissions constantly in order to stay up to date... same for skills
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
ai 만드는 회사가 이런 버그도 못 고치다니...
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
- locked as resolved and limited conversation to collaborators
on Aug 16, 2026
Description
With
claudeCode.initialPermissionModeset to"bypassPermissions"in VS Code User settings, edits to files under~/.claude/(e.g.~/.claude/commands/*.md,~/.claude/rules/*.md) still trigger the "Make this edit to [file]?" confirmation dialog.Edits to files outside
~/.claude/(e.g. project files under~/Documents/) are correctly auto-approved — no prompt.Expected behavior
bypassPermissionsshould bypass all permission checks, including edits to~/.claude/files. If this directory is intentionally protected, this should be documented, and ideally there should be a way to opt out.Steps to reproduce
"claudeCode.initialPermissionMode": "bypassPermissions"in VS Code Usersettings.json~/.claude/(e.g. a custom command/skill file in~/.claude/commands/)~/.claude/— no dialog appearsEnvironment