Desktop 1.20186.9: both `auto` and `bypassPermissions` report "not available for this session" despite toggle ON, Max plan, and clean config

Summary

In a local Claude Code session in the Claude Desktop app, selecting either auto mode or bypassPermissions mode from the mode picker fails with "bypass permissions is not available for this session — asking for permissions instead", and the session falls back to default ask-mode (prompting on every tool call).

Both modes fail together, which suggests a single shared gate rather than two independent bugs. This worked for months on permissions.defaultMode: "auto" and regressed around 2026-07-14.

Environment

• Claude Desktop: 1.20186.9 (app reports "you're on the latest version")
• Bundled Claude Code: 2.1.207
• OS: macOS (Darwin 25.5.0), Apple Silicon
• Plan: individual Max, active, auto-renewing, invoices paid
• Session type: local Claude Code session — not Cowork, not remote control, not a cloud/VM session

Steps to reproduce

1. Open a local Claude Code session on a project folder in Claude Desktop
2. Select auto (or bypass permissions) in the mode picker
3. Mode reverts; message: "bypass permissions is not available for this session"

Expected

auto and bypassPermissions are selectable and persist for the session.

Actual

Both are refused. Session is forced into default ask-mode and prompts on every tool call.

Ruled out (all verified directly)

• Settings → Claude Code → "Allow bypass permissions mode" is ON (confirmed visually)
• ~/.claude/settings.json → permissions.defaultMode = auto (also tried bypassPermissions)
• permissions.deny = only Read(.env*) entries; permissions.ask = only Bash(git push*)
• No disableAutoMode in any scope
• No disableBypassPermissionsMode in any scope
• No /Library/Application Support/ClaudeCode/managed-settings.json (file does not exist); no managed-settings.d
• No PermissionRequest hook registered (hooks present: SessionStart, PreToolUse, PostToolUse, Notification, Stop, SessionEnd)
• disableAllHooks / allowManagedHooksOnly: absent
• Individual account (the org ID is the personal account container — no Team/Enterprise policy)
• Not a stale build (app installed 2026-07-14; reports latest)
• A sandbox block in settings was set to enabled: false and then removed entirely → no change. Confirmed empirically that the sandbox was not enforcing at the time (writes outside the project and SSH to non-allowlisted hosts both succeeded with no bypass flag).

Desktop config state

claude_desktop_config.json shows what look like the correct "enabled" values:

• preferences.bypassPermissionsOptInByAccount → {<account>: true}
• preferences.bypassPermissionsGateByAccount → {<account>: true}
• preferences.epitaxyPrefs.epitaxy-folder-permission-mode.<account> maps the project folder → "bypassPermissions"
• preferences.epitaxyPrefs.epitaxy-perm-mode-acks.<account> contains "<folder>:bypassPermissions" (disclaimer previously acknowledged)

Notably, one other project folder is still mapped to "auto" and has continued to work without prompting, while folders mapped to "bypassPermissions" prompt on everything.

Workaround

Extending permissions.allow works, because allow-list entries auto-approve even in default ask-mode. So work can continue — but the mode picker is effectively non-functional.

Notes

• The regression window aligns with the 2026-07-14 Desktop app install.
• Happy to provide the account/org UUIDs privately if that helps check for an account-side gate.