[BUG] v2.1.78: Protected directory prompt in bypassPermissions has no override — forces hacky workarounds

i found this problem minutes ago too! This break my daily workflow as well.

I already filed a duplicate issue

But why, I was earlier :-) But i dont mind which we keep open... (though yes, you did file a duplicate, did your Claude not do a proper search or did mine select a shitty title?)

+1

But why, I was earlier :-) But i dont mind which we keep open... (though yes, you did file a duplicate, did your Claude not do a proper search or did mine select a shitty title?)

The former I suppose, I already fired my agent

I hesitate to share it, in case it get "patched", but maybe they'll fix this mess if they work this issue: symlinks seem to be safe, so if you symlink the skills folder, or even all of .claude, it seems to work.

Hard to believe this was the intended behavior. I expected to pop in and find a bug report and it turns out this is the "fix"! I've had agents working on optimizing our claude code structure for months now.

This is driving me insane approving individual edits whenever claude code is writing or updating skills in ~/.claude/skills

Click fatigue destroys security

Very true, and is how you end up with people running fully permissive openclaws everywhere 😅

Fix incoming

[BUG] v2.1.81 (Windows): Protected directory prompt persists in bypassPermissions — breaks long-running automated pipelines

Environment

• Claude Code version: 2.1.81
• OS: Windows (native)
• Permission mode: --dangerously-skip-permissions

Problem

v2.1.78 introduced: "Fixed .git, .claude, and other protected directories being writable without a prompt in bypassPermissions mode."

This prompt persists in v2.1.81 despite #35646 being closed as fixed. On Windows (native), every single Write to any .claude/ path triggers a confirmation prompt — even with --dangerously-skip-permissions, and even for the same file written multiple times in the same session.

Evidence

The following terminal output shows analysis_manifest.md being prompted twice in the same session, back-to-back:

● Update(.claude\analysis\_manifest.md)
  ⎿  Added 13 lines, removed 9 lines
     [A_PIPELINE_STATE updated: phase → COMPLETED]

● Now update DF_PIPELINE_STATE to reflect A-Pipeline completion.

● Update(.claude\analysis\_manifest.md)
──────────────────────────────────────────────────────────
 Do you want to make this edit to _manifest.md?
 > 1. Yes
   2. Yes, and allow Claude to edit its own settings for this session
   3. No

Same file. Same session. Second prompt fired anyway.

Workaround (does not exist)

Option "Yes, and allow Claude to edit its own settings for this session" does not suppress subsequent prompts — not even for the same file in the same session. There is no working workaround for automated runs.

Affected paths

Not limited to .claude/skills/. My system uses .claude/ for full pipeline state management across a multi-phase orchestrated agent system:

• .claude/*.md — global, project-agnostic state
• .claude/<pipeline>/ — per-process state: manifests, parking-lots, phase tracking, pattern libraries, task definitions

Why this is a complete workflow blocker

My pipeline is recursive and designed to run unattended for hours. Phases include:
taskDefinition → work → pre-PR → post-PR → patternLibraryUpdate → ...

Each phase transition writes to .claude/ state files. Since the prompt fires on every single write — including repeated writes to the same file — the pipeline cannot progress without constant manual intervention.

Concretely:

• A pipeline that previously ran unattended for hours now requires a manual keypress at every state update
• Prompts appear at unpredictable times, e.g. hours into a run when transitioning between phases
• There is no way to pre-authorize writes at session start
• Subprocess / CI runs are completely broken

Why the fix likely did not land on Windows

The original report (#35646) was filed on Linux/Ubuntu. Windows uses backslash paths (.claude\pipeline\manifest.md). The protected-directory bypass check likely does not handle Windows path separators correctly, causing the fix to have no effect on Windows.

Related

• #35646 — original issue (closed as fixed — regression on Windows)

I can confirm that this is happening on Mac and linux as well (not only Windows) for the latest version 2.1.81

Still happening for me too.

Still happening for me to on windows ,working on a WSL folder

I'm having this issue on verision 2.1.81, on Mac

Just FYI - I think the "fix incoming" was after release of 2.1.81 - i jumped back to .66 and waiting for 82 until i try again. Just for all trying in 81 - think this will be earliest in 82 (just guessing though, but timeline does not fit an include in 81 according to my Claude) - also do not see it here, so i assume really gotta wait for 82:

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Just FYI - I think the "fix incoming" was after release of 2.1.81 - i jumped back to .66 and waiting for 82 until i try again. Just for all trying in 81 - think this will be earliest in 82 (just guessing though, but timeline does not fit an include in 81 according to my Claude) - also do not see it here, so i assume really gotta wait for 82: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Thanks @cruppertautomation-ai I'm already a few hours into trying to debug my setup and this saved me from going deeper down that rabbit hole.

Sharing my temporary workaround until the fix ships

Still hitting this on 2.1.81. I needed writes to ~/.claude/skills/ and .claude/skills/ (project-level) to go through without prompting for slash commands that write skill/report files. Sharing in case it's useful. Happy to hear if there's a better approach or if I'm missing edge cases.

The workaround is a PermissionRequest hook that auto-approves reads and writes to the three exempt subdirectories.

Add to any settings file (~/.claude/settings.json, .claude/settings.json, or .claude/settings.local.json). Merge into existing hooks if you already have hooks configured:

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "Read|Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'if sed -n \"s/.*\\\"file_path\\\":[[:space:]]*\\\"\\([^\\\"]*\\)\\\".*/\\1/p\" | grep -qE \"^($HOME/\\.claude|\\.claude)/(skills|commands|agents)/\"; then echo \"{\\\"hookSpecificOutput\\\":{\\\"hookEventName\\\":\\\"PermissionRequest\\\",\\\"decision\\\":{\\\"behavior\\\":\\\"allow\\\"}}}\"; fi'"
          }
        ]
      }
    ]
  }
}

Uses sed and grep to keep dependencies minimal. These are available on macOS, Linux, and Windows via Git Bash (which Claude Code uses internally on Windows). If you have jq, you can replace the sed extraction with jq -r ".tool_input.file_path // empty" for more robust JSON parsing.

How it works: The hook fires when the protected directory prompt is about to appear. It extracts tool_input.file_path from the hook input and checks whether it starts with $HOME/.claude/skills/, commands/, or agents/ (global) or .claude/skills/, commands/, or agents/ (project-level). If matched, it returns an allow decision and the prompt is skipped. Other .claude/ paths (e.g., settings.json) still trigger the normal prompt.

Lightly tested with Read, Write, and Edit tools on Linux (bypassPermissions mode) and macOS (acceptEdits mode). Not tested on Windows, but Claude Code uses Git Bash internally there, so bash/sed/grep/$HOME should be available.

