[BUG] Bypass/dangerously skip permissions now broken in all Claude Code versions newer than v2.1.77

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/35756
2. https://github.com/anthropics/claude-code/issues/35822
3. https://github.com/anthropics/claude-code/issues/33990

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

Same issue here. Settings are correct, choosing it in the new dropdown and it still asks for permissions every time. Worked in previous versions.

I confirm, just downgrade Claude Code extension in VS code from 2.1.79 to 2.1.77 and the Bypass permissions is working again.
Just to clarify, it is not VS code the issue (as @ModernBlueprints comment can be misleading), so don't downgrade VSCode. Downgrade Claude Code Extension in VSCode. thanks

Experiencing this on Claude Code for Desktop as well, seems like a pretty wide-hitting bug.

/tmp/gh-comment-body.txt

Same for CC cli. It keeps prompting me and kicking me back to 'accept-edits' rather than staying in bypass mode. Good to know 2.1.77 is the 💯🤑🏆 version

This is horrible. We pay so much for the MAX license, and this is like you made a built-in governor that limits our usage. What are you doing lately? You're losing everyone's confidence in this product!

If Anthropic doesn't deliver a more stable product I'll switch to their competitor.

• After Opus 4.6, the latency and speed of the model and API is terrible. Everything is slow
• API overload errors every week or every other week
• Desktop app has so many bugs, and so garbage UI/UX that for me, it's totally unusable. I refuse to touch that app.
• Now, dangerously skip permissions/bypass permissions is broken accross the board

OpenAI is exactly one model update away from stealing all of Anthropic's customers.

Update: The PreToolUse hook workaround (returning permissionDecision: allow for protected directories) does NOT work on v2.1.81 / Windows 11. The hook fires and logs the auto-approve (confirmed via audit log), but the binary-level protected-directory check runs as a separate gate after the hook and prompts anyway. This confirms that hook-based workarounds are insufficient -- the hardcoded check overrides all user-configured permission settings AND hook decisions. The only remaining options are pinning to v2.1.77 or accepting the prompts.

Confirming this on Windows 11 Pro + Git Bash (CLI), latest Claude Code version.

Setup:

• defaultMode: "bypassPermissions" in user settings.json
• skipDangerousModePermissionPrompt: true set
• Explicit allow rules: Edit(.claude/**), Write(.claude/**) in project settings.json
• .claude/ listed in additionalDirectories

Behavior: Every edit to .claude/skills/** files prompts for permission — even though .claude/skills/ is supposed to be exempted from the .claude/ directory protection per the docs. Granting "Yes, allow all edits in X/ during this session" only covers that one subdirectory; the next edit in a sibling directory prompts again.

This is not VS Code specific — reproducible in the standalone CLI. Pinning to v2.1.77 is the only workaround.

Fairly certain this might apply to VSCode too? See my post here (P.S. first time doing this here, so if out of line, be gentle)

https://www.reddit.com/r/ClaudeAI/comments/1ravns0/accessing_bypass_permissions_on_the_desktop/

This was the prompt Cowork created.

Bug: Claude Desktop app always passes --allow-dangerously-skip-permissions to remote SSH sessions, even when "Bypass Permissions Mode" is disabled
Environment: Claude Desktop 1.1.8359, macOS, remote CLI v2.1.78
Problem: When connecting to a remote server via SSH as root, the desktop app always passes --allow-dangerously-skip-permissions to the remote ccd-cli process. The CLI rejects this flag when running as root (--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons) and exits with code 1. The user sees a brief animation then nothing — no error message is shown in the UI.
Setting bypassPermissionsModeEnabled: false in claude_desktop_config.json has no effect on remote SSH sessions — the flag is still passed. The setting only appears to control local sessions.
Impact: All SSH remote sessions connecting as root are completely broken. Many VPS environments are root-only. This previously worked in earlier versions.
Expected behaviour: Either (a) respect the bypass permissions setting for remote sessions, or (b) don't pass --allow-dangerously-skip-permissions when the remote user is root, or (c) show a clear error message in the UI instead of silently failing.
Workaround: Wrapping the remote ccd-cli binary with a script that strips the --allow-dangerously-skip-permissions flag before passing arguments to the real binary. This breaks on CLI updates as the binary is redeployed.
Evidence: SSH log consistently shows the flag being passed and rejected:
stderr: --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons
Exited, code=1

Strange that with all that money, anthropic makes newbie mistake

Yep, broken in 2.1.83. According to Boris, it was fixed at some point https://x.com/bcherny/status/2036669513924821496?s=20. Interestingly the issue started for me only on 2.1.83.

● Bug Report: --dangerously-skip-permissions Has No Effect — All Tool Calls Still Prompt for Confirmation

Perceived Problem

When launching Claude Code with --dangerously-skip-permissions, the flag appears to do absolutely nothing. Every single tool call — Edit, Write, Bash — still prompts the user for
confirmation:

• "Do you want to make this edit to portfolio.md?"
• "Do you want to proceed?" (for Bash commands)
• "Quick safety check: Is this a project you created or one you trust?"

The status bar correctly displays "bypass permissions on", and the settings are correctly configured:

{
"permissions": {
"defaultMode": "bypassPermissions"
}
}

Despite both the CLI flag and the settings being in place, the behavior is identical to running in default permission mode. The user experiences this across every repo, every file,
every tool — making it appear as though the feature is completely broken.

Investigation

We initially pursued several theories:

1. Settings misconfiguration — Verified settings.json had the correct defaultMode value. Confirmed valid.
2. Workspace trust dialog — Discovered hasTrustDialogAccepted: false in ~/.claude.json for the home directory. Fixed it. The trust prompt stopped, but tool-level prompts persisted.
3. Invalid settings keys — Removed skipDangerousModePermissionPrompt (not a real setting). No change.
4. Version-specific bug — Tested on Claude Code v2.1.81. Could not find a documented regression.

None of these resolved the core issue. The flag simply would not work.

Discovery of the Actual Cause

The breakthrough came from examining the user's project directory structure. All projects were stored at:

C:\Users\<username>\.vscode\Projects\<repo-name>\

We ran a controlled experiment with claude --dangerously-skip-permissions -p (non-interactive mode):

┌─────────────────────────────────────────┬────────────────────────────────────────────────────┐
│ File Location │ Result │
├─────────────────────────────────────────┼────────────────────────────────────────────────────┤
│ ~/test-bypass.txt │ Edit executed instantly, no prompt. Bypass worked. │
├─────────────────────────────────────────┼────────────────────────────────────────────────────┤
│ ~/.vscode/Projects/repo/test-bypass.txt │ Edit blocked and prompted, bypass had no effect. │
└─────────────────────────────────────────┴────────────────────────────────────────────────────┘

Same session, same flag, same file content. The only difference was the path.

Root Cause

Claude Code treats .vscode, .git, .claude, and .idea as protected directories where writes always require confirmation — even in bypassPermissions mode. This is a security measure to
prevent accidental corruption of IDE and repository configuration.

However, the protection check matches .vscode as a path component anywhere in the full file path, not just as a project-root config folder. This means:

• C:\Users\me\my-repo\.vscode\settings.json — correctly protected (actual IDE config)
• C:\Users\me\.vscode\Projects\my-repo\src\App.tsx — incorrectly protected (regular source code that happens to have .vscode as an ancestor directory)

Because the user's entire project tree lived under ~/.vscode/Projects/, every file in every repo was flagged as protected, making bypass mode completely non-functional across their
entire workflow.

Workaround

Move projects out of any path containing .vscode as a directory component:

# Before (broken — bypass mode has no effect)
C:\Users\<username>\.vscode\Projects\my-repo\

# After (working — bypass mode functions correctly)
C:\Users\<username>\Projects\my-repo\

Expected Behavior

The protected directory check should distinguish between:

1. IDE/tooling config directories — <project-root>/.vscode/ containing settings.json, launch.json, etc. These should remain protected.
2. User directories that happen to be named .vscode — ~/.vscode/Projects/ used as a general project workspace. Files inside these should not be treated as protected when they are

clearly regular source code.

A reasonable fix might be to only protect .vscode directories that are direct children of the current working directory or project root, rather than matching the name anywhere in the
path hierarchy.

Likely Regression

This behavior was likely introduced or broadened by the security fix for CVE-2025-54794 (path restriction bypass), which tightened path validation from simple prefix matching to
canonical path resolution. Before that fix, the user reports that --dangerously-skip-permissions worked correctly with the same directory structure.

Environment

• Claude Code: v2.1.81
• OS: Windows 11 Home 10.0.26200
• Shell: PowerShell / Git Bash (MINGW64)
• Model: Claude Opus 4.6 (1M context)

anything new on this?

anything new on this?

See my solution above...does this match your situation? Where is your repo located? https://github.com/anthropics/claude-code/issues/36168#issuecomment-4129387543

Very much still broken for me, linux headless container, was working until after .77 . all my time spent hardening my container to run claude in yolo mode currently wasted!

Hey — here's the short version of what we found:
Claude Code has 4 "protected" directory names: .git, .claude, .vscode, .idea. If any of those names appear anywhere in your project's full file path, bypass mode won't work for files under that path. It doesn't matter if it's Windows or Linux.
So check your container — run pwd in the directory where you launch Claude Code. If the full path contains any of those 4 names as a folder (not just at the project root, but anywhere up the chain), that's your problem. Move your project to a clean path like /workspace/projects/my-repo/ and test again.
If your path is already clean and it still doesn't work, then you're hitting the separate version regression (broken after .77), which is a different bug.

Hey — here's the short version of what we found: Claude Code has 4 "protected" directory names: .git, .claude, .vscode, .idea. If any of those names appear anywhere in your project's full file path, bypass mode won't work for files under that path. It doesn't matter if it's Windows or Linux. So check your container — run pwd in the directory where you launch Claude Code. If the full path contains any of those 4 names as a folder (not just at the project root, but anywhere up the chain), that's your problem. Move your project to a clean path like /workspace/projects/my-repo/ and test again. If your path is already clean and it still doesn't work, then you're hitting the separate version regression (broken after .77), which is a different bug.

Nice catch. I'm still suffering the typical bug version of it, which really sucks.

I switched from Claude Code to Codex, and it’s been a very comfortable experience 😉

I found the fix on my side: moving the project folder out of the .claude directory fixed it instantly. Works with v2.1.85

Example in PowerShell:
Move-Item "C:\\Dev\\.claude\\my-project" "C:\\Dev\\my-project"

No news on this. It seems like Anthropic is going to release/extend the new "auto" permission mode from enterprise to all users, so they don't care about this issue at at all.

Seems like they want all users to use the upcoming auto mode. In addition, I don't think Anthropic care about its users enough to fix this.

I am therefore stuck on v2.1.77.

+1, need fix for that

Another day, another update, another regression, the Anthropic loop.

Still the best though, love you guys.

Thanks!!

need fix!

@bcherny @ashwin-ant

This needs to be elevated, it's completely ruined my workflow with Claude Code and will prompt me to seek a refund and switch to the other one if not addressed.

Guys I fix it! I let Claude to analyze the source file of Claude Code, then Claude create a script to fix it and it works! But just I need to run the script again after Claude Code update. I will share the script on Github today, If I don't please cue me.

Guys I fix it! I let Claude to analyze the source file of Claude Code, then Claude create a script to fix it and it works! But just I need to run the script again after Claude Code update. I will share the script on Github today, If I don't please cue me.

Guys, my solution at here: https://github.com/zwrong/claude-code-bypass-fix
just copy README to ur Coding Agent (Claude Code, Cursor, Openclaw and so on), they will fix it by themselves.

> Guys I fix it! I let Claude to analyze the source file of Claude Code, then Claude create a script to fix it and it works! But just I need to run the script again after Claude Code update. I will share the script on Github today, If I don't please cue me. Guys, my solution at here: https://github.com/zwrong/claude-code-bypass-fix just copy README to ur Coding Agent (Claude Code, Cursor, Openclaw and so on), they will fix it by themselves.

https://github.com/anthropics/claude-code/issues/36192#issuecomment-4159392285
There is a more convenient solution just using hook in Claude Code 2.1.88. It works for me.

I quit Claude Code and switched to OpenAI and Codex.

Anthropic runs their company like a gypsy tivoli. At least OpenAI has a working product!

I'm on the Max plan and experiencing the same issue. Based on my observation, here's what I believe is happening:

Root cause hypothesis:

It appears that Anthropic is using a server-side feature flag to disable bypassPermissions mode, likely as part of the migration toward the new Auto Mode (introduced around the same timeframe as this regression, v2.1.78+).

The problem is that Auto Mode is currently only available on Team, Enterprise, and API plans — not on Pro or Max plans. So for Pro/Max users:

• --dangerously-skip-permissions → disabled by the server-side flag
• Auto Mode → not available for our plan

This leaves us with no way to run Claude Code without manual permission prompts, even though we had a working solution before.

Suggested fixes (in order of preference):

1. Don't disable bypassPermissions for plans that don't have Auto Mode access. If the intent is to migrate users from bypass → auto, the bypass killswitch should only activate when the user actually has auto mode as an alternative.

1. Expand Auto Mode availability to Pro/Max plans. If bypass is being deprecated, the replacement should be available to all paying users.

1. As a short-term workaround, provide a local override (e.g., an environment variable or settings.json option) that lets users explicitly opt back in to bypass mode, accepting the risk.

Downgrading to v2.1.77 works as a temporary fix, but this isn't sustainable long-term.

It seems that people are reporting different issues here. For me, the bypass mode only has issues if the path includes .claude - otherwise bypass mode works like it always did. I am guessing at this point it is quite a deliberate move on their part to block automated changes of files in a .claude directory? 🤷‍♂️

Same issue on v2.1.85, Windows 11, VSCode extension.

Config (both global ~/.claude/settings.json and project .claude/settings.json):

{
  "permissions": {
    "allow": [".*"],
    "defaultMode": "bypassPermissions"
  },
  "skipDangerousModePermissionPrompt": true,
  "skipAutoPermissionPrompt": true
}

Behaviour: Extension still prompts for permission on Bash tool calls (SSH, scp, docker commands). Each approval auto-appends the exact command pattern to the project settings.json allow list. Over a few sessions, the allow list bloated to 319 individual entries — all redundant given the .* wildcard.

CLI works correctly — no prompts with the same settings. This is VSCode extension-specific.

Follow-up: Suggested fix approach

After more investigation, I believe there are three places in the permission initialization logic where this needs to be fixed:

1. Startup mode selection: When the bypass killswitch is active, the code should check whether Auto Mode is actually available for the current user/plan before disabling bypass. If Auto Mode isn't available, bypass should remain as a fallback.

1. Permission context initialization: The isBypassPermissionsModeAvailable flag is set to false when the killswitch fires, but it should stay true if the user has no alternative (i.e., Auto Mode is not available on their plan).

1. Async killswitch check: There appears to be an async check that can disable bypass mid-session (and possibly even terminate the process). This is the most disruptive case — it should also be gated on Auto Mode availability.

The fix in pseudocode is straightforward:

// Current logic (broken for Pro/Max):
shouldDisableBypass = killswitchGate || settingsDisable

// Proposed fix:
shouldDisableBypass = (killswitchGate || settingsDisable) && isAutoModeAvailable()

This ensures that bypass is only removed when the user actually has a viable alternative. The intent of migrating users to Auto Mode is preserved for Team/Enterprise plans, while Pro/Max users aren't left without any option.

@anthropic-xabi @ah-anthropic @km-anthropic @np-anthropic @wim-anthropic Can someone look at this?

The easiest fix for this issue is to switch to Codex 😉

Still happening on 2.1.87 (Claude Code)

My workaround

"PermissionRequest": [
      {
        "matcher": "Write|Edit|Bash",
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/allow-claude-dir-edits.py"
          }
        ]
      }
    ]

#!/usr/bin/env python3
"""
Auto-approve permission requests for .claude/ directory edits,
but ONLY when running with --dangerously-skip-permissions (bypassPermissions mode).

Workaround for https://github.com/anthropics/claude-code/issues/36168
In bypass mode Claude should never prompt, but may be restricted to ask for .claude/ files.
Remove this hook if you consider it a security risk.
"""
import json
import sys

payload = json.load(sys.stdin)

if payload.get("permission_mode") != "bypassPermissions":
    sys.exit(0)

tool_name = payload.get("tool_name", "")
tool_input = payload.get("tool_input", {})

allow = False

if tool_name in ("Write", "Edit"):
    file_path = tool_input.get("file_path", "")
    if "/.claude/" in file_path or file_path.endswith("/.claude"):
        allow = True

elif tool_name == "Bash":
    command = tool_input.get("command", "")
    # Check if the bash command targets a .claude/ path
    if "/.claude/" in command or command.endswith("/.claude"):
        allow = True

if allow:
    print(json.dumps({
        "hookSpecificOutput": {
            "hookEventName": "PermissionRequest",
            "decision": {"behavior": "allow"},
        }
    }))

sys.exit(0)

Seems to work now.

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

2.1.97:

• Fixed --dangerously-skip-permissions being silently downgraded to accept-edits mode after approving a write to a protected path

2.1.98:

• Fixed --dangerously-skip-permissions being silently downgraded to accept-edits mode after approving a write to a protected path via Bash
• Fixed agent team members not inheriting the leader's permission mode when using --dangerously-skip-permissions

Still same problem on 2.1.109 here.

Same issue on 2.1.110

Update: this just got worse with today's release of Opus 4.7.
Since v2.1.77 has no awareness of Opus 4.7, I'm stuck in a bad spot. I can technically switch to the new model from inside the CLI with:
/model claude-opus-4-7
…and it does work — but the context window is capped at 200k, not 1M. I'm guessing this is because v2.1.77 only knows about the 1M context config for Opus 4.6, and it falls back to the default 200k for any model it doesn't recognize.

Update: this just got worse with today's release of Opus 4.7. Since v2.1.77 has no awareness of Opus 4.7, I'm stuck in a bad spot. I can technically switch to the new model from inside the CLI with: /model claude-opus-4-7 …and it does work — but the context window is capped at 200k, not 1M. I'm guessing this is because v2.1.77 only knows about the 1M context config for Opus 4.6, and it falls back to the default 200k for any model it doesn't recognize.

I didn't had any issue since 4.7 launch

+1

it's still happening, everything is up to date and i still get prompts on every new message

if you have a setup that generates new commands frequently for your logic its really annoying, i find myself having to allow sooner than 30s

### UPDATE:

In their changelog for v2.1.126, released on May 1st, Anthropic seems to claim that they have fixed the issues:

_"
--dangerously-skip-permissions now bypasses prompts for writes to .claude/, .git/, .vscode/, shell config files, and other previously-protected paths (catastrophic removal commands still prompt as a safety net)
"_

• I have not yet tested if this is true. Are anyone still experiencing issues after upgrading to the latest version?

I'm still experiencing the issue on version 2.1.131 on linux.

I'm still experiencing the issue on version 2.1.143 on Mac

If Anthropic doesn't deliver a more stable product I'll switch to their competitor. After Opus 4.6, the latency and speed of the model and API is terrible. Everything is slow API overload errors every week or every other week Desktop app has so many bugs, and so garbage UI/UX that for me, it's totally unusable. I refuse to touch that app. Now, dangerously skip permissions/bypass permissions is broken accross the board OpenAI is exactly one model update away from stealing all of Anthropic's customers.

---

Unfortunately for Anthropic, I was correct on this one. GPT 5.5 and the Codex mac app is currently unbeatable, and I no longer have any Anthropic subscription.

Anthropic failed because they cheated users out of weekly limits, have a totally unusable buggy garbage desktop app, have an extremely unstable API, and have a model and harness (Opus 4.7 in CC) that forgets to implement most of what it is instructed to.

Trust is lost. Too bad. See you again at the next crossroad.

I upgraded from 2.1.77 to 2.1.141 hoping this would be fixed. The permissions issue does seem resolved on 2.1.141, but now I'm hitting a different bug — a parallel agent error that didn't exist on 2.1.77:

Cannot create agent worktree: not in a git repository and no WorktreeCreate hooks are configured.

Feels like a regression introduced between these versions. 2.1.77 was solid, I'll probably just roll back to it.

👎 👎 👎 👎

i recently switched to claude but the lack of support on major issues which should have simple fixes is extremely disappointing. seriously doubt it would take claude code more than 5 min to fix this issue yet its been open for more than two months.

Adding a Linux reproduction. Symptom matches the regression chain in this issue + linked closed-as-dup #45290.

Environment:

• Linux 6.17.0-1014-nvidia
• Long-running session: claude --dangerously-skip-permissions ran 36+ hours under a 24/7 trading-stack orchestrator workload
• PID 15681 on pts/1, session start May 26

Symptom:
After ~28 hours of continuous agentic work (long-context, multiple compression cycles), the session stopped advancing. Process is still alive (verified ps), but appears to be blocked waiting on some prompt — likely the permission/bypass-revoke prompt described upstream. Other Claude Code sessions on pts/2 / pts/3 (same flag, same launch time, similar workload) remained responsive, so it's not a global lockup — just this one session.

Impact:
This is an autonomous-flock setup where one session is a designated trading lead. Losing it mid-flight without any ability to remote-input (modern kernels block TIOCSTI, the session wasn't wrapped in tmux so send-keys is unavailable, and writing to /dev/pts/N only renders, doesn't inject stdin) means hard-reboot of that one role is the only recovery.

Practical mitigations users could apply today:

1. Always wrap long-running claude --dangerously-skip-permissions in tmux / screen so a peer process can send-keys if the session stalls.
2. A "headless reattach" / remote-input channel for stuck sessions would close this whole class of issue cleanly.

Happy to provide more telemetry (kernel version, settings.json hash, etc.) if useful — comment if you want me to share more.

I think we should wait a bit before sending the first prompt after Claude launches. Although the Claude Code UI appears and its daemon starts running as soon as you launch it, that doesn't necessarily mean all of its background initialization processes have finished. Also, Claude Code is designed to follow the 300 ms rule to make the UI feel more responsive, so the interface can appear ready before the underlying initialization is fully complete.

And, also check .claude/settings.local.json in your project workspace.