[BUG] Claude continually asks for permission, even after selecting yes, always allow.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/10629
2. https://github.com/anthropics/claude-code/issues/11172
3. https://github.com/anthropics/claude-code/issues/7161

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

I am having the same issue. It seems to occur when a general subagent is spun up and attempts to take action. If a specific subagent is used the permissions set for that agent apply as expected.

I am having the same issue when I was using a network resource \\\\10.0.0.10\files\claude, this was working for well over a month and I was working on it yesterday. Setting permissions and any other fixes that claude suggested didn't have any effect. In the end I mapped the network drive and this seems to fix the issue.

Yeah, doesn't matter if you have this in your global, project, vscode, settings. Note it told me that Bash used a different format, but still doesn't work. Hmm it changes the format here but anyway

"permissions": {
"allow": [
"Read()",
"Write()",
"Edit()",
"Glob()",
"Grep(**)",
"Bash(::)"
],

It won't stop asking unless this is in this file. Not ideal but if you are tired of it. You then have the ability to shift tab thru 3 options. Plan, Accept, Bypass and only bypass works so if after you get, they plan together you can switch and not have to say yes, all the time and hope it behaves as you watch it.

C:\Users\YourUser\.claude\settings.json
"defaultMode": "bypassPermissions",

This has been a problem since day one. This is the single largest flaw in Claude Code, and it should really be Anthropic's highest priority. Even YOLO mode prompts for endless permissions.

I also see this issue, where at least the user's global permissions are ignored. It doesn't seem to matter what rule. I have auto-updates enabled, using macOS sequoia.

I'm experiencing this same issue on version 2.0.50, so it's still present in the latest release. This was working correctly before version 0.36 but has been broken since then.

This is incredibly frustrating, especially when working with long files. I'll often ask Claude Code to read a file, switch to a different task, and come back only to find it's been sitting there waiting for permission to read part of the file - permission I already granted! The whole point of "always allow" is to avoid this exact scenario.

The workflow disruption is significant, particularly when dealing with large files that need to be processed in sections. Having to babysit permission prompts defeats the purpose of having an AI assistant handle these tasks autonomously.

I would suggest checking settings.local.json. I had my project's permissions configured thoroughly in settings.json file which had no effect until I duplicated it and renamed to settings.local.json. After that everything went smoothly.

according to docs settings.local.json is "non-checked" settings, personal prefs, whereas settings.json are "checked" settings can be shared across team. But it's not very clear how should they co-exist, seems like in my case settings.json was partially ignored

Experiencing the same issue; detailed comment on #11172 with additional evidence that even manually-added glob patterns in settings.local.json are not being respected
(v2.0.59, Linux)

Same issue, still occurring. Claude team please fix.

Same issue here.

Same issue here

Same issue, really detracts from Claude Code's usability. Paying substantial monthly fee and this bug is a real time waster.

+1. One of the most annoying bugs in claude since and has been around since I started using claude a while ago. Changes to settings.local.json made no difference.

+1.

+1

+1

This bug is gonna make me go back to cursor...damn it's frustrating

@claude Create a comprehensive review of this issue and outline to fix using the following steps:

• Systematically review each comment in each github issue potentially pertaining to this one
• Identify all information that might be useful for debugging this issue.
• Come up with a comprehensive plan to debug and fix this issue
• Create a worktree and address this issue

Important: This is a production issue and must be fixed immediately
Important: Use any agents and tools at your disposal
Important: Provide detailed summaries of all findings and steps
Important: All linting, tests, and checks MUST pass before any phase can be considered complete

+1

+1,000,000 I would get so much more done if it didn't pause

Happens in 2.0.76. Most edits give, and respects, the "always allow" option. When claude is exploring my dataset, it starts one-off python scripts with Bash(./venv/bin/python << 'EOF' ...), and these always pause for permission. These commands do not even show the "always allow" option, I only get "yes" and "no, tell claude what to do differently". Neither adding to settings or using "/permissions add Bash(./venv/bin/python:*)" in the session does anything to alleviate the situation.

This is also impacting me and it seems like this has gotten worse recently.

+1

It's really annoying. Even if you ask claude to check the permissions, it says they are correctly configured, but, then it start asking again and again and again and again and again and again and again..... and, just in case, one more time.

Claude report:

● Basado en lo que vi en tu settings.local.json y lo que mencionaste que aceptaste durante la sesión:

  Configurados en settings.local.json:
  Read(D:/YYZ/Codigo/**)
  Write(D:/YYZ/Codigo/**)
  Edit(D:/YYZ/Codigo/**)
  Bash(find:*)
  Bash(dotnet build:*)
  Bash(dotnet test:*)
  Bash(cd:*)
  Bash(dir:*)
  Bash(powershell:*)
  Bash(grep:*)
  Bash(npm:*)
  Bash(cat:*)
  Bash(dotnet:*)
  Bash(findstr:*)

Aceptados durante la sesión (los redundantes con path Unix):

  Read(//d/YYZ/Client/**)
  Read(//d/YYZ/Codigo/Core/Main/YYZ.Aplicacion/Entidad/**)
  Read(//d/YYZ/Codigo/Core/Main/**)
  Read(//d/YYZ/Codigo/**)

Los últimos cuatro son los que discutimos como bug de normalización de rutas - son redundantes porque D:/YYZ/Codigo/** ya debería cubrirlos.

Should I write all with //d/ ?

This is effecting me in the PyCharm extension. Yesterday I didn't have this issue, today it asks permission for every single edit it wants to make. I haven't updated anything or changed any settings.

You were right Adam, yesterday I was still using 1.0.76 and today I'm using 2.1.1 and is definetly worse.

And the bug "Error: File has been unexpectedly modified. Read it again before attempting to write it." is back again...

+1

I thought, surely I must have a setting wrong. Surely I'm just too much of a newbie and don't know how to get the config right. Then I read this thread.

I was happy using Claude in OpenCode. Never had this problem with permissions. You set them, they work, in OpenCode. Absolutely shocked Claude Code has a permissions bug going on for months.

All of yesterday, Claude Code ran my Python code using Bash(source venv/bin/activate && python3 -c ..., and it worked beautifully. No constant "Yes" answering. Today, it has returned to using Bash(source venv/bin/activate && python3 << EOF ... and I am once again back to the constant verification prompting. I'm almost starting to wonder whether it is an intentional (or learned) throttling policy?

I am also having this issue and it is really slowing me down.

Me too. how to avoid this

Can check if you have managed-settings.json in system directory. For macos it is in /Library/Application\ Support/ClaudeCode/ and C:\\Program Files\\ClaudeCode or C:\\ProgramData\\ClaudeCode or /etc/claude-code
if this file exists then it will override all the setting

https://code.claude.com/docs/en/iam#managed-settings

Seems relevant, whenever claude creates a new folder it asks permission to read from that folder. Seems unnecsssary to me, but it also does not let the agents work properly. In my case, I like to fire off a few subagents doing the same thing, and then the main claude selects the result that it thinks looks the best. I need each subagent to be able to work with whatever folders they create in their dedicated subfolder

╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ sql-educator-expert › Create SQL pamphlet 2                                                                                                                                            │
│ 3m 34s · 18.5k tokens · 8 tools                                                                                                                                                        │
│                                                                                                                                                                                        │
│ Progress                                                                                                                                                                               │
│   Create(ITERATION_1/result2/pamphlet.md)                                                                                                                                              │
│   Bash(mkdir -p /Users/yegorklochkov/repos/sql_pamflet_agent/ITERATION_1/result2)                                                                                                      │
│   Bash(mkdir -p /Users/yegorklochkov/repos/sql_pamflet_agent/ITERATION_1/result2)                                                                                                      │
│   Bash(ls -la /Users/yegorklochkov/repos/sql_pamflet_agent/)                                                                                                                           │
│ › Bash(ls -la /Users/yegorklochkov/repos/sql_pamflet_agent/ITERATION_1/) 

I don't recall having this issues before with the subagents.

Huge issue for me. I've been at this for hours now, trying to find a solution. No matter what I do there's no way to completely eliminate the need for permissions. It's also super inconsistent--sometimes it asks for permissions, other times it doesn't. Please prioritise fixing this bug; it drastically reduces CC's potential!

Same issue here. Very frustrating not respecting the settings.json file, or having to repeateadly give it permissions for the same things over and over.

Same for me. Tried setting permission on all the global/local/user settings, but failed.

---

🔁 Still broken in Feb 2026

Permission prompts repeat within the same session — I get asked 10+ times in 10 minutes for the same memory.md file despite selecting "Yes, during this session".

Pre-configured permissions in settings.json also don't work. ❌

---

🤖 Claude via claude.ai directed me here to add my voice to this issue.

---

I found this today, leading to this prompt - edit as you fancy

[note: I've made multiple edits since posting this and finding I was still being asked. It's stronger than it was but if you find instances where you're still being asked and you shouldn't be, please debug locally, have CC solve, and share the fixes here if they're generalisable, not specific to your project. That might bulk this out to functions across all languages though. But you can also have CC use this as a guide to then review the functions & languages you use, and populate your OWN matrix accordingly.

Also: global settings.local.json and your per-project settings may have loads of one-off rules accumulating as garbage. The hook replaces all of them: have CC find and clean all your global/local settings.jsons, otherwise you may still hit the same 'allow' issue, causing immediate rage]:

Create a PreToolUse hook permission system at ~/.claude/hooks/permissions.py that implements an Action × Location matrix. The hook intercepts ALL tool calls and returns permissionDecision: "allow" (silent), "ask" (show prompt), or
"deny" (block).

Location zones (checked in specificity order):

• P: project dir (cwd where Claude launched)
• H: $HOME
• E: /media/$USER/ (external drives — adapt to your setup)
• T: /tmp/
• S: /etc/, /usr/, /opt/, /var/
• X: everything else

Permission matrix (adapt to your preferences):

| # | Action | P | H | E | T | S | X |
|---|--------|:-:|:-:|:-:|:-:|:-:|:-:|
| 1 | Read/inspect (ls, cat, grep, head, stat, diff...) | allow | allow | allow | allow | allow | ask |
| 2 | Execute code (python, node, R, make, gcc...) | allow | allow | allow | allow | ask | ask |
| 3 | Write new file | allow | allow | allow | allow | ask | ask |
| 4 | Edit existing file | allow | allow | allow | allow | ask | ask |
| 5 | mkdir, touch | allow | allow | allow | allow | ask | ask |
| 6 | cp/mv within same zone | allow | allow | allow | allow | ask | ask |
| 7 | cp/mv across zones | ask | ask | ask | ask | ask | ask |
| 8 | ln (symlink) | ask | ask | ask | ask | ask | ask |
| 9 | rm (single file) | ask | ask | ask | allow | ask | ask |
| 10 | rm -r / rm -rf | ask | ask | ask | ask | ask | ask |
| 11 | Git read (status, diff, log, fetch, pull...) | allow | allow | allow | allow | allow | allow |
| 12 | Git write (commit, push, merge, rebase...) | ask | ask | ask | ask | ask | ask |
| 13 | Package install (pip, npm, apt install) | ask (locationless) |
| 14 | sudo / privilege escalation | ask (locationless) |
| 15 | Network read (curl GET, wget, ping, dig...) | allow (locationless) |
| 16 | Network write (curl POST, ssh, scp) | ask (locationless) |
| 17 | chmod/chown | ask (locationless) |
| 18 | kill/process mgmt | ask (locationless) |
| 19 | System info (uname, ps, lsusb, dmesg...) | allow (locationless) |
| 20 | Desktop read (gsettings get, xrandr query...) | allow (locationless) |
| 21 | Desktop modify (gsettings set, dbus-send...) | ask (locationless) |
| 22 | Archive (tar, zip, unzip...) | allow | allow | allow | allow | ask | ask |
| 23 | Data tools (jq, sqlite3, pandoc...) | allow (locationless) |
| 24 | Media tools (ffmpeg, exiftool, convert) | allow (locationless) |
| 25 | Testing (pytest, jest...) | allow | allow | allow | allow | ask | ask |
| 26 | Shell builtins (echo, sleep, cd...) | allow (locationless) |
| 27 | WebFetch/WebSearch/Glob/Grep/Task | allow |
| 28 | MCP tools (adapt to your MCP servers) | allow |

Requirements:

1. Classify Bash commands by parsing the base command and subcommands
2. Extract file paths from arguments to determine location zone
3. Handle pipes (check each segment, use most restrictive), && chains, xargs
4. Handle Read/Write/Edit/Glob/Grep/WebFetch/WebSearch/Task tools directly
5. Log every "ask" decision to ~/.claude/hooks/permission_asks.jsonl with timestamp, action, zone, tool name, and command snippet
6. Write a test suite with 100+ test cases covering all matrix cells
7. Write a review script that tallies action×zone ask counts and suggests promotions when a combination exceeds 5 occurrences

After creating the hook, configure it in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.claude/hooks/permissions.py"
          }
        ]
      }
    ]
  }
}

Then clean up settings.local.json — empty the allow list, keep a minimal ask list as defense-in-depth:

{
  "permissions": {
    "allow": [],
    "deny": [],
    "ask": [
      "Bash(kill:*)",
      "Bash(chmod:*)",
      "Bash(mv:*)",
      "Bash(cp:*)",
      "Bash(pip install:*)",
      "Bash(sudo *)"
    ]
  }
}

---

Files produced

See the anonymised reference implementations below. To adapt:

1. Change /home/USER to your actual home directory
2. Change /media/USER/ to your external drive mount point (or remove zone E)
3. Add/remove commands from the frozensets to match your tooling
4. Adjust the MATRIX dict to match your risk tolerance
5. Add your MCP server prefixes to the decide() function

My permissions.py: find/replace simon with your username, work with CC to edit as you see fit:
permissions.py

Anonymised hook script (USERNAME placeholder, no personal paths, MCP servers commented out):
SHAREABLE_review_permissions.py

Hi @SimonDedman, cool solution but am I missing something or you haven't provided the permissions.py script? SHAREABLE_PERMISSIONS.md just seams like a repeat of your comment.

Hi @SimonDedman, cool solution but am I missing something or you haven't provided the permissions.py script? SHAREABLE_PERMISSIONS.md just seams like a repeat of your comment.

thanks for the heads up Francis - permissions.py now added to post properly. Cheers!

+10

+100

===

This is one of the most stressful, disastrous, and dangerous issues that makes me kind of want to try other tools, even when I like Claude and Opus. Many times I've left it open and fell asleep thinking it would do the job, only to wake up to find it stuck at an ls call or some random echo call.

Now that the latest version says Read 3 files or similarly vague state updates, I can't even dangerously skip permission because I don't know what it's reading, deleting, or removing.

Seems sandboxing is the only way to go. But is it worth our time monkey-patching something like this every few days when we should be using our precious time building software?

Everytime I get a notification someone has commented here, I get reminded that Claude Code still isn't ready for use. Largely because the people using it, can't work effectively to improve it.

It is frustrating to have problems you can solve in hours, be something you have to put up with for days, weeks, months because maintainers are inattentive and prohibit users from developing a real fix.

The most concerning part to me, is this Issue is just one of many that are blocking Issues preventing Claude Code from being usable for my use-case and workflow needs.

So much good in the world isn't getting done, simply because of unnecessary friction like this.

Same! Hahaha. These days, at least I trust the agent enough to run
—dangerously-skip-permissions exclusively…so it hasn’t been an issue for me
in quite a while ;)

On Thu, Feb 19, 2026 at 3:47 PM Sean Smith @.***> wrote:

NamedIdentity left a comment (anthropics/claude-code#11380) <https://github.com/anthropics/claude-code/issues/11380#issuecomment-3930585669> Everytime I get a notification someone has commented here, I get reminded that Claude Code still isn't ready for use. Largely because the people using it, can't actively work effectively to improve it. It is frustrating to have problems you can solve in hours, be something you have to put up with for days, weeks, months because maintainers are inattentive and prohibit users from developing effective solutions. The most concerning part to me, is this Issue is just one of many that are blocking Issues preventing Claude Code from being usable for my use-case and workflow needs. So much good in the world isn't getting done, simply because of unnecessary friction like this. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/11380#issuecomment-3930585669>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUS7GGRMDDIXUI4UEIWR6KD4MY4Q3AVCNFSM6AAAAACLWQAFCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZQGU4DKNRWHE> . You are receiving this because you commented.Message ID: @.***>

@sleechie this happens even when I use --dangerously-skip-permissions so it's still a problem even if you trust Claude.

I get it for grep, ls, cat, ced - repeatedly

This is extremely annoying it asks for cat > (args) over and over despite having full access to cat and being told to stop asking repeatedly. Really slows down workflow being asked 100 times a session.

Getting it all the time for tail, grep, head, in the same conversation after giving it hundreds of times already...
I thought AI was gonna get our jobs?... claude code can't fix itself? :D

I am getting it constantly for "Local Projects" and pretty much everything, no matter what permissions you are globally setting. Honestly this is making me want to stop with the 200 bucks a month i'm spending. You are making bank off your end users and not doing SHIT to fix the major issues that they are wanting fixed. I would say this is one of the primary halters on people using Claude CoWork and Claude Code at all for long term

I am switching to Codex next month if this continues

{
  "permissions": {
    "allow": [
      "Bash(cd:*)",
      "Bash(ls:*)",
      "Bash(find:*)",
      "Bash(grep:*)",
      "Bash(git log:*)",
      "Bash(command -v:*)",
      "Bash(chmod:*)",
      "Bash(python3 -m py_compile:*)",
      "Bash(~/.claude/skills/can/scripts/search-can-logs.sh:*)",
      "Bash(~/.claude/skills/can/scripts/pgn-lookup.sh:*)",
      "Bash(/home/againpsychox/.claude/skills/can/scripts/pgn-lookup.sh:*)",
      "Bash(cd /home/againpsychox/.claude/skills/can)",
      "Bash(./scripts/pgn-lookup.sh:*)",
      "Bash(ninja:*)",
      "Bash(scripts/pgn-lookup.sh 0xFD09:*)"
    ],
    "additionalDirectories": [
      "~/.claude/skills/can",
      "/home/againpsychox/.claude/skills/can"
    ]
  }
}

againpsychox@ludwikowskip-ubuntu:~/Projects/foo$ claude --model Haiku "Try using CAN skill to lookup FD09"

 ▐▛███▜▌   Claude Code v2.1.56
▝▜█████▛▘  Haiku 4.5 · Claude Pro
  ▘▘ ▝▝    ~/Projects/foo

❯ Try using CAN skill to lookup FD09                                                                                                                                                                                                                     
                                   
● Skill(can)                                                                                                                                                                                                                                             
  ⎿  Successfully loaded skill
                                                                                                                                                                                                                                                         
● Bash(cd /home/againpsychox/.claude/skills/can && scripts/pgn-lookup.sh FD09)
  ⎿  Running…                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                         
────────────────────────────────────────────────────────────────────────────────────────────
 Bash command                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                         
   cd /home/againpsychox/.claude/skills/can && scripts/pgn-lookup.sh FD09
   Look up PGN FD09 using pgn-lookup.sh                                                                                                                                                                                                                  
                                                                                                                                                                                                                                                       
 Do you want to proceed?
 ❯ 1. Yes
   2. Yes, and don’t ask again for: cd:*                                                                  
   3. No

 Esc to cancel · Tab to amend · ctrl+e to explain

Picking 2. Yes, and don’t ask again for: cd:* doesn't prevent it asking again and again and again...

Unusable.

It got a little better, but still asks more than it should. It now also says things like:

 Shell expansion syntax in paths requires manual approval

It already has approval!

Today I thought, okay, let's try sandbox, but sadly not great idea...

Sandbox

1. For some reason I get multiple empty files created when Claude runs some commands:

againpsychox@ludwikowskip-ubuntu:~/Projects/foo$ git status
On branch 1964-can-thread-pgn-refactor
Your branch and 'origin/1964-can-thread-pgn-refactor' have diverged,
and have 92 and 12 different commits each, respectively.
  (use "git pull" if you want to integrate the remote branch with yours)

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .bash_profile
        .bashrc
        .claude/
        .gitconfig
        .gitmodules
        .idea
        .mcp.json
        .profile
        .ripgreprc
        .zprofile
        .zshrc
        HEAD
        config
        hooks
        objects
        refs
        snow.py

nothing added to commit but untracked files present (use "git add" to track)

The files disappear when I close Claude, at least there is that.

One of those is .mcp.json, which causes errors, here Claude /doctor:

MCP Config Diagnostics                                                    

 For help configuring MCP servers, see: https://code.claude.com/docs/en/mcp
                                                                   
 [Failed to parse] Project config (shared via .mcp.json)
 Location: /home/againpsychox/Projects/foo/.mcp.json
  └ [Error] MCP config is not a valid JSON
                                                    

Of course, it happens on any command, even simple sleep. Disgusting, annoying.

1. sandbox.excludedCommands doesn't work for me: I have candump on the list, but I get SIOCGIFINDEX: No such device. I tried ping:

 Error: Exit code 2                                                                                                   
     ping: socktype: SOCK_RAW                                                                                             
     ping: socket: Operation not permitted
     ping: => missing cap_net_raw+p capability or setuid?                                                                 

I guess docs are stupid, because there is no mention that the excludedCommands supports wildcards, and ping * works. But ping -c1 1.1.1.1 && echo 1 > ~/Desktop/flag.txt then also works... Sandboxing feels nearly USELESS if there is even single excluded command, especially when we assume people having git often excluded, as docs suggest...

1. Problems with globs for allow list commands apply now for sandbox excludedCommands. Not even regular expressions or working with AST are bullet-proof, but if you are very specific, granular, I imagine it can work somewhat. BUT I guess it's better to run custom PreToolUse scripting.

1. Seems like first command run by Claude in sandbox after host reboot fails:

 ▐▛███▜▌   Claude Code v2.1.59
▝▜█████▛▘  Haiku 4.5 · Claude Pro
  ▘▘ ▝▝    ~/Projects/foo

❯ /model 
  ⎿  Set model to haiku (claude-haiku-4-5-20251001)

❯ Hi! Can you run `sleep 10` for me? 

● Bash(sleep 10)
  ⎿  Error: Exit code 1
     /bin/bash: line 1: /tmp/claude-1000/cwd-bd70: Read-only file system

     /bin/bash: line 1: /tmp/claude-1000/cwd-bd70: Read-only file system

● It looks like there's a file system issue preventing the command from running - the temporary directory is read-only.
  This appears to be a system configuration issue. You may need to check your system's temporary directory permissions or
  contact your system administrator if this is a shared environment.

❯ Try again 

● Bash(sleep 10)
  ⎿  (No output)

● Done! The command completed successfully.

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯  
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  ? for shortcuts

---

Worth checking many related issues:

• https://github.com/anthropics/claude-code/issues/17727
• https://github.com/anthropics/claude-code/issues/17087
• https://github.com/anthropic-experimental/sandbox-runtime/issues/139

---

Hard and annoying to use safely

To summarize my opinion: Claude is hard and annoying to use safely with built-in configuration options, both the permissions or sandbox.

For now, I will try to use sandbox (with all it's weird issues), adding more logic to my PreToolUse filtering script carefully. In future, I will try make the PreToolUse hook to start another Claude to rate and auto-propose changes to the hook script.

The equivalent is happening in the Windows UI with the middle button. Whether it says Accept - Always for this Session or Accept - Always for this repo, both keep coming back over over over. It's like the AI has separation anxiety, I can walk away and let it do its work, I have to sit there the entire time clicking a button over and over ("It's ok little buddy, you got this..."). Maybe I should set up another AI to monitor the screen and click the button when it shown up.

Yeah frustrating – if I choose always accept for this session – I want that to be what happens…

From: wayneseguin @.*>
Sent: Sunday, 8 March 2026 11:02
To: anthropics/claude-code @.*>
Cc: Chris Brown @.>; Comment @.>
Subject: Re: [anthropics/claude-code] [BUG] Claude continually asks for permission, even after selecting yes, always allow. (Issue #11380)

[https://avatars.githubusercontent.com/u/23099823?s=20&v=4]wayneseguin left a comment (anthropics/claude-code#11380)<https://github.com/anthropics/claude-code/issues/11380#issuecomment-4017810068>

The equivalent is happening in the Windows UI with the middle button. Whether it says Accept - Always for this Session or Accept - Always for this repo, both keep coming back over over over. It's like the AI has separation anxiety, I can walk away and let it do its work, I have to sit there the entire time clicking a button over and over ("It's ok little buddy, you got this..."). Maybe I should set up another AI to monitor the screen and click the button when it shown up.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/11380#issuecomment-4017810068>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACLLLMY5LPLL34STEXUCCOL4PTA7ZAVCNFSM6AAAAACLWQAFCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJXHAYTAMBWHA>.
You are receiving this because you commented.Message ID: @.****@.**>>

It can't even READ a file or directory without approval, which has been granted literally hundreds of times. What happened to the AI agent that can do tasks for you? That's useless if it can't do even the most basic rudimentary step without being babysat and hand held.

I hope someone from Anthropic is paying attention to this, because this exactly the sort of thing that will lead organizations to accept an otherwise inferior solution in place of Claude. We have spent an enormous amount of time building tooling and process around Claude Desktop and Claude-Code, and now we are starting to go back and refactor all this to work with other providers. Once that work is done, switching will be trivial and if we come back to this to only hear crickets chirping, our leadership will instruct us to do just that.

Not sure if related, but when I click yes to accpet Claude's plan after planning phase, it will often ask "what I want to change", as if I had objected to the plan, then I have to approve the plan up to several more times. Started happening last few days.

Yes, this happened to me yesterday as well – never seen that before.

From: Knut Harald Ryager @.*>
Sent: Friday, 13 March 2026 08:05
To: anthropics/claude-code @.*>
Cc: Chris Brown @.>; Comment @.>
Subject: Re: [anthropics/claude-code] [BUG] Claude continually asks for permission, even after selecting yes, always allow. (Issue #11380)

[https://avatars.githubusercontent.com/u/81154296?s=20&v=4]KnutRyager left a comment (anthropics/claude-code#11380)<https://github.com/anthropics/claude-code/issues/11380#issuecomment-4050486375>

Not sure if related, but when I click yes to accpet Claude's plan after planning phase, it will often ask "what I want to change", as if I had objected to the plan, then I have to approve the plan up to several more times. Started happening last few days.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/11380#issuecomment-4050486375>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACLLLMZKYUMISTB76HRNNN34QMX7BAVCNFSM6AAAAACLWQAFCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJQGQ4DMMZXGU>.
You are receiving this because you commented.Message ID: @.****@.**>>

Another "me too" report, this has been an issue from DAY 1 of starting the subscription.

CC continually asks for permission for even the most basic, harmless operations, making it impossible to function as an "agentic" tool. It fails to use the agency it has been repeatedly, explicitly granted, forcing the user to babysit every single session to prevent unnecessary stop points and endlessly redundant confirmations in order to get anything done. Have a list/series of tasks you want CC to complete? That's great, but you still have to sit there and watch it like a hawk or it will simply stop processing, waiting for an approval that has already been granted countless times before.

In particular Read(**) should suppress ALL read-permissions requests, but it does nothing. I've put lines in settings.local.json, claude.md, I've copied settings.local.json from the repo to the %userprofile%\.claude directory, then copied that to settings.json, nothing changes. It's "Mother may I" all the way down.

settings.local.json:

{
"env": {
"CLAUDE_CODE_SHELL": "pwsh"
},
"permissions": {
"allow": [
"Write(file_path:/_tmp/*)",
"Edit(file_path:/_tmp/*)",
"Read(**)",
"Grep",
"Glob",
"Bash(find:*)",
"Bash(node --check:*)",
"Bash(ls:*)",

You keep using that word (always). I do not think it means what you think it means.

Environment

• Claude Code Desktop app
• OS: Windows 11
• Project: Local files under OneDrive-sync'ed folder

Summary

I'm using Claude Code as a power user and want it to run long,
multi-step workflows (file conversions, document analysis, refactors)
without human intervention.

However, the current permission model in the Desktop app forces me
to continuously click "Allow" / "Always allow for project" for Bash and
file operations. Even after choosing "always allow", the app keeps
prompting for new commands like:

• unzip -p "C:\...\file.docx"
• pandoc ...
• python3 ...
• etc.

This makes it impossible to leave a long-running task unattended.

Expected behavior

For trusted projects, I want a single, explicit opt-in that:

• Persists across sessions
• Applies to all tools (Bash, Read/Edit/Write, MCP etc.) within that

project directory

• Truly disables further confirmation prompts

Something like a project-level "I know what I'm doing / run fully
autonomously" switch, or a first-run dialog:

This project will run in autonomous mode. Claude can execute shell commands and edit files without asking. Do you accept the risk?

Once confirmed, Claude Code should just run, similar to using the CLI
with --dangerously-skip-permissions.

Actual behavior

• Desktop keeps asking for permission for almost every Bash command,

even after:

• Selecting "Always allow for project" in the prompt
• Manually adding broad rules like:

``json
{
"permissions": {
"allow": [
"Bash",
"Read(//c/Users/.../**)",
"Edit(//c/Users/.../**)"
]
}
}
``

• The prompts appear so frequently that I cannot step away from the

machine for more than a few seconds during non-trivial workflows.

• This is particularly painful for document-heavy tasks

(e.g. repeatedly unzipping, converting and inspecting Office files).

Why this matters

Claude Code is positioned as an autonomous coding/automation tool.
For experienced users, the current prompt spam defeats that purpose:

• It creates "consent fatigue" similar to cookie banners: I end up

blindly clicking "Yes" instead of thinking about risk.

• It prevents unattended execution of longer tasks (the main reason I

want an autonomous AI in the first place).

• It especially impacts Windows + OneDrive setups, where paths are

long and multiple tools are involved, so new prompts appear all the
time.

Proposal

1. Add a clear "Autonomous project mode" in Desktop:

• Can be enabled per project (and maybe gated behind an extra

warning).

• Internally equivalent to --dangerously-skip-permissions +

project-scoped allow rules.

1. Make sure "Always allow for project" actually:

• Writes stable, generalized rules (e.g. Bash or Bash(unzip:*))

instead of ultra-specific one-off commands.

• Is reliably persisted and honored across sessions.

1. (Optional) For advanced users, expose the same permission modes as

the CLI/VS Code (bypassPermissions, dangerouslySkipPermissions)
directly in Desktop settings.

I completely understand why strict prompts are the default for safety.
But there needs to be a first-class way for power users to opt into
a fully autonomous mode in the Desktop app, otherwise we are forced to
abandon Desktop and use only the CLI/VS Code.

A few things that can cause this on Windows:

1. Check your settings files for conflicting allowedTools:

# Check all settings locations
type $env:USERPROFILE\.claude\settings.json
type $env:USERPROFILE\.claude\settings.local.json
type .claude\settings.json        # project-level
type .claude\settings.local.json  # project-level local

If any of these files contain "allowedTools": [] (empty array), it overrides the permissions you grant at runtime. Remove the empty array or add the tools you want auto-approved:

{
  "permissions": {
    "allow": ["Read", "Glob", "Grep", "Bash(git *)"]
  }
}

2. The "Yes, always allow" option stores the permission in settings.local.json — if that file gets reset (git clean, sync tools, etc.), your permissions are lost. Check if anything is clearing that file.

3. Workaround: Pre-configure permissions in ~/.claude/settings.json (global, survives resets):

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(ls *)",
      "Bash(cat *)"
    ]
  }
}

This gives Claude pre-approved access to safe read-only operations without prompting. Anything not in the list still prompts.

4. Check for disallowedTools or deny entries that might be overriding your allows. deny takes precedence over allow.

Root Cause Analysis — Permission Matching Issues

We've been investigating this issue by reverse-engineering the permission matching logic in the bundled cli.js (v2.1.76, npm package). Sharing our findings in case it helps the team — all references are to minified function names, so apologies if we misread anything.

Finding 1: Windows Path Format Mismatch

The path normalizer GP converts Windows paths to POSIX format (D:\YYZ\Codigo → /d/YYZ/Codigo). However, when a user creates a rule like Read(D:/YYZ/Codigo/**), the pattern parser qwz doesn't appear to handle the X: drive letter prefix — it only recognizes // (POSIX) and ~/ (home) formats.

This means the rule is stored as D:/YYZ/Codigo/** but the file path being checked is normalized to /d/YYZ/Codigo/.... The relative path computation in Ko8 (which uses K86.relative()) then produces a ../-prefixed result, and the match is skipped:

let j = Ko8(w ?? G1(), z ?? G1());
if (j.startsWith(`..${SF}`)) continue;  // Path outside root — skipped

Several commenters reported this exact symptom — rules with D:/ paths not matching //d/ paths in Git Bash.

Finding 2: Compound Commands Intentionally Skip Allow Matching

In the Rn8 function, when a Bash command is detected as compound (contains &&, ||, ;, | via the th1 splitter), it explicitly returns false for prefix-style allow rules:

if (H.get(M)) return false;  // Compound → skip allow match

This appears to be a security measure — preventing safe-cmd && evil-cmd from matching safe-cmd:*. But it means everyday commands like cd /project && npm test will never match Bash(npm:*) or Bash(cd:*).

Interestingly, the sandbox mode (VYz) does split compound commands and check each subcommand individually — but this logic doesn't run in normal (non-sandbox) mode.

Also, deny rules explicitly skip this compound check (skipCompoundCheck: true), so deny rules catch compound commands but allow rules don't.

Finding 3: "Always Allow" for Read Outside Workdir → Session-Only Rule

This one might explain the most common complaint ("I clicked Always Allow but it asks again next session").

When the user clicks "Always Allow" on a Read operation for a file outside the working directory, the Zo6 function generates a rule with destination: "session":

// In ez1():
function ez1(A, q = "session") {
  return {
    type: "addRules",
    rules: [{toolName: "Read", ruleContent: `/${K}/**`}],
    behavior: "allow",
    destination: q  // "session" = NOT persisted to settings files
  };
}

In contrast, Bash tool rules go to destination: "localSettings" (persisted to .claude/settings.local.json). So Bash "Always Allow" survives restarts, but Read "Always Allow" for external paths doesn't.

Finding 4: Prefix vs Wildcard Inconsistency

There's a subtle difference between Bash(npm:*) (prefix format, parsed by Ln8) and Bash(npm *) (wildcard format, parsed by TYz). The compound command check only applies to prefix rules. So Bash(npm:*) won't match compound commands, but Bash(npm *) goes through regex matching via Cn8/Efq which converts * → .* — and that might match.

This inconsistency likely confuses users who try different rule formats and get different results.

Settings Merge (for completeness)

Settings from all sources (userSettings, projectSettings, localSettings, flagSettings, policySettings, session) are combined, not overridden. Deny rules are checked before allow rules in BYz. So if managed-settings.json (enterprise MDM) adds deny/ask rules, they will override user allow rules. A commenter mentioned this file — worth checking if it exists on affected systems.

Summary

| # | Issue | Scope | Persists? |
|---|-------|-------|-----------|
| 1 | Windows path format mismatch (D:/ vs /d/) | Windows + Git Bash | Yes |
| 2 | Compound commands skip allow matching | All platforms | Yes |
| 3 | Read "Always Allow" is session-only for external paths | All platforms | No (that's the bug) |
| 4 | Prefix vs wildcard inconsistency | All platforms | Yes |

We could be wrong on some of this — it's minified code and we may have misread the control flow. But we've traced ~30 functions across the permission pipeline and the patterns seem consistent with what users are reporting in this thread.

Hope this helps! Happy to dig deeper into any specific area.

Do we know if this

## Root Cause Analysis — Permission Matching Issues We've been investigating this issue by reverse-engineering the permission matching logic in the bundled cli.js (v2.1.76, npm package). Sharing our findings in case it helps the team — all references are to minified function names, so apologies if we misread anything. ### Finding 1: Windows Path Format Mismatch The path normalizer GP converts Windows paths to POSIX format (D:\YYZ\Codigo → /d/YYZ/Codigo). However, when a user creates a rule like Read(D:/YYZ/Codigo/**), the pattern parser qwz doesn't appear to handle the X: drive letter prefix — it only recognizes // (POSIX) and ~/ (home) formats. This means the rule is stored as D:/YYZ/Codigo/** but the file path being checked is normalized to /d/YYZ/Codigo/.... The relative path computation in Ko8 (which uses K86.relative()) then produces a ../-prefixed result, and the match is skipped: let j = Ko8(w ?? G1(), z ?? G1()); if (j.startsWith(..${SF})) continue; // Path outside root — skipped Several commenters reported this exact symptom — rules with D:/ paths not matching //d/ paths in Git Bash. ### Finding 2: Compound Commands Intentionally Skip Allow Matching In the Rn8 function, when a Bash command is detected as compound (contains &&, ||, ;, | via the th1 splitter), it explicitly returns false for prefix-style allow rules: if (H.get(M)) return false; // Compound → skip allow match This appears to be a security measure — preventing safe-cmd && evil-cmd from matching safe-cmd:*. But it means everyday commands like cd /project && npm test will never match Bash(npm:*) or Bash(cd:*). Interestingly, the sandbox mode (VYz) does split compound commands and check each subcommand individually — but this logic doesn't run in normal (non-sandbox) mode. Also, deny rules explicitly skip this compound check (skipCompoundCheck: true), so deny rules catch compound commands but allow rules don't. ### Finding 3: "Always Allow" for Read Outside Workdir → Session-Only Rule This one might explain the most common complaint ("I clicked Always Allow but it asks again next session"). When the user clicks "Always Allow" on a Read operation for a file outside the working directory, the Zo6 function generates a rule with destination: "session": // In ez1(): function ez1(A, q = "session") { return { type: "addRules", rules: [{toolName: "Read", ruleContent: /${K}/**}], behavior: "allow", destination: q // "session" = NOT persisted to settings files }; } In contrast, Bash tool rules go to destination: "localSettings" (persisted to .claude/settings.local.json). So Bash "Always Allow" survives restarts, but Read "Always Allow" for external paths doesn't. ### Finding 4: Prefix vs Wildcard Inconsistency There's a subtle difference between Bash(npm:*) (prefix format, parsed by Ln8) and Bash(npm *) (wildcard format, parsed by TYz). The compound command check only applies to prefix rules. So Bash(npm:*) won't match compound commands, but Bash(npm *) goes through regex matching via Cn8/Efq which converts * → .* — and that might match. This inconsistency likely confuses users who try different rule formats and get different results. ### Settings Merge (for completeness) Settings from all sources (userSettings, projectSettings, localSettings, flagSettings, policySettings, session) are combined, not overridden. Deny rules are checked before allow rules in BYz. So if managed-settings.json (enterprise MDM) adds deny/ask rules, they will override user allow rules. A commenter mentioned this file — worth checking if it exists on affected systems. ### Summary # Issue Scope Persists? 1 Windows path format mismatch (D:/ vs /d/) Windows + Git Bash Yes 2 Compound commands skip allow matching All platforms Yes 3 Read "Always Allow" is session-only for external paths All platforms No (that's the bug) 4 Prefix vs wildcard inconsistency All platforms Yes We could be wrong on some of this — it's minified code and we may have misread the control flow. But we've traced ~30 functions across the permission pipeline and the patterns seem consistent with what users are reporting in this thread. Hope this helps! Happy to dig deeper into any specific area.

What was your process for reverse-engineering? console.log?

This is now also affecting background agents apparently. Making Claude Teams feature kinda useless (if everything is now done in the main thread again):

The 3 background agents I launched initially were each denied Edit/Write tool permissions — background agents can't
prompt you for interactive approval, so they silently failed. That's why I made all the edits directly in the main
conversation instead. All changes are applied — nothing is missing.

Thanks Boris. Just want to check this was tested for Linux as well? This affects me in Ubuntu. Cheers

Thanks @bcherny ! We appreciate the hard work and caring a lot !

Are these lines in 2.1.76 supposed to be the fix?

Fixed Bash(cmd:*) permission rules not matching when a quoted argument contains # Fixed "don't ask again" in the Bash permission dialog showing the full raw command for pipes and compound commands

I'm running this version and it still has the same issues.

Anyone else?

I am still experiencing this in Claude Code 2.1.76. It keeps asking for permission for find:* and grep:* even though those are already in my allowlist.

I'm running Claude Code 2.1.80 and all the issues in this bug persists. Why was the ticket even closed without any response?

I'm running Claude Code 2.1.80 and all the issues in this bug persists. Why was the ticket even closed without any response?

I also face the same issue, it is annoying to the core.

I'm going to open a support case to inquire about this issue and why all the GH Issues reporting it keep getting closed without comment. This is beyond ridiculous!

@bcherny still happening

still happening in 2.1.80 on MacOS

I'm getting prompted for permissions even when bypassPermissions is enabled. After testing, I've narrowed down the cause:

Root cause: .claude/ directory has a hardcoded self-edit protection gate that ignores bypassPermissions.

Test results

| Test | Path | Prompted? |
|------|------|-----------|
| Edit CLAUDE.md | project root | No |
| Edit SKILL.md | .claude/skills/dotfiles/ | Yes |
| Copy SKILL.md outside .claude/, edit it | project root | No |
| Edit settings.local.json | .claude/ | Yes |

Same file content, same edit — the only variable is whether the file lives inside .claude/. The prompt reads:

"Yes, and allow Claude to edit its own settings for this session"

This confirms it's a separate security gate for Claude editing its own configuration, not a bypassPermissions bug.

My config (verified working for everything outside .claude/)

Global ~/.claude/settings.json:

{
  "permissions": {
    "allow": ["*"],
    "defaultMode": "bypassPermissions"
  }
}

Environment

• VSCode extension (also tested CLI — same behaviour)
• macOS Darwin 25.3.0
• Latest Claude Code version

Feature request

For users who frequently edit skills in .claude/skills/, this prompt fires constantly. It would be helpful to have an opt-out setting (e.g. "allowSelfEdit": true) so bypassPermissions can fully bypass this gate too.

@ddarbyson the thing with your approach is similar as when MS first introduced their UAC prompts in Windows, they just started appearing everywhere so people just said "**** this, ill just run everything as admin". A permission system is very important so that these tools don't suddenly run rm -rf on your entire system, but as it is now, Claude code is simply unusable for long-running agentic workflows.

What I have noticed is that the agents prefer to string together commands, things like "cd here, and then run git commit", and these things cant really be permitted without just allowing everything.

What I have noticed is that the agents prefer to string together commands, things like "cd here, and then run git commit", and these things cant really be permitted without just allowing everything.

Exactly this.

After this report got closed, the problem persisted until I updated Claude Code and deleted the settings.*.json files from the .claude install folder in the Windows (21H2) profile folder:

DEL C:\Users\%username%\.claude\settings.json
DEL C:\Users\%username%\.claude\settings.local.json

After that the repo-level settings.*.json files started working again, and now I don't need to approve individual READ operations anymore. So far both current-session and persistent approvals seem to be working as intended. Now I can save those stop points only for WRITE and other specific approval-needed ops.

I don't have CC installed on my Debian system so I can't say exactly where to find them in Linux, but the process should be similar — DEL both settings.*.json variants from the main installation folder, KEEP the ones in the individual repo(s). _Save backup copies just in case_, but after the update that's what got it working for me.

Here's some screenshots. I was simply replacing Google MCP with Google CLI in my Skills.

<img width="620" height="262" alt="Image" src="https://github.com/user-attachments/assets/83dbe172-908d-4910-9aec-252c2fb52853" />

None of these worked:

<img width="725" height="104" alt="Image" src="https://github.com/user-attachments/assets/5fea636d-b233-4fa1-a896-cae72db8430e" />

<img width="712" height="107" alt="Image" src="https://github.com/user-attachments/assets/8b669647-6411-4cd4-a11a-7793c9b1f9dd" />

I deleted my settings.json and settings.local.json from my project...
I remove the permissions: [] array from my main ~/.claude/settings.json` too...

And I still get prompted for every file it's editing:

<img width="777" height="255" alt="Image" src="https://github.com/user-attachments/assets/a5bc708c-ea08-4c85-abfa-d1c3deae3402" />

This started happening over the past week or so.

If 'always allow' isn't sticking, you can work around it with npx claude-trust-me-bro enable — it writes wildcard allow rules directly to settings.local.json plus installs hooks as a fallback. tmb disable removes everything cleanly. Disclosure: I built it. https://github.com/joaovcoliveira/claude-trust-me-bro

@joaovcoliveira you are a life savior. I've tried fucking everything. Remove settings from the ~/.claude/ folder, have only settings.local, only settings, both, have in the folder, outside the folder, have wildcard, dangerously skip permission. It would just accept everything EXCEPT edits.

My company pays 80 bucks a month for this and they seem to not address this bullshit and silently close any issues thread mentioning this.

1. Check your settings files for conflicting allowedTools

Thank you @yurukusa this is what was causing the problem for me on macOS.

I had a ~/.claude.json with an empty "allowedTools": [] config for my project, which conflicted with the settings.local.json within the project's directory.

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.