Nice one, i have a way bigger hook system in place anyway, but i was missing that hook. One possibly important note (though its unverified and I am to lazy to look into it - I had behaviour when hitting the permission prompt (and approving it) that it was loosing the "dangerously skip" flag completely - falling back to asking for every tool call. I think in that case even the "approve for this session" broke. Might have been side effect of my setup, or some ugly gotcha... Again, just FYI, but I guess with the above hooks its still possible to mitigate. I mean I could even write my own "dangerous" by simply approving all.

For anybody (like me) who missed a few hooks which came "recently" here is a list my Claude just compiled - after he realized there are way more hooks than he though there are:

• v2.0.45+ (Nov 2025 - Early 2026) — PreToolUse, PostToolUse, UserPromptSubmit, Notification, Stop, SubagentStart, SubagentStop, PermissionRequest
• v2.1.47 (Feb 18) — SessionStart
• v2.1.49 (Feb 19) — ConfigChange
• v2.1.50 (Feb 20) — WorktreeCreate, WorktreeRemove
• v2.1.63 (~Mar 1) — HTTP hook type added
• v2.1.69 (Mar 5) — InstructionsLoaded
• v2.1.72 (Mar 10) — TeammateIdle, TaskCompleted
• v2.1.76 (Mar 14) — PreCompact, PostCompact, Elicitation, ElicitationResult
• v2.1.78 (Mar 17) — StopFailure, SessionEnd

PS: HTTP hooks are neat, removes overhead of python call, gets timing down to MS - you can have one persistant service containing all the logic which is ready when hook fires and answers fast, got a few rust ones for that.. (we did switch to that pattern a while back, but I forgot to force him to look up full available hook list)

Still broken on v2.1.83 (macOS) — protected-dir check short-circuits before PermissionRequest hooks in -p mode

Version: 2.1.83
OS: macOS (Darwin 25.3.0)

Finding

The protected-dir check in claude -p mode never fires a PermissionRequest event, so the hook workaround shared by @wdelhagen cannot work for non-interactive subprocess invocations.

Evidence from stream-json output

The model does call the Write tool. The harness intercepts it and returns an error directly — no PermissionRequest event is generated:

// Model calls Write
{"type":"assistant","content":[{"type":"tool_use","name":"Write","input":{"file_path":"/Users/.../.claude/.tmp/test.txt","content":"hello"}}]}

// Harness returns error directly (no PermissionRequest, no hook fired)
{"type":"user","content":[{"type":"tool_result","content":"Claude requested permissions to edit .../.claude/.tmp/test.txt which is a sensitive file.","is_error":true}]}

// Final result includes permission_denials
{"type":"result","permission_denials":[{"tool_name":"Write","file_path":".../.claude/.tmp/test.txt"}]}

Verification

A PermissionRequest hook with debug logging (echo "$INPUT" >> /tmp/hook-debug.log) confirms:

• Interactive session (bypassPermissions): hook fires, log populated, write succeeds
• claude -p (any permission mode): hook never fires, log stays empty, write blocked
• claude -p --dangerously-skip-permissions: same — hook never fires, write blocked

The protected-dir check runs at a layer below the PermissionRequest event system. In interactive mode it goes through PermissionRequest (hookable). In -p mode it short-circuits to an immediate error return.

Impact

This blocks claude -p subprocess workflows that need to write to ~/.claude/ — e.g., skill creation/editing, self-maintenance pipelines, any automation that manages Claude Code configuration.

Suggested fix

The protected-dir check in -p mode should go through the same PermissionRequest path as interactive mode, giving hooks a chance to allow the write. Alternatively, --dangerously-skip-permissions should bypass the protected-dir check entirely (as the flag name implies).

This is still an issue

@alexey-pelykh's finding is accurate and well-documented. Quick confirmation from the hooks side:
Interactive mode: PermissionRequest hooks fire correctly for .claude/ writes. The execution order is:

1. PreToolUse hooks run
2. Built-in protected-directory checks run
3. PermissionRequest hooks run (can override step 2)
4. Tool executes

-p mode: Step 3 never happens. The protected-dir check in step 2 returns an immediate error, bypassing the PermissionRequest event entirely. This means hook-based workarounds (like allow-claude-settings.sh or @wdelhagen's hook) only work in interactive sessions.
Workaround for -p mode users: Currently none that I'm aware of. The --dangerously-skip-permissions flag does not bypass the protected-dir check in -p mode either (as alexey-pelykh confirmed).
This is a core harness issue — the protected-dir check needs to go through the PermissionRequest path in all modes, not just interactive. Supporting the fix request.

and still an issue in 2.1.84 @bcherny

yeah, can confirm this bug is BACK or never truly solved. This is a huge productivity blocker for people like me that fire and forget a dozen tasks at a time only to come back and find nothing done. Seriously you guys need to learn about regression testing... these are simple things that shouldn't ever go backwards... ever... maybe teach claude that next?

Still broken on Claude Code VScode extension v 2.1.84

@bcherny — the fix from this issue didn't hold. Multiple users confirm the problem persists on v2.1.84:

• #36887: "Still broken on v2.1.84 in the VSCode extension"
• #39350: "Bypass permissions mode resets to ask permissions on every edit"
• #39057: "Permission mode resets from 'Bypass permissions' to 'Edit automatically' mid-session"

The protected directory prompt also interacts badly with the mode selector — clicking "Yes, allow all edits this session" silently downgrades the mode from Bypass to Edit Automatically, which then causes all subsequent operations to prompt.

I've mapped the full dependency tree (12+ issues, two correlated branches, trail going back to #2933 from July 2025) in a consolidated meta-issue: #39523.

Would appreciate this being reopened or the meta-issue being used as the tracking issue. This is a significant pain point for anyone running autonomous agent workflows.

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.