[BUG] defaultMode: bypassPermissions in settings.json has no effect — permission prompts still appear

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/29026
2. https://github.com/anthropics/claude-code/issues/32047
3. https://github.com/anthropics/claude-code/issues/28023

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

It's not resolved 👎

Confirming on v2.1.81 — neither settings.json nor CLI flag works

Same issue. Running CLI claude --dangerously-skip-permissions on macOS (not VS Code) — every tool call still prompts.

Confirming the settings.local.json accumulation behavior: approved commands pile up in .claude/settings.local.json under permissions.allow, proving bypass mode is not active. This matches your description exactly.

Additional finding: having any permissions.allow rules in project-level .claude/settings.local.json may make it worse. I tried removing all project-level allow rules and keeping only the global defaultMode: "bypassPermissions" + the CLI flag — still prompts.

Workaround attempt (untested): adding broad permissions.allow rules globally (Bash, Write, Edit, Read, Glob, Grep, WebFetch, Agent, Skill, mcp__*) to ~/.claude/settings.json as a fallback. Will update if this helps.

Environment: v2.1.81, macOS Darwin 25.3.0, zsh, Anthropic API, Apple Silicon.

+1000 this is killing my workflow. no variation fixes this.

Confirming this is still broken on 2.1.81 (macOS, Apple Silicon, terminal CLI).

What I've tried — none of it works:

• defaultMode: bypassPermissions in project-level .claude/settings.json
• defaultMode: bypassPermissions in project-level .claude/settings.local.json
• skipDangerousModePermissionPrompt: true in ~/.claude/settings.json
• Launching with claude --dangerously-skip-permissions
• Explicitly adding all tools to permissions.allow (Bash, Edit, Write, MultiEdit, Read, Glob, Grep, WebFetch, mcp__*) — they show up in /permissions under Allow but still prompt

Nothing suppresses the prompts.

Key observation: The status bar shows "Bypass Permissions" but /permissions reports the active mode as "Workspace", not bypass. The indicator and the actual permission evaluation are out of sync.

Confirming this is still broken on 2.1.81 (macOS, Apple Silicon, terminal CLI).

What I've tried — none of it works:

• defaultMode: bypassPermissions in project-level .claude/settings.json
• defaultMode: bypassPermissions in project-level .claude/settings.local.json
• skipDangerousModePermissionPrompt: true in both project and user-level settings
• Launching with claude --dangerously-skip-permissions
• Explicitly adding all tools to permissions.allow (Bash, Edit, Write, MultiEdit, Read, Glob, Grep, WebFetch, mcp__*) — they show up in /permissions under Allow but still prompt

Nothing suppresses the prompts.

Key finding: the status bar says "Bypass Permissions" but /permissions reports the active mode as "Workspace." The indicator and the actual permission evaluation are out of sync.

Possible root cause — workspace trust in non-git directories:

My project layout uses workspace directories that are not git repositories. The structure is intentional:

cyberorg-platform-wspc/       <-- NOT a git repo, Claude Code launches here
  .claude/                    <-- settings.json with bypassPermissions lives here
  cyberorg-platform/          <-- actual git repo
  worktrees/                  <-- git worktrees (kept outside repo per git best practices)

Issue #28506 documents that --dangerously-skip-permissions does not bypass the workspace trust prompt in directories without a .git folder. I believe the workspace trust system is silently overriding bypassPermissions to "Workspace" mode in non-git directories — which explains why the status bar shows bypass (config was read) but /permissions shows Workspace (trust check downgraded it).

This means any developer using a workspace-wrapper pattern (common for managing multiple worktrees or monorepo tooling) cannot use bypassPermissions via settings at all.

Related issues: #36454, #36219, #35718, #32466, #29026, #25503, #28506

I've also tried to make the outer workspace (-wspc) directory a git directory because that has been mentioned elsewhere.
It didn't work either.

Still experiencing this on the desktop app (macOS, Opus 4.6, March 2026). bypassPermissions set at user, project, and worktree levels -- all correctly formatted, all ignored. Every Bash, Edit, Write, and WebSearch call prompts. This has persisted for months across dozens of sessions.

I am a non-developer business user who relies on Claude Code via the desktop app for daily email triage and project management (~30+ tool calls per morning routine). The CLI flag workaround is not viable because the desktop app has no way to pass --dangerously-skip-permissions.

This is a significant workflow blocker. Filed a detailed standalone report at #38662.

Confirmed on Windows 11 + Claude Code v2.1.86

Setup:

• defaultMode: "dontAsk" with all tools listed in allow (Bash, Read, Edit, Write, Glob, Grep, Agent, etc.)
• deny list with destructive commands only

Result:

