[BUG] Desktop: Bypass Permissions mode can't be enabled on macOS — reverts to Accept Edits, "Permission mode couldn't be changed" (2.1.148)

same issue here and I am windows 11

Can confirm the same on mac os, Claude 1.8555.1 (cfe7d4) 2026-05-22T17:41:12.000Z

Confirmed. Fresh install, fresh macos 26.4 (25E246), Claude 1.8555.2 (a476c3) 2026-05-22T23:04:37.000Z

This issue requires immediate attention and resolution. Confirmed issue on Windows

I have the same problem on my Mac.

Confirming this on macOS with the same version same symptoms exactly.

"Bypass Permissions mode isn't enabled. The session started in Accept Edits — enable Bypass Permissions in Settings to use it."

Confirming same issue on MacOS, Immediate attention needed.

needed fix

Confirmed. This needs attention.

+1

+1

+1 (on windows 11)

Bug report — Bypass permissions.md

+1

+1, btw I use Windows 11

Same. Windows 11

+1,Windows 11

+1 on MacOS

+1 macos and i try claude to inspect and repair the setting files and still couldn't be solved

Workaround: ensure ~/Library/Application Support/Claude/claude_desktop_config.json contains:

{
  "preferences": {
    "bypassPermissionsModeEnabled": true
  }
}

Then relaunch. Happy trails.

Confirmed - that workaround did the trick for me. Thanks!

{ "preferences": { "bypassPermissionsModeEnabled": true } }

This workaround worked for me on:
MacBook Air (Intel)
Sequoia 15.7.5 (24G624)
Claude 1.8555.2 (a476c3)

Previously I encounter the same error as in this bug report: "Permission mode couldn't be changed. You can try again".

+1 spent 1 hour and cannot fix.

Windows 11 same

解决方法：确保~/Library/Application Support/Claude/claude_desktop_config.json包含： { "preferences": { "bypassPermissionsModeEnabled": true } } 然后重新启动。祝您一路顺风。

win11 Claude 1.8555.2 (a476c3) 2026-05-22T23:04:37.000Z 尝试各种方法，无效

i have the same issue on mac. it was working fine on my other computer (windows) a few days ago, so i suspect it's a regression.

Confirming this is still broken on the latest desktop build.

Environment

• Claude Code Desktop: 1.8555.2
• Claude Code CLI: 2.1.150
• macOS: 26.4.1 (Darwin 25.4.0, Apple Silicon)

Repro

1. Settings → Claude Code → "Allow bypass permissions mode" toggled ON.
2. ~/.claude/settings.json has "permissions": { "defaultMode": "bypassPermissions" }.
3. Project .claude/settings.json and .claude/settings.local.json also have "permissions": { "defaultMode": "bypassPermissions" }.
4. No managed settings under /Library/Application Support/ClaudeCode/managed-settings.json.
5. No disableBypassPermissionsMode anywhere.
6. skipDangerousModePermissionPrompt: true is set in user settings.

Expected
Session starts in bypass mode (or at least bypass is selectable from the mode picker).

Actual

• Bypass mode does not appear in the in-session permission mode selector.
• Shift+Tab cycles through the other modes only.
• defaultMode: "bypassPermissions" from settings.json appears to be ignored by the desktop app.

Works fine via CLI
Same machine, same settings files — claude --dangerously-skip-permissions and Shift+Tab both work as expected in the terminal. The bug is desktop-only.

Happy to provide logs / a sysdiagnose if helpful.

Same issue, Windows 11. Disappointing due to hours of time wasted attempting to fix.

Same on Windows 11

Same, Windows 11. This is extremely crippling to my work, having to constantly check in on Claude and accept edits. It should be working autonomously, but now I have to babysit.

Same, Windows 11. This is extremely crippling to my work, having to constantly check in on Claude and accept edits. It should be working autonomously, but now I have to babysit.

