›_ Claude Code Issues
Claude Code Issues / #86478

bypassPermissions defaultMode and --permission-mode flag ignored; session stays in auto mode (since 2026-08-14 auto-mode rollout)

Status Open
Reported on v2.1.231
Maintainer reply ✓ Yes — bcherny
Activity 3 comments · opened Aug 13, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Description

Even with permissions.defaultMode: "bypassPermissions" correctly set in every settings file, and even when starting a brand-new session with the explicit flag claude --permission-mode bypassPermissions, the session still starts in (and stays in) auto mode, not bypass-permissions mode. This appears to have started on 2026-08-14, the day auto mode became the default permission mode for Pro/Max/Team plans.

Environment

  • Claude Code version: 2.1.231
  • OS: Linux
  • Plan: Claude Max (claude_max), personal org, account role admin (not an enterprise/managed account)
  • Install: native launcher (~/.local/bin/claude -> ~/.local/share/claude/versions/2.1.231)

Steps to reproduce

  1. Confirm permissions.defaultMode: "bypassPermissions" is set in all of:
  • ~/.claude/settings.json
  • ~/.claude/settings.local.json
  • <project>/.claude/settings.json
  • <project>/.claude/settings.local.json
  1. Fully exit any running session (/exit).
  2. Start a brand-new session with the explicit enabling flag:

``
claude --permission-mode bypassPermissions
``

  1. Observe the mode indicator in the status line / prompt.

Expected behavior

Per the docs (https://code.claude.com/docs/en/permission-modes#skip-all-checks-with-bypasspermissions-mode):

Enable it at launch with permissions.defaultMode: "bypassPermissions" in settings or with an enabling flag: claude --permission-mode bypassPermissions

The session should start in bypassPermissions mode (showing the one-time warning dialog on first use), or at minimum the CLI flag should override any other default.

Actual behavior

  • The session starts in auto mode regardless.
  • Confirmed via the native mode indicator: ⏵⏵ auto mode on (shift+tab to cycle).
  • Also confirmed via a native permission prompt on a command with an explicit Ask rule (Bash(rm:*)):

> Ask rule Bash(rm:*) overrides auto mode for this command.

This message names the active mode as "auto mode", not "bypass permissions", confirming the mode itself (not just a display artifact) is auto.

  • This happens both in a session resumed/continued from before, AND in a genuinely fresh session started with --permission-mode bypassPermissions explicitly.

Things already ruled out

  • No managed-settings.json at any known path (/etc/claude-code/managed-settings.json, ~/.claude/managed-settings.json).
  • No disableAutoMode / disableBypassPermissionsMode keys found anywhere in the settings cascade or in ~/.claude.json.
  • No shell alias/wrapper adding --continue/--resume or any other flag to claude.
  • Only one claude binary on PATH (no npm-global/local shadow install).
  • Account is a personal Claude Max org where the user is the org admin — no external org policy should apply.
  • All 4 relevant settings files are valid JSON and agree on defaultMode: "bypassPermissions".

Suspicion

Given the exact timing (2026-08-14, the day auto mode became the default for Pro/Max/Team), this looks like a rollout-related regression where the server-side "auto mode is now default" push is overriding both local defaultMode settings and the --permission-mode / --dangerously-skip-permissions launch flags, rather than only applying when no other mode is configured.

View original on GitHub ↗

3 Comments

bcherny collaborator · 15 days ago

Could not reproduce on v2.1.233 (macOS).

Steps tried:

  1. ~/.claude/settings.json with permissions.defaultMode: "auto" (so auto is the account-level default).
  2. Fresh project with .claude/settings.json = {"permissions":{"defaultMode":"bypassPermissions"}}.
  3. claude --permission-mode bypassPermissions in that directory; accepted the workspace-trust prompt.
  4. Also plain claude in the same directory (project setting only).

Observed: both sessions start with ⏵⏵ bypass permissions on (shift+tab to cycle), not auto mode.

Expected: the same, matching the docs.

Assessment: If a session really starts in auto mode with --permission-mode bypassPermissions on the command line, that is a genuine bug — the docs (https://code.claude.com/docs/en/permission-modes#which-mode-a-session-starts-in) say the flag beats every settings file and the built-in default, and the built-in auto default is only meant to apply when nothing else picks a mode. We could not make it happen here, though. The one known way for a bypass request to end up in auto is when bypass permissions mode is disabled for the account (by an org policy or permissions.disableBypassPermissionsMode); in that case Claude Code prints a startup notice like "Bypass permissions mode was disabled by your organization policy" and then falls through to the built-in default, which is now auto on Pro/Max/Team. Could you check whether that notice appears at the top of your session, and if not, share the first ~30 lines of claude --debug --permission-mode bypassPermissions (or a /share link)? That would show which mode source won at startup.

🤖 Generated with Claude Code

github-actions[bot] · 15 days ago

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.

katelovescode · 8 days ago

Seeing the same underlying bug, but with manual as the configured default rather than bypassPermissions.

Environment

  • Claude Code version: 2.1.240
  • OS: macOS (Darwin 25.5.0)
  • Install: native launcher (~/.local/bin/claude -> ~/.local/share/claude/versions/2.1.240)

Steps to reproduce

  1. /config shows "Default permission mode: Manual" (set via the Settings UI, not a settings file).
  2. Started a brand-new session with plain claude (no flags) in a project directory.
  3. Statusline showed auto mode on at launch, not manual.
  4. Mid-session, after an unrelated message, the mode silently switched to manual (system reminder: "Exited Auto Mode") with no user action to trigger it.

Things ruled out

Checked the full settings cascade for a defaultMode/permissionMode override:

  • ~/.claude/settings.json
  • ~/.claude/settings.local.json
  • <project>/.claude/settings.json
  • <project>/.claude/settings.local.json
  • /Library/Application Support/ClaudeCode/managed-settings.json (absent)
  • ~/.claude.json (deep search of all keys, including per-project entries)
  • ~/.claude/sessions/<pid>.json (per-session state)
  • Desktop app config (~/Library/Application Support/Claude/config.json)

No defaultMode/permissionMode key exists anywhere with value manual, despite /config displaying "Manual" as the current setting. Also confirmed the parent process is a plain interactive shell (not a wrapper/alias, not a nested/bridged session), so this wasn't a launch-flag issue.

One lead: ~/.claude.json's local feature-gate cache contains an entry named default-permission-mode-config (gate/rule-version IDs 218 and 15 in two separate cache blocks), which suggests the effective default may be resolved via a server-side experiment gate rather than purely from the /config-displayed local preference — consistent with the 2026-08-14 auto-mode-default rollout mentioned in this issue overriding whatever the UI shows as configured.

So the pattern in this issue (configured mode not respected at session start) reproduces for manual too, not just bypassPermissions — and in my case it also flips mode mid-session with no user action, which might be a related but distinct symptom worth separating out if useful.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →