managed-settings disableBypassPermissionsMode does not block --dangerously-skip-permissions (file proven loaded via deny rule in same session)

Summary

permissions.disableBypassPermissionsMode: "disable" in machine-local managed settings does not prevent claude --dangerously-skip-permissions from launching and running with permissions bypassed. The managed file is demonstrably loaded and enforcing — a permissions.deny rule in the same file correctly denies commands inside the same bypass session — so this is not a file-discovery problem: the bypass-block key specifically has no effect on the CLI flag.

Environment

• macOS (Darwin 25.5.0), Apple Silicon
• Claude Code CLI: reproduced on 2.1.220 and, after claude update, on 2.1.229
• Auth: ANTHROPIC_API_KEY set in the shell (the startup banner notes it takes precedence over the claude.ai login); the account also belongs to a claude.ai org that delivers server-side settings (claude doctor shows an org policy line for Remote Control)
• Managed settings file: /Library/Application Support/ClaudeCode/managed-settings.json, owned root:wheel, mode 644, valid JSON:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": { "strictAllowlist": true }
  },
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Bash(touch /tmp/managed-canary*)"]
  }
}

Steps to reproduce

1. Install the file above at /Library/Application Support/ClaudeCode/managed-settings.json.
2. Run a bypass-mode session non-interactively:

``bash
cd /tmp && rm -f bypass-proof.txt && \
claude --dangerously-skip-permissions -p "Run this exact bash command and report the result: echo BYPASS-ACTIVE > /tmp/bypass-proof.txt" ; \
ls -l /tmp/bypass-proof.txt
``

Expected

The CLI refuses to start in bypass-permissions mode (or at minimum downgrades and denies the un-preapproved write), because managed policy sets disableBypassPermissionsMode: "disable".

Actual

The session launches, runs the un-preapproved echo … > /tmp/bypass-proof.txt without any permission prompt or denial, and the file is created containing BYPASS-ACTIVE. Reproduced identically on 2.1.220 and 2.1.229.

Proof the managed file is loaded (same session type, same file)

The canary deny rule in the same managed file does fire inside a bypass session:

cd /tmp && rm -f managed-canary-1 && \
claude --dangerously-skip-permissions -p "Run this exact bash command and report success or the exact error: touch /tmp/managed-canary-1" ; \
ls -l /tmp/managed-canary-1

Result: Permission to use Bash with command touch /tmp/managed-canary-1 has been denied. — no file created. So within one --dangerously-skip-permissions -p invocation: managed permissions.deny enforces (file parsed, denies survive bypass, as documented), while disableBypassPermissionsMode does nothing.

Notes

• All observations are from non-interactive -p runs; interactive bypass mode was not tested and may or may not differ.
• claude doctor (2.1.229) prints no mention of the local managed-settings file (its only policy output is the claude.ai-org-delivered Remote Control line) — if machine-local managed settings are meant to be surfaced there, that may be a related gap; if not, a doctor line confirming the managed file was parsed would have shortened this investigation considerably.
• Possibly related: the 2.1.223 changelog entry "Fixed a permission gap where an agent definition's bypassPermissions mode ignored the org bypass-permissions disable policy" — this report is the analogous case for the top-level CLI flag vs. machine-local managed settings, still present after that fix.

Impact

disableBypassPermissionsMode is the documented fleet-wide hard-block for bypass mode on credential-bearing machines. With it silently ineffective, an operator who has verified their managed file loads (e.g. via a deny rule) can still not prevent --dangerously-skip-permissions from being invoked; the only effective mitigations we found are the OS sandbox (which does bind bypass sessions) and managed deny rules.