claude-code - 💡(How to fix) Fix Desktop 1.8555.0 (Windows): bypassPermissions mode ignored despite all config keys = true

Update 2026-05-23 (post-investigation): Initial hypothesis (per-account UUID config keys true but ignored) was partially incorrect. Deeper log inspection identified a separate top-level preference bypassPermissionsModeEnabled as the actual gate. Full updated diagnosis below.

Summary

Claude Desktop 1.8555.0 on Windows 11 persistently downgrades new Code sessions from bypassPermissions to acceptEdits at session start, citing a top-level bypassPermissionsModeEnabled preference being off — even though Settings → Local sessions → "Allow bypass permissions mode" toggle is visually ON, every per-account opt-in key in claude_desktop_config.json is true, and per-folder epitaxy-folder-permission-mode is bypassPermissions. Restart cycle does not fix it. Surgical config-file edits to per-account UUID keys do not fix it. Only a full toggle-OFF → quit-Desktop → relaunch → toggle-ON cycle restores correct behaviour, suggesting the toggle write path was broken on initial sync after the 1.8555.0 destructive migration of %APPDATA%\Claude\.

Environment

• OS: Windows 11
• Claude Desktop: 1.8555.0 (install timestamp 2026-05-22 23:36:42 UTC; install replaced 539 files under %APPDATA%\Claude\, 0 files older than 24h — destructive migration confirmed)
• Bundled Claude Code CLI: 2.1.149
• MSIX install: C:\Program Files\WindowsApps\Claude_1.8555.2.0_x64__pzs8sxrjxfjjc\app\Claude.exe
• Project folder: C:\Users\<user>\projects\<project>

Real root cause (verified)

The actual permission gate is a top-level bypassPermissionsModeEnabled preference, separate from the per-account opt-in/gate keys in claude_desktop_config.json. The CCD subsystem reads this preference at session start; if off, it downgrades the session mode regardless of any per-account/per-folder config. The Claude Code CLI binary further refuses runtime mode switches to bypassPermissions unless launched with --dangerously-skip-permissions.

Verbatim log evidence from %APPDATA%\Claude\logs\main.log:

2026-05-23 05:25:35 [info] [CCD] Downgrading session local_3626afd2-... bypassPermissions → acceptEdits at start — bypassPermissionsModeEnabled pref is off

2026-05-23 05:12:58 [error] [CCD] Failed to set permission mode for session local_50dc35a7-...: Cannot set permission mode to bypassPermissions because the session was not launched with --dangerously-skip-permissions
    at handler (C:\Program Files\WindowsApps\Claude_1.8555.2.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:461:6164)

The downgrade-at-start pattern repeats for every session post-update (15+ occurrences observed in main.log). Every subsequent setPermissionMode mode=bypassPermissions IPC call fails with the same error because the underlying PTY was launched without the --dangerously-skip-permissions flag.

The bypassPermissionsModeEnabled preference is not stored in any plain-text local file (verified via grep across claude_desktop_config.json, config.json, all JSON under %APPDATA%\Claude\). It is either stored in IndexedDB/LocalStorage (snappy-compressed, not text-greppable) or fetched server-side from the user account profile. After the 1.8555.0 destructive migration, the UI shows the toggle as ON while the actual preference value is OFF — a sync/persistence bug in the migration.

Config state observed (red herrings, not the gate)

All four bypass-related keys in claude_desktop_config.json were already true for both the personal account UUID and the org UUID, and per-folder mode was set to bypassPermissions:

{
  "preferences": {
    "bypassPermissionsGateByAccount": {
      "<account-uuid>": true,
      "<org-uuid>": true
    },
    "bypassPermissionsOptInByAccount": {
      "<account-uuid>": true,
      "<org-uuid>": true
    },
    "epitaxyPrefs": {
      "epitaxy-perm-mode-acks.<account-uuid>": [
        "C:\\Users\\<user>\\projects\\<project>:auto",
        "C:\\Users\\<user>\\projects\\<project>:bypassPermissions"
      ],
      "epitaxy-folder-permission-mode.<account-uuid>": {
        "C:\\Users\\<user>\\projects\\<project>": "bypassPermissions"
      }
    }
  }
}

Adding entries for additional UUIDs and editing this file directly did not resolve the toast — confirming these per-account keys are user acks / per-account opt-in records, not the actual runtime gate. Logs cite the gate as the singular top-level bypassPermissionsModeEnabled pref.

Repro