Your best bet is Auto mode right now, but this is kind of a not okay bug and Anthropic has yet to fix it. Hoping Anthropic can compensate for the wasted token usage (Auto Mode uses more token usage as it weighs what's safe and what's risky.

Having the same issue as well. Not being able to use "bypass permissions" makes the process so much harder and it takes away from being able to do autonomous work.

I am using a Macbook Pro Nov 2024, M4 Max on OS Tahoe 26.5 on the latest Claude Desktop app at the time of posting Claude 1.8555.2 (a476c3) 2026-05-22T23:04:37.000Z

I can't wait until this gets fixed.

Same issue on Win11. I managed to fix it in %APPDATA%\Claude\claude_desktop_config.json , adding "bypassPermissionsModeEnabled": true to the preferences object, then restarting the app.

samer here

Same issue on Win11. I managed to fix it in %APPDATA%\Claude\claude_desktop_config.json , adding "bypassPermissionsModeEnabled": true to the preferences object, then restarting the app.

Thanks @tedornitier - this has worked for me on Windows 11.

Same issue on Win11. I managed to fix it in %APPDATA%\Claude\claude_desktop_config.json , adding "bypassPermissionsModeEnabled": true to the preferences object, then restarting the app.

Confirmed patch, i have added.

{
  "preferences": {
    "bypassPermissionsModeEnabled":true,

And all worked thanks!

> Same issue on Win11. I managed to fix it in %APPDATA%\Claude\claude_desktop_config.json , adding "bypassPermissionsModeEnabled": true to the preferences object, then restarting the app. Thanks @tedornitier - this has worked for me on Windows 11.

Can also confirm this worked for me. Thanks, you saved me a ton of time!

same here on Mac OS 15.7.4

这是win10 desktop的解决方案，在下面这个路径
C:\Users\<用户名>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
添加 "bypassPermissionsModeEnabled": true
完整文件参考
{
"preferences": {
"coworkScheduledTasksEnabled": true,
"ccdScheduledTasksEnabled": true,
"bypassPermissionsModeEnabled": true,
"bypassPermissionsOptInByAccount": {},
"bypassPermissionsGateByAccount": {},
"coworkWebSearchEnabled": true,
"epitaxyPrefs": {
"starred-local-code-sessions": [],
"starred-cowork-spaces": [],
"starred-session-groups": [],
"dframe-local-slice": {
"pinnedOrder": [],
"customGroupAssignments": {},
"customGroupOrder": {}
}
}
}
}

Same Issue, MacBook Air, M5

Same issue on Win11. I managed to fix it in %APPDATA%\Claude\claude_desktop_config.json , adding "bypassPermissionsModeEnabled": true to the preferences object, then restarting the app.

Solved in macbook with same edit^

FYI, for macos the file you are looking for is ~/Library/Application Support/Claude/claude_desktop_config.json

**Workaround that survives the GrowthBook re-sync — set the launcher gate bypassPermissionsModeEnabled directly in claude_desktop_config.json (macOS, with explanation of why it works)**

Adding to the existing bypassPermissionsModeEnabled: true workaround already mentioned in this thread (kudos to the Win11 reporters above) with the macOS path, the launcher logic that explains why this is the right key, and a couple of caveats that bit me.

Why this specific key works (decompiled from app.asar)

The session-launcher's effective mode is computed like this:

const d = i.permissionMode ?? r?.permissionMode ?? u ?? sn.Default,
      h = Bi("bypassPermissionsModeEnabled") === true,
      f = d === sn.Bypass && !h,         // want bypass but launcher gate off?
      y = f ? sn.AcceptEdits : d;        // → forced downgrade
// ...later, when spawning the CLI:
d && Y.push("--allow-dangerously-skip-permissions")

If bypassPermissionsModeEnabled !== true, every Bypass session is silently downgraded to AcceptEdits at launch AND the CLI is spawned without --allow-dangerously-skip-permissions. That's why trying to flip the mode later also fails with "Permission mode couldn't be changed" — the CLI was never given the flag at spawn time, so it rejects any later setPermissionMode(bypass) call.

Three independent prefs are at play in the Desktop app, and only one is checked at session-launch time:

| Pref | Purpose | Where checked |
|---|---|---|
| bypassPermissionsOptInByAccount[uuid] | UI dropdown visibility | UI render |
| bypassPermissionsGateByAccount[uuid] | Settings toggle state | Settings UI |
| bypassPermissionsModeEnabled | Launcher gate — adds --allow-dangerously-skip-permissions | Session spawn |

The Settings UI toggle "Allow bypass permissions mode" sets the per-account flags but does not always set the global one (especially when the harbor A/B cohort is active — see #62205). The launcher then reads bypassPermissionsModeEnabled as undefined, treats it as false, and downgrades.

Fix (macOS)

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "preferences": {
    "bypassPermissionsModeEnabled": true,
    "bypassPermissionsOptInByAccount": {
      "<your-account-uuid>": true
    },
    "bypassPermissionsGateByAccount": {
      "<your-account-uuid>": true
    },
    "epitaxyPrefs": {
      "epitaxy-folder-permission-mode.<your-account-uuid>": {
        "/path/to/project": "bypassPermissions"
      }
    }
  }
}

Find your current account UUID:

grep -aoE "orgId=[a-f0-9-]+" ~/Library/Logs/Claude/main.log | sort -u | tail -1

Then fully ⌘Q Claude Desktop and:

chmod 444 ~/Library/Application\ Support/Claude/claude_desktop_config.json
# Relaunch Claude Desktop; verify Bypass Permissions sticks past the first prompt
chmod 600 ~/Library/Application\ Support/Claude/claude_desktop_config.json

The temporary chmod 444 matters: when Claude Desktop quits, it serializes its in-memory prefs back to this file. Since the in-memory state from the previous launch doesn't contain your new bypassPermissionsModeEnabled: true, the quit-time write strips it. Locking the file read-only across one quit/relaunch cycle preserves the edit long enough for the new launch to read it into memory.

Why this is more durable than the ~/.claude.json patch in #62205

#62205 correctly identifies that GrowthBook flags tengu_permission_friction + tengu_quill_harbor: "acceptEdits" are the underlying cause for users in the harbor A/B cohort. But ~/.claude.json's cachedGrowthBookFeatures is re-synced from Anthropic's GrowthBook CDN every ~9 minutes — any patch there gets clobbered. claude_desktop_config.json is local user state, never re-synced, so the launcher-gate fix persists.

I'm in that A/B cohort (tengu_harbor=true, tengu_harbor_permissions=true, tengu_permission_friction=true, tengu_quill_harbor=acceptEdits) and setting bypassPermissionsModeEnabled: true alone defuses both symptoms — the session-launch downgrade AND the "Permission mode couldn't be changed" error — because the launcher gate short-circuits before the GrowthBook-derived session default is applied.

Extra gotcha — account UUID mismatch after reinstall/re-auth

A reinstall + re-auth can land you on a different orgId than the one your existing bypass flags are keyed to. In my case the flags were keyed to a now-defunct UUID and my active account was a new one. The Settings toggle reported "on" but pointed at a dead UUID — the fix appeared applied but had no effect.

To check:

# Active account UUID (current orgId):
grep -aoE "orgId=[a-f0-9-]+" ~/Library/Logs/Claude/main.log | sort -u | tail -1

# UUIDs your bypass flags are keyed to:
python3 -c "
import json
d = json.load(open('/Users/USERNAME/Library/Application Support/Claude/claude_desktop_config.json'))
p = d['preferences']
print('OptIn keys:', list(p.get('bypassPermissionsOptInByAccount', {}).keys()))
print('Gate  keys:', list(p.get('bypassPermissionsGateByAccount', {}).keys()))
"

If they don't match, duplicate the entries under the active UUID (you can keep the old ones too).

Environment

• macOS 26.4.1 (25E253), Apple Silicon
• Claude Desktop 1.9255.0, embedded Claude Code 2.1.149
• Plan: Max
• Verified before/after in ~/Library/Logs/Claude/main.log:
• Before: [error] [CCD] Failed to set permission mode for session ...: Cannot set permission mode to bypassPermissions because the session was not launched with --dangerously-skip-permissions
• After: [info] [CCD] Set permission mode for session ... to bypassPermissions

Cross-ref for the deeper A/B-flag root cause: #62205. Other related: #61436, #61618, #62076.

Same issue on Win11. I managed to fix it in %APPDATA%\Claude\claude_desktop_config.json , adding "bypassPermissionsModeEnabled": true to the preferences object, then restarting the app.

Thanks.

Reproduced on macOS Desktop, with root cause traced to a GrowthBook flag override.

Setup:

Desktop app on macOS (Darwin 25.3.0)
Settings → "Allow bypass permissions mode" toggled on
~/.claude/settings.json contains "permissions": { "defaultMode": "bypassPermissions" }
Behavior:

Every new session starts in Accept Edits with the banner: "Bypass Permissions mode isn't enabled. The session started in Accept Edits — enable Bypass Permissions in Settings to use it."
Attempting to switch modes manually fails with "Permission mode couldn't be changed."
claude --dangerously-skip-permissions from the CLI on the same machine works fine.
Root cause:

~/.claude.json contains cachedGrowthBookFeatures.tengu_quill_harbor = "acceptEdits", mirrored to top-level tengu_quill_harbor on launch.
Editing either field manually is reverted on the next launch (the cache appears to refetch or the launcher re-mirrors).
Related flags on the account: tengu_permission_friction: true, tengu_harbor_permissions: true, tengu_disable_bypass_permissions_mode: false — i.e. bypass mode is available, just forcibly defaulted off by experiment assignment.
The UX problem: the Settings toggle and the local permissions.defaultMode value are both silently overridden by the server-side experiment. From the user's perspective, the setting is enabled but does nothing, with no indication that an experiment is in control. At minimum the toggle should either (a) actually override the experiment for users who explicitly opt in, or (b) be disabled with a visible "managed by your account configuration" message.

Workaround for affected users: use claude --dangerously-skip-permissions from the CLI. The Desktop app is unusable for bypass-mode workflows until the local override path is fixed or the experiment exits.

The fact that this issue is still in effect after several days is very disappointing.

The same problem

same issue

same issue

same issue

Same issue here - nothing seems to work against it...

same issue

same issue

Same issue with the Windows Desktop app, works in CLI

same issue

Close Claude Desktop, then add "bypassPermissionsModeEnabled": true to the preferences section in claude_desktop_config.json:

• 3p: %LOCALAPPDATA%\Claude-3p\claude_desktop_config.json
• Store: %APPDATA%\Claude\claude_desktop_config.json

{
  "deploymentMode": "3p",
  "coworkUserFilesPath": "C:\\Users\\my\\Claude",
  "preferences": {
    "coworkScheduledTasksEnabled": true,
    "ccdScheduledTasksEnabled": false,
    "sidebarMode": "epitaxy",
    "bypassPermissionsModeEnabled": true,
    "bypassPermissionsOptInByAccount": {
      "a862753b-d6e9-4c66-9ffd-62ef7a970eef": true
    },
    "bypassPermissionsGateByAccount": {
      "a862753b-d6e9-4c66-9ffd-62ef7a970eef": true
    },
    "coworkWebSearchEnabled": true,
    "remoteToolsDeviceName": "desktop-39jh5vi",
    "epitaxyPrefs": {
      "cc-landing-draft-permission-mode": "acceptEdits",
      "cc-landing-worktree-enabled": false,
      "claude-code-preferred-editor": "vscode",
      "dframe-local-slice": {
        "pinnedOrder": [],
        "customGroupAssignments": {},
        "customGroupOrder": {}
      },
      "epitaxy-folder-permission-mode.a862753b-d6e9-4c66-9ffd-62ef7a970eef": {
        "D:\\my-skills": "bypassPermissions"
      },
      "epitaxy-perm-mode-acks.a862753b-d6e9-4c66-9ffd-62ef7a970eef": [
        "D:\\my-skills:bypassPermissions"
      ],
      "starred-cowork-spaces": [],
      "starred-local-code-sessions": [],
      "starred-session-groups": []
    }
  }
}

Save and restart Claude Desktop. Note: the app may rewrite this file on restart and strip the field, so you might need to re-add it.

@fucknoobhanzo's comment worked for me.
fyi on a mac, claude_desktop_config.json can be found in ~/Library/Application\ Support/Claude/

Same issue and claude_desktop_config.json does not exist. The Claude-3p folder is just an empty file directory.

Same here, I have Claude version 1.9659.2 (390d6c) and I am running on macOS Tahoe 26.3.1

Adding: "bypassPermissionsModeEnabled": true in ~/Library/Application\ Support/Claude/claude_desktop_config.json does not work.

Same here, I have Claude version 1.9659.2 (390d6c) and I am running on macOS Tahoe 26.3.1 Adding: "bypassPermissionsModeEnabled": true in ~/Library/Application\ Support/Claude/claude_desktop_config.json does not work.

Adding: "bypassPermissionsModeEnabled": true in ~/Library/Application\ Support/Claude-3p/claude_desktop_config.json

Same. Workaround doesn't help. I'm in dev mode with a local LLM. Could it be that?

any feedback ? till have this issue after a month...

This is seriously annoying, same issue here.

same issue.