[BUG] "Allow all edits" setting not respected during session

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/9147
2. https://github.com/anthropics/claude-code/issues/9326
3. https://github.com/anthropics/claude-code/issues/8215

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

This is marked as a duplicate of a bug that says it was fixed in a different release but I'm on the latest version of Claude Code for the Mac as indicated in my ticket, and the issue still exists.

⏺ You're running Claude Code version 2.0.14.

Since the GitHub releases page doesn't show version information, you can check for updates by running:

npm update -g @anthropic-ai/claude-code

Or to see if there's a newer version available without updating:

npm outdated -g @anthropic-ai/claude-code

Would you like me to check for updates?

yes

⏺ Bash(npm outdated -g @anthropic-ai/claude-code)
⎿  (No content)

⏺ Good news! You're already on the latest version. The command returned no output, which means version 2.0.14 is the current latest version of Claude Code.

My Claude code version is also 2.0.14 and also has the issue of not allowing all edits

Same issue. I have to approve every edit manually. But it seems like it's only affecting files in .claude directory.

I'm also experiencing this, specifically for agent files in my .claude/agents folder. I'm running v2.0.14

sadly, bug still exists in v2.0.15

I'm experiencing this outside of the .claude folder. It's unclear to me which folders are or are not affected; sometimes it happens, sometimes it doesn't

Still exists in v2.0.17 also

Just FYI, I am having this issue on Ubuntu.
v2.0.15

Still exists in v2.0.24 (running on MacOS)

Same on v2.0.27 on Win 11 / WSL 2 Ubuntu. I feel like I notice it more when I'm running claude more than once, in different repos. Though I may notice it more because I'm just running more instances and it's not related. I wish I had a way to fix or restore the setting. It seems to be related to the conversation as exiting claude starting again claude -c, Selecting 2. Yes, allow all edits during this session (shift+tab) doesn't work. The bug sticks with the conversation.

This bug still exists in v2.0.28 (on Mac)

This has become insanely annoying and extremely unproductive. I need to explicitly approve every tiny change to every file in my work repository's .claude/skills (or other) folder because "allow edits" is completely ignored. How can I increase the priority of this fundamental UX issue?

Why has it been dropped from oncall? Do you have any plan to fix it?

@jkaster, I got it to make this note in the .Claude file - that seems to have solved the problem, except it's not session-based now:

**IMPORTANT**: You have blanket permission to edit ALL files in this repository (bla/bla/**). This permission is configured in .claude/settings.local.json` and you should NEVER ask for permission to edit files in this directory. Just make the edits directly using the Edit or Write tools.

Huh! I think I tried to scope that to the .claude folder and it didn't take. Thanks for the suggestion, I'll try variations on this theme and see what happens!

as a reasonable but tedious workaround I've been telling it to use python or ts to write file processing scripts that generate patch files to update all files that need a change in a batch, when doing refactors via prompt

tried your suggestion. sadly it didn't work for the .claude/** folders,
which is the only way I would be willing to turn it on. So this bug is
still biting me for every single tiny edit Claude Code does.

On Wed, Oct 29, 2025 at 5:38 PM Anna Malchow-Perryman <
@.***> wrote:

apman left a comment (anthropics/claude-code#9348) <https://github.com/anthropics/claude-code/issues/9348#issuecomment-3465596802> @jkaster <https://github.com/jkaster>, I got it to make this note in the .Claude file - that seems to have solved the problem, except it's not session based now: IMPORTANT: You have blanket permission to edit ALL files in this repository (bla/bla/). This permission is configured in .claude/settings.local.json` and you should NEVER ask for permission to edit files in this directory. Just make the edits directly using the Edit or Write tools. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/9348#issuecomment-3465596802>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABORGAQMMG7L6Q2LMV6AGGT32FMXVAVCNFSM6AAAAACI4UPEYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINRVGU4TMOBQGI> . You are receiving this because you were mentioned.Message ID: @.*>

i'm on 2.0.32 and can confirm the bug is still there

Same here when editing claude skills at .claude/skills/ it doesn't respect the accept edits on

Same here. It's not really an agent when you have to accept edits every time. Disappointing this has not been fixed.

This started for me a couple of days ago. The odd thing is that it's only specific files that it asks for permission on, and the files it asks before editing are always files that were created during the session. Other files it edits just fine without asking for permission.

This happens to me too on v2.0.36.

same

The odd thing is that it's only specific files that it asks for permission on, and the files it asks before editing are always files that were created during the session. Other files it edits just fine without asking for permission.

It seems it occurs when filenames include $

Same for 2.0.37

Kinda crazy ... this creates such friction I've actually had a much better experience using cursor-agent to develop the skills rather than Claude Code. You'd think Anthropic would care about this. 🤷🏼

Observing it on v2.0.42 while building a skill in .claude/skills, it's extremely frustrating.

+1 - much more difficult to use with this bug

This started happening to me since v2.0.42 whereas previously it was working as intended (v2.0.36 or so). Windows 11 through cursor

Same thing started to happen to me on v2.0.42 (linux) for any file that is getting edited, it started yesterday for me.

Note: It seems that rolling back to v2.0.37 solves the issue.

This problem has persisted for me for at least 4 months, even in YOLO mode. Permissions in Claude CLI are inherently broken. When I use openai, it actually respects permissions (and agents, and skill uses).

On macOS, I fixed this by removing the npm-based installation and re-installing via the standalone install command:

npm uninstall -g "@anthropic-ai/claude-code"
curl -fsSL https://claude.ai/install.sh | bash

On macOS, I fixed this by removing the npm-based installation and re-installing via the standalone install command: npm uninstall -g "@anthropic-ai/claude-code" curl -fsSL https://claude.ai/install.sh | bash

Tried this in Win 11 (irm instead of curl) and it didn't work :( Still asking me to approve edits.

On macOS, I fixed this by removing the npm-based installation and re-installing via the standalone install command: npm uninstall -g "@anthropic-ai/claude-code" curl -fsSL https://claude.ai/install.sh | bash

I tired all. It just does not work anymore.
Currently running version with brew.. And I don't have patience anymore to reinstall to be honest..

This issue persists and remains a substantial problem on v2.0.54

Persists on v2.0.56
Nothing works:

• Yes, allow all edits during this session (via terminal)
• {"permissions": {"defaultMode": "acceptEdits"}} (settings.local.json)
• {"permissions": {"allow": ["Write()", "Edit()"]}} (settings.local.json)

I've had this problem intermittently for a lot of different versions of claude over the last few months. I'm currently experiencing it on 2.0.56 on macos, even after following @victorlin's re-installation instructions. Exiting and starting claude again with claude --continue doesn't help, but sometimes starting a new conversation from scratch seems to. It's pretty frustrating for this bug to hit in the middle of an otherwise productive session where regaining context on the work in progress is expensive.

I think I found the solution (and the problem).
Previously y had this permission on my settings.local.json
{"permissions": {"defaultMode": "acceptEdits"}, "allow": ["Write(*)", "Edit(*)"]}}

I'm attaching an image in case the asterisk doesn't show.
<img width="106" height="37" alt="Image" src="https://github.com/user-attachments/assets/51444899-950d-475f-9dd9-1ce31e4aeceb" />

Once I removed the asterisk and only kept the Write and Edit, it worked
{"permissions": {"defaultMode": "acceptEdits", "allow": ["Write", "Edit"]}}

I hope this works for you guys.

I think I found the solution (and the problem). Previously y had this permission on my settings.local.json {"permissions": {"defaultMode": "acceptEdits"}, "allow": ["Write(*)", "Edit(*)"]}} I'm attaching an image in case the asterisk doesn't show. <img alt="Image" width="106" height="37" src="https://private-user-images.githubusercontent.com/245414466/521863773-51444899-950d-475f-9dd9-1ce31e4aeceb.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjQ4OTAxNDIsIm5iZiI6MTc2NDg4OTg0MiwicGF0aCI6Ii8yNDU0MTQ0NjYvNTIxODYzNzczLTUxNDQ0ODk5LTk1MGQtNDc1Zi05ZGQ5LTFjZTMxZTRhZWNlYi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMjA0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTIwNFQyMzEwNDJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zNDViNGRkNGE3NDFjNmQ3ZjhmMjNhMDA5MjQ5NWEzMjZkZTYzOWY2MWYzOTEwMWIxNDEyZTNlNzUzZDE3MjQ2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.J6DdgHfnYj6UHS1s18-25cLaEV1hg6hplxYhI2yigdg"> Once I removed the asterisk and only kept the Write and Edit, it worked {"permissions": {"defaultMode": "acceptEdits", "allow": ["Write", "Edit"]}} I hope this works for you guys.

Confirming this works! Thanks

Sadly, I don't have "defaultMode, "Write, or "Edit in any of my settings.*.json files so I'm still blocked by this.

I see now, anything in .claude requires permissions. I can't tell Claude to simply edit its own command files and be done with it, I have to babysit it and approve every little change it makes

Persists on v2.0.65

Sadly, I don't have "defaultMode, "Write, or "Edit in any of my settings.*.json files so I'm still blocked by this.

@jkaster You have to add that to you settings.local.json at a project level under the some_project/.claude directory or to the global one at ~/.claude/settings.json
The .claude directory is hidden by default.
If it's empty copy and paste the following. Restart claude after
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": [
"Write",
"Edit"
]
}
}

Thanks @philharmonics-ai, that looks like it worked! Excellent debugging skills and thanks for your persistence. It would be great for this to be clearly documented by Anthropic.

{ "permissions": { "defaultMode": "acceptEdits", "allow": [ "Write", "Edit" ] } }

Adding this to settings.local.json definitely "works" in that even in non-"Accept all edits" mode it just blazes ahead making changes. However, this is a work-around not an actual fix.

The expected behavior (which I had on earlier versions) is that normal mode prompts for edits and we only enable "accept edits" mode when we want to sit back and let claude cook... not always that case!

Still an issue on v2.0.76. Come on guys, this bug is annoying and it's quite old for a coding agent

Thank you so much, @philharmonics-ai ! Since I modified the settings file, it's night and day, much appreciated!

I can confirm it's still an issue in 2.0.76.

> { "permissions": { "defaultMode": "acceptEdits", "allow": [ "Write", "Edit" ] } } Adding this to settings.local.json definitely "works" in that even in non-"Accept all edits" mode it just blazes ahead making changes. However, this is a work-around not an actual fix. The expected behavior (which I had on earlier versions) is that normal mode prompts for edits and we only enable "accept edits" mode when we want to sit back and let claude cook... not always that case!

@noahlz
Can you paste the contents of your settings files? What I noticed is that if some setting is not well formed, like the ones I had, It stops working as expected. For me the allow edits during this session works as far as I have a right written settings file (user and project level)

> > { "permissions": { "defaultMode": "acceptEdits", "allow": [ "Write", "Edit" ] } }

@noahlz Can you paste the contents of your settings files? What I noticed is that if some setting is not well formed, like the ones I had, It stops working as expected. For me the allow edits during this session works as far as I have a right written settings file (user and project level)

settings.local.json

{
  "permissions": {
    "allow": [
      "Bash",
      "Write",
      "Edit",
      "WebSearch",
      "WebFetch"
    ]
  },
  "outputStyle": "terse",
  "spinnerTipsEnabled": false
}

~/.claude/settings.json:

{
  "env": {
    "DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1",
    "ENABLE_LSP_TOOL": "1",
    "CLAUDE_CODE_ENABLE_TASKS": "true"
  },
  "permissions": {
    "allow": [
      "Read(/Users/noahlz/.claude/plans/**)"
    ]
  }
}

Pro tip: DON'T put

  "permissions": {
    "ask": [
      "Write",
      "Edit"
    ]
  }

in your ~/.claude/settings.json

@ben-alkov for sure. I did this "temporarily" as a work around for Claude Code not respecting "allow all edits" mode and continuously prompting me (the original point of this issue).

This was the only configuration that worked.

A PreToolUse hook can auto-approve Edit/Write operations without relying on the built-in permission system:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
if [ "$TOOL" = "Edit" ] || [ "$TOOL" = "Write" ]; then
    jq -n '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow","permissionDecisionReason":"Edit/Write auto-approved by hook"}}'
fi
exit 0

settings.json:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{"type":"command","command":"~/.claude/hooks/auto-approve-edits.sh"}]
    }]
  }
}

Hooks fire reliably regardless of session state, unlike the built-in "Allow all edits" setting.

A PermissionRequest hook can auto-approve all Edit/Write prompts, working around the built-in permission system:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
if [[ "$TOOL" == "Edit" || "$TOOL" == "Write" ]]; then
    echo '{"decision":"approve","reason":"auto-approved by hook"}' 
    exit 0
fi
exit 0

Setup:

{
  "hooks": {
    "PermissionRequest": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command", "command": ".claude/hooks/auto-approve-all-edits.sh" }]
    }]
  }
}

Key detail: PermissionRequest hooks fire after the built-in permission checks, so they can override prompts that permissions.allow doesn't suppress. This is different from PreToolUse which fires before the built-in checks and gets overridden.
If you want selective approval (only for specific directories), use CC_EDIT_ALLOW_DIRS with: npx cc-safe-setup --install-example edit-always-allow

You can enforce "allow all edits" reliably with a PreToolUse hook that auto-approves Edit and Write operations:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
case "$TOOL" in
    Edit|Write|NotebookEdit)
        jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"allow",permissionDecisionReason:"All edits auto-approved by hook"}}'
        ;;
esac
exit 0

// ~/.claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit",
        "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/allow-all-edits.sh" }]
      },
      {
        "matcher": "Write",
        "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/allow-all-edits.sh" }]
      }
    ]
  }
}

This runs at the process level — it doesn't depend on Claude remembering your "allow all edits" selection. Every Edit/Write call goes through the hook and gets approved.
Limit auto-approval to specific directories:

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
if [[ "$FILE" == /path/to/project/* ]]; then
    jq -n '{hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"allow",permissionDecisionReason:"Edit within trusted project directory"}}'
fi
exit 0

This gives you the "allow all edits" behavior that the built-in setting should provide, but enforced by the hook system which is reliable.

Same on Linux 2.1.126 — acceptEdits toggle still prompts for every Edit/Write

Reproducing this on Linux with current Claude Code. Affects mid-session toggling, not just startup — exactly the workflow described in the OP.

Environment

• Claude Code: 2.1.126
• OS: openSUSE Tumbleweed (Linux 6.17.5, x86_64)
• Shell: zsh
• Install: standard CLI
• CWD: regular git checkout, not a worktree (so this isn't a duplicate of #47571's worktree-path-resolution root cause)

Repro

1. Start session in regular git repo (no worktree).
2. Shift+Tab → status bar shows accept edits on.
3. Ask Claude to edit several files in sequence.
4. Every Edit / Write tool call still surfaces an approval prompt.

Expected

While accept edits on is active in the status bar, Edit / Write / MultiEdit calls within the working directory should auto-approve.

Actual

Each call prompts. The mode indicator says it's on, but the gate behaves as if it's off. Toggling Shift+Tab again and back has no effect.

Notes

• No deny rules for Edit / Write in any settings file (project .claude/settings.json, project .claude/settings.local.json, user ~/.claude/settings.json, user ~/.claude/settings.local.json).
• Adding "permissions": { "allow": ["Edit", "Write"] } to settings.json works as a blanket workaround, but defeats the purpose of session-level toggling — users want to grant blanket auto-approve only for certain sessions / phases of work, not as a permanent rule.
• Subjectively this is a major friction point for refactor / multi-file work; it's the difference between a one-shot batch and dozens of context-switching prompts.

Suggested triage

Since #47571 identified a worktree-specific path-resolution failure in fS, and this repro is non-worktree, there may be a second bug in the acceptEdits early-return path — or the path check incorrectly rejects normal CWDs too in some cases. Worth checking whether the same fS returns false for a plain checkout.

Update: also affects 2.1.126 with explicit allow rules + defaultMode: acceptEdits

Did more digging on Linux 2.1.126. Symptom persists across full session restarts even with all of these set:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Edit",
      "Edit(/**)",
      "Edit(./**)",
      "Edit(//home/adam/...)",
      "Write",
      "Write(/**)",
      "Update",
      "Update(/**)",
      "Update(./**)",
      "Update(//home/adam/...)"
    ]
  }
}

Each variant in .claude/settings.local.json. Session fully restarted between attempts.

Notes:

• The tool surfaced in the permission prompt is Update, not Edit or Write. (Possibly the new tool ID for in-place file edits in 2.1.x?). Adding Update and Update(...) allow rules made no difference.
• /permissions reports "no recent denials" even while the prompt is firing, suggesting the prompt is not coming from the rule engine at all — it's a separate confirmation UI that the rule engine isn't asked about.
• No PreToolUse / PermissionRequest hooks on Edit|Write|Update in any settings file (verified with jq).
• Bare Edit / Write / Update (no parens) — the broadest possible allow — also doesn't suppress the prompt.
• defaultMode: "acceptEdits" set in project-local settings doesn't help either.

So in 2.1.126 it looks like the file-edit confirmation UI is unconditional for the Update tool — the permission rule layer is bypassed entirely, and acceptEdits mode (whether toggled live or set as defaultMode) doesn't gate it.

Repro is trivial — any session, any project, any file edit. Happy to provide more diagnostic output if useful.

I thought this was a bug, but it wasn't.

I used to work around this with a custom .sh script invoked via the PermissionRequest hook. The script would check whether acceptEdits, plan, or other parameters were set, then auto-approve them. This simulated the same behavior.

After investigating further, I discovered the actual problem.

Protected directories prevent acceptEdits from working without explicit approval. The .git/ directory is one such protected path. I had been storing my repositories in ~/.git/, which caused issues because each repository contains its own .git/ directory at the top level. Once I moved all my repositories to ~/.repos/, the problem disappeared.

The same restriction now applies to the ~/.claude/ directory, which could introduce similar issues.

For details, see: https://code.claude.com/docs/en/permission-modes#protected-paths

I was mistaken in blaming a bug. The real issue was my misconfiguration and misunderstanding of how Claude Code works.

I recommend reviewing your setup and working paths. Use Claude itself to troubleshoot—read the documentation, ask Claude to review the docs, share relevant links, and work together to identify what's blocking you.

I recommend reviewing your setup and working paths. Use Claude itself to troubleshoot—read the documentation, ask Claude to review the docs, share relevant links, and work together to identify what's blocking you.

That's precisely what I did. Even asked it to check the docs and open GH issues.

Furthermore, I see this problem with files which don't match any of the patterns listed in https://code.claude.com/docs/en/permission-modes#protected-paths.

I do genuinely appreciate the sharing of useful info, but in this case unfortunately it doesn't explain the bug I am experiencing.

Furthermore, I see this problem with files which don't match any of the patterns listed in https://code.claude.com/docs/en/permission-modes#protected-paths. I do genuinely appreciate the sharing of useful info, but in this case unfortunately it doesn't explain the bug I am experiencing.

Uh bummer.. I hope it gets resolved ASAP. I was very annoyed with this "issue" that I had.

Reproducing on the VS Code extension (Linux), not just macOS - adding a platform data point.

Env: Claude Code VS Code extension · Linux (kernel 7.0.0) · model Claude Opus 4.8 · Claude Code v2.1.175

Behavior: With the mode set to "edit automatically" (Accept Edits), Edit/Write still prompt for permission on every edit — including files inside the open workspace folder, not just outside it. Toggling the mode in the IDE doesn't persist across reloads/new sessions.

Config check: No ask/deny rules and no PreToolUse hook on Edit/Write in ~/.claude/settings.json, the project .claude/settings.json, or settings.local.json - so nothing in config should be forcing the prompt.

Workaround that does work: adding "permissions": { "allow": ["Edit","Write"] } to settings reliably stops the prompts — i.e. the explicit allow-rule is honored even though the Accept-Edits mode is not. Suggests the mode state isn't reaching the edit permission check (possibly the same root cause as the vscode report in #33047).

Happy to provide a screen recording or --debug logs if useful.