1. Install/update to Desktop 1.8555.0
2. Observe that Settings → Local sessions → Allow bypass permissions mode toggle is visually ON (without manual interaction)
3. Open a Code session in any folder
4. Send any message — toast immediately:

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

5. Attempt to switch mode via Shift+Tab or Mode dropdown → toast:

   Permission mode couldn't be changed. You can try again.

6. Check %APPDATA%\Claude\logs\main.log — confirms [CCD] Downgrading session ... bypassPermissions → acceptEdits at start — bypassPermissionsModeEnabled pref is off
7. Full Desktop quit (tray Quit, not window close) + relaunch — behaviour persists
8. Editing claude_desktop_config.json to add bypassPermissionsGateByAccount / bypassPermissionsOptInByAccount entries for additional account UUIDs — behaviour persists

Working fix sequence

The following sequence restores correct behaviour (verified on affected machine):

1. Settings → Local sessions → toggle Allow bypass permissions mode OFF (forces a fresh false write through the toggle persistence path)
2. Fully quit Desktop via tray icon → Quit (not window close-to-tray)
3. Relaunch Desktop
4. Settings → Local sessions → toggle Allow bypass permissions mode ON (forces a fresh true write — this is the step the 1.8555.0 migration apparently failed to perform on the toggle actual underlying preference)
5. Open a new Code session — bypass mode is now active

Looking at main.log after this fix, subsequent sessions no longer emit the Downgrading session ... pref is off line, and setPermissionMode IPC calls succeed.

Expected

After a Desktop update where the user previously had bypass permissions enabled, the toggle visible state and the underlying bypassPermissionsModeEnabled preference value must remain in sync. Currently the migration leaves the UI displaying true while the actual preference is false (or unset, defaulting to false), with no UI indication of the desync.

Hypothesis on the migration bug

The 1.8555.0 destructive replacement of %APPDATA%\Claude\ cleared the IndexedDB/LocalStorage state where bypassPermissionsModeEnabled lives. The UI toggle component, on first render, reads from a different source (per-account opt-in keys in claude_desktop_config.json, which were preserved from the pre-migration state and still showed true) — giving the visual illusion that bypass is still configured. Meanwhile the CCD session-spawning code reads the cleared bypassPermissionsModeEnabled value (now false/missing) and downgrades. Manually toggling OFF→ON re-syncs both sides.

Suggested fixes

1. Migration: ensure bypassPermissionsModeEnabled survives the %APPDATA%\Claude\ wipe (move to a preserved storage location, or re-derive from per-account opt-in keys if user had previously acknowledged bypass for the current account)
2. UI consistency: the toggle component should read from the same source CCD reads (bypassPermissionsModeEnabled), not from per-account opt-in keys, so visible state matches actual gate
3. Toast text: the current toast Bypass Permissions mode isn't enabled. The session started in Accept Edits — enable Bypass Permissions in Settings to use it. is misleading when the Settings toggle visibly shows ON. Either point to the toggle that needs interaction (e.g. "Toggle the setting off and back on to re-sync") or detect the desync and show a more accurate message.

Severity

High — bypass mode is fully unusable via Desktop UI after migration until the user discovers the toggle re-cycle workaround. Existing workflows that depend on uninterrupted execution break silently after update.

Affected user impact (real-world experience)

User on the affected machine spent approximately 90 minutes attempting various fixes (multiple Desktop relaunches, direct edits to claude_desktop_config.json, adding/removing per-account UUID keys, editing ~/.claude/settings.json with defaultMode: bypassPermissions, etc.) before discovering the toggle-cycle workaround. Logs were diagnostic but not surfaced in any visible error — the actionable bypassPermissionsModeEnabled pref is off line is buried in %APPDATA%\Claude\logs\main.log while the user-facing toast points at the wrong remediation ("enable Bypass Permissions in Settings" when it is already showing as enabled).

Related local symptoms also observed (probably same migration bug class)

• Theme: prior dark reverted to system default
• Window state: position/size reset to defaults
• Connector/MCP list: visually empty in Settings → Connectors (per-account config preserved but UI list not rendering)
• Sessions sidebar: only the newest session visible immediately after migration, older sessions not indexed in claude-code-sessions/ registry despite .jsonl files being intact in ~/.claude/projects/<encoded-folder>/

All point to the same pattern: 1.8555.0 wiped Electron user-data store, and various UI components fall back to different secondary sources that do not represent the true gate, causing user-facing inconsistencies.