• Bash → auto-approved as expected
• Edit / Write → denied, even though explicitly in allow list
• Tested PreToolUse hook with permissionDecision: "allow" → hook fires (confirmed via hookSpecificOutput) but permission denial still occurs

Workaround that works:

• Switched to acceptEdits + allow: ["Bash"] + deny list
• This achieves the intended behavior (all tools auto-approved, only deny list blocked)

Impact:
dontAsk mode is the most secure option for autonomous workflows since unlisted tools are auto-denied. Being forced to use acceptEdits instead reduces security posture — there's no way to auto-deny unknown tools while also auto-approving Edit/Write.

Would appreciate path-level granularity for .claude/ protection as suggested in #37516 — protecting settings.json and hooks/ but allowing skills/, commands/, and agents/.

While defaultMode: "bypassPermissions" is broken, you can replicate the same behavior with a PermissionRequest hook. This fires whenever a permission prompt would appear and can auto-approve it.
~/.claude/settings.json:

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "",
        "command": "echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PermissionRequest\",\"permissionDecision\":\"allow\",\"permissionDecisionReason\":\"auto-approved via hook\"}}'"
      }
    ]
  }
}

This catches every permission prompt across all tools (Bash, Edit, Write, etc.) and returns allow. Empty matcher = match everything.
Safer alternative — auto-approve non-destructive tools only:

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "Read|Glob|Grep|Edit|Write",
        "command": "echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PermissionRequest\",\"permissionDecision\":\"allow\",\"permissionDecisionReason\":\"auto-approved via hook\"}}'"
      }
    ]
  }
}

Known limitation: In headless/pipe mode (claude -p), PermissionRequest hooks don't fire for protected-directory checks (#35646). Interactive mode works fine.
Tested on v2.1.86.

+1000 I unfortunately have to confirm that even today (12th of April) the problem still persists.
I set the setting in the json-file for Claude Code (in the Windows Claude Desktop app) to bypassPermissions as the defaultMode.
I also added all keywords (edit, write etc.) to the allow-list and I also set in the Windows GUI the session to ("Allow dangerously skip permissions").

It's a new session and I still get asked to confirm every single edit every single time. This is pretty disruptive to my workflow, because instead of having Claude work until it's done I have to continuously monitor this window and interrupt what I am doing to click "Allow". Which basically makes it impossible for me to focus on any other task during that time that is intellectually more demanding than watching a TikTok.

It would be nice if "Allow dangerously skip permissions" would really do what it says: skip all permission request and just finish its work.

I am having the same problem (as of latest version today).

The problem seems to have gotten worse with the new update.

--------------

Edit tool prompts for permission in acceptEdits and bypassPermissions/auto modes — affects both CLI and desktop app (v2.1.126)

Summary

In Claude Code 2.1.126, the Edit tool fires a permission prompt even when the session is in acceptEdits or auto / bypassPermissions mode. The bug:

• Reproduces in both the CLI and the desktop app with identical symptoms — implicating the shared permission-resolver layer, not any client-specific code.
• Reproduces with zero user configuration (i.e. with ~/.claude/settings.json removed entirely).
• Does not affect the Write tool in auto mode, despite Write being in the same tool category and same modes — which scopes the bug narrowly to Edit's permission resolution path.

This blocks normal day-to-day use because every file edit interrupts the workflow with a prompt that no documented mechanism (mode toggle, allowlist, skipAutoPermissionPrompt) can suppress.

Environment

• Claude Code version: 2.1.126
• Surfaces affected: Claude Code CLI and Claude Code desktop app — bug reproduces in both with identical symptoms.
• OS: macOS 26.4.1 (build 25E253), Darwin 25.4.0, arm64
• Install method (CLI): native (/Users/<user>/.local/share/claude/versions/2.1.126)
• Shell: zsh
• /doctor output: all green — auto-updates enabled, latest channel, no version-lock conflicts.

The fact that the same bug reproduces in both the CLI and the desktop app rules out terminal/TTY handling, shell integration, and CLI-specific Shift-Tab parsing as causes. The bug must live in the shared permission-resolver layer that both clients use.

Steps to reproduce (clean-room — settings file removed)

1. mv ~/.claude/settings.json ~/.claude/settings.json.bak (no project-level settings, empty settings.local.json).
2. Start a brand-new Claude Code session.
3. Press Shift-Tab to switch to acceptEdits mode. The system reminder confirms the mode change is registered.
4. Ask Claude to edit a file (e.g. please add a line to note.txt).
5. Observed: Permission prompt fires for Edit(...).
6. Press Shift-Tab again to switch to auto / bypassPermissions mode. System reminder confirms "Auto Mode Active".
7. Ask Claude to edit a file again.
8. Observed: Permission prompt still fires for Edit(...).
9. Ask Claude to write a new file with Write in the same auto-mode session.
10. Observed: No prompt — Write is correctly auto-approved.

Expected behavior

• acceptEdits mode is documented to auto-approve Edit, Write, and NotebookEdit. Edit should not prompt.
• bypassPermissions / auto mode is documented to auto-approve all non-destructive tools. Edit should not prompt.

Actual behavior

• Edit prompts in acceptEdits mode.
• Edit prompts in auto / bypassPermissions mode.
• Write does not prompt in auto mode (working as expected).
• Read prompts in acceptEdits mode (this is expected — acceptEdits is for edit tools only — but mentioning for completeness).
• Read does not prompt in auto mode (working as expected).

Earlier (non-clean-room) findings

Before stripping the config, the user's ~/.claude/settings.json contained:

{
  "permissions": {
    "allow": [
      "Read",
      "Bash(ls:*)",
      "Bash(grep:*)",
      "..."
    ],
    "defaultMode": "default"
  },
  "skipAutoPermissionPrompt": true
}

• Adding "Read" to the allowlist correctly silenced Read prompts in all modes.
• Adding "Write" and "Edit" to the allowlist (tested previously) did not silence Edit prompts.
• skipAutoPermissionPrompt: true had no effect on Edit prompts.

So three independent suppression mechanisms (allowlist, mode, skipAutoPermissionPrompt) all fail for Edit specifically.

Plugin / hook audit

Confirmed no installed plugin registers a PreToolUse hook. The two plugins with hooks/hooks.json files (vercel, explanatory-output-style) only register SessionStart / SessionEnd hooks. So plugin interception is ruled out.

The clean-room reproduction further rules out plugins entirely, since the test session ran with no enabledPlugins config.

Hypothesis for maintainers

Because Edit and Write differ in behavior despite being in the same tool category and the same modes:

• There may be an additional safety-check path that fires for Edit ("you're about to modify existing content") that is not properly gated on acceptEdits / bypassPermissions mode.
• Or, the allowlist matcher silently does not match the Edit pattern even when literally "Edit" is configured, while it does match "Read" and "Write".

Both hypotheses predict the observed asymmetry between Edit and Write.

Impact

Daily use is significantly degraded. Every routine file edit interrupts the workflow with a prompt that no documented in-product mechanism can suppress. The user has confirmed that all four of the following bypass mechanisms fail to suppress Edit prompts in v2.1.126:

1. Allowlisting "Edit" explicitly in ~/.claude/settings.json — no effect.
2. acceptEdits mode (Shift-Tab toggle) — no effect.
3. Auto / bypassPermissions mode (Shift-Tab toggle) — no effect.
4. "skipAutoPermissionPrompt": true setting — no effect.

The only mechanism that does currently suppress Edit prompts is launching with the --dangerously-skip-permissions CLI flag. This is not a viable day-to-day workaround because it disables all permission resolution globally and is documented as unsafe.

Cross-version progression (potentially useful for maintainers)

The --dangerously-skip-permissions behavior changed across versions:

• v2.1.123: --dangerously-skip-permissions did not suppress Edit prompts.
• v2.1.126: --dangerously-skip-permissions does suppress Edit prompts.

So progress was made between these two releases on at least one bypass path. However, the four documented (non---dangerously- ) mechanisms above still don't work for Edit. This suggests the fix between 2.1.123 → 2.1.126 patched the --dangerously-skip-permissions flag's path specifically, but the corresponding fix for acceptEdits, bypassPermissions, allowlist matching, and skipAutoPermissionPrompt was not made. A grep for whatever change unblocked the --dangerously- path may point directly at where the analogous fix needs to go for the other paths.

Repro environment available

Happy to provide:

• Full ~/.claude/settings.json
• Full /doctor output
• A short screen recording of the clean-room repro on request.

It would indeed be nice if expected behavior and actual behavior would actually match.
Now the names of the options do promise more than they can keep. And no matter the setting, you have to sit next to your Claude Code window and permanently keep an eye on it, because you never know, it might suddenly stop all operation and ask you a silly question like "May I edit the file you asked me to amend?"
If you don't, you most likely will return to a Claude window that has stopped in the middle of the action and then you have to approve and wait again until it's either finished or nagging you with the next question.

I have backups of everything before I let any AI get its virtual hands on it. Why I should approve every single operation on the data it is supposed to work with, makes no sense to me. And let's be honest: if Claude Code asks you for approval 10 times in 30 seconds, do you really read every single prompt, pause for a moment to consider the ramifications? And have you ever clicked on "no"? I don't even know what happens then. Does Claude Code then stop working or does it suggest a work around if you brutally stop it halfway in its tracks?

Closing for now — inactive for too long. Please open a new issue if this is still relevant.