claude-code - 💡(How to fix) Fix Edit/Write guardrail blocks files with .claude/ anywhere in path, not just project-root .claude/ [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49573Fetched 2026-04-17 08:37:18
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Root Cause

  1. Claude Code denies the operation:
    Permission to use Edit has been denied because Claude Code is running in don't ask mode.

Fix Action

Fix / Workaround

The workaround is --dangerously-skip-permissions, which is overly broad — it disables ALL permission checks, not just the .claude/ path guard.

Code Example

project-root/
   ├── .claude/           ← actual Claude Code config (correct to guard)
   └── framework/
       └── .claude/       ← application code, NOT Claude Code config
           └── skills/
               └── scripts/
                   └── graphiti_service.py   ← blocked by guardrail

---

Permission to use Edit has been denied because Claude Code is running in don't ask mode.
RAW_BUFFERClick to expand / collapse

Bug

Claude Code's Edit and Write tools are denied on files that contain .claude/ anywhere in their path — not just files under the project-root .claude/ directory. This means application code in subdirectories that happen to be named .claude/ is incorrectly treated as Claude Code configuration and blocked from modification.

Reproduction

  1. Have a project with a directory structure like:

    project-root/
    ├── .claude/           ← actual Claude Code config (correct to guard)
    └── framework/
        └── .claude/       ← application code, NOT Claude Code config
            └── skills/
                └── scripts/
                    └── graphiti_service.py   ← blocked by guardrail
  2. Run Claude Code with --permission-mode dontAsk --allowedTools Edit --allowedTools Write

  3. Attempt to Edit or Write framework/.claude/skills/scripts/graphiti_service.py

  4. Claude Code denies the operation:

    Permission to use Edit has been denied because Claude Code is running in don't ask mode.

Expected behavior

The .claude/ guardrail should only protect:

  • <project-root>/.claude/ — the Claude Code configuration directory for this project
  • ~/.claude/ — the global Claude Code configuration directory

Subdirectories named .claude/ deeper in the tree (e.g. framework/.claude/, packages/foo/.claude/) are application code and should be editable normally when Edit is in the allowed tools list.

Actual behavior

Any file with .claude/ in its path is denied, regardless of depth. The guard appears to pattern-match on the path segment rather than checking whether the .claude/ directory is actually at the project root.

Impact

This affects any project where .claude/ is used as a directory name for non-Claude-Code purposes deeper in the tree. In our case, framework/.claude/skills/ contains Python scripts that are part of the application's plugin system — they happen to use the same directory name as Claude Code's config directory, but they are application runtime code.

The workaround is --dangerously-skip-permissions, which is overly broad — it disables ALL permission checks, not just the .claude/ path guard.

Environment

  • Claude Code version: 2.1.109
  • macOS (Darwin 25.3.0)
  • Invocation: claude --output-format stream-json --verbose --permission-mode dontAsk --allowedTools Edit --allowedTools Write ...

Suggested fix

Check whether the .claude/ path segment is at the project root (first component of the relative path from the working directory), not anywhere in the path. Alternatively, only guard paths that resolve to the actual ~/.claude/ or <git-root>/.claude/ directories.

extent analysis

TL;DR

The issue can be resolved by modifying the permission check to only guard .claude/ directories at the project root or the user's home directory.

Guidance

  • Verify that the .claude/ directory is not at the project root by checking the relative path from the working directory.
  • Modify the permission check to use an absolute path comparison instead of a substring match.
  • Consider adding a whitelist for specific directories or files that should be exempt from the permission check.
  • Test the modified permission check with different directory structures to ensure it works as expected.

Example

import os

def is_claude_config_dir(path):
    # Check if the .claude/ directory is at the project root
    project_root = os.path.abspath('.')
    claude_dir = os.path.join(project_root, '.claude')
    return os.path.abspath(path) == claude_dir or os.path.abspath(path) == os.path.join(os.path.expanduser('~'), '.claude')

Notes

The suggested fix requires modifying the Claude Code source code, which may not be feasible for all users. Additionally, the fix may need to be adapted to work with different operating systems and file systems.

Recommendation

Apply a workaround by modifying the permission check to only guard .claude/ directories at the project root or the user's home directory, as this is a more targeted solution than using the --dangerously-skip-permissions flag.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The .claude/ guardrail should only protect:

  • <project-root>/.claude/ — the Claude Code configuration directory for this project
  • ~/.claude/ — the global Claude Code configuration directory

Subdirectories named .claude/ deeper in the tree (e.g. framework/.claude/, packages/foo/.claude/) are application code and should be editable normally when Edit is in the allowed tools list.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Edit/Write guardrail blocks files with .claude/ anywhere in path, not just project-root .claude/ [1 participants]