claude code managed settings not enforced

Five Reasons, from Most to Least Common

1. The wrong source is active. Managed sources rank server-managed, then MDM (plist or HKLM), then the managed file, then HKCU. By default ("first-wins") the first source with a policy wins for most keys and the others are ignored, so adding one console setting can silently replace a file-based policy. Since v2.1.242, managedSourcesBehavior: "merge" combines them; a few keys, such as env, are read from every admin source either way.
2. The session reads a different source. The terminal, the VS Code and JetBrains extensions, the desktop app’s Code tab and Agent SDK sessions read the device’s managed settings. Anthropic-hosted cloud sessions do not read the device file and need server-managed settings; Claude Tag sessions do not receive server-managed settings; Cowork is configured separately.
3. The provider path skips server-managed settings. Anthropic documents that setting CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX or a non-default ANTHROPIC_BASE_URL skips the server-managed fetch, unless settings are delivered through a Claude apps gateway.
4. The rule never matched. A deny rule matches the command text Claude writes. Compound commands are split and deny rules apply to each part, but bash -c, absolute paths (/bin/rm), scripts and Makefile targets produce text the rule does not describe.
5. A version bug. Several reports describe disableBypassPermissionsMode not blocking --dangerously-skip-permissions on specific versions.

Reported Gaps and Their Status

“Closed as not planned” often means a stale-issue bot closed it, not that it was fixed or that it still reproduces. Test on your own versions. One reporter summarized the frustration bluntly in #82704: managed settings are “trivially bypassable in most environments, especially in an Agent-powered world.”

Diagnose It on One Machine

1. Run /status inside Claude Code and read the Setting sources line.
2. Check every managed source on the machine: the server-managed console, the MDM profile or registry key, and the managed file. Unless you set "merge", only the first one with a policy applies for most keys.
3. Check for ANTHROPIC_BASE_URL, CLAUDE_CODE_USE_BEDROCK and CLAUDE_CODE_USE_VERTEX in the developer’s environment.
4. Reproduce the blocked action in the terminal, then in each IDE extension and the desktop app your developers use.
5. Try the action indirectly: through bash -c, a script, and an absolute path. If any of those run, the rule is matching text, not effect.

Make Enforcement Independent of the Source

Managed settings remain the right way to lock Claude Code’s own configuration; keep them. For rules that must hold everywhere, add enforcement at the hook level on the machine. On a machine configured for its daemon, Failproof evaluates every gated tool call there, fails closed if the daemon is unreachable, and applies the same policy to Codex, Cursor and Copilot CLI sessions on the same laptop. On Codex, the hooks only run once trusted: installed through sudo into /etc/codex/config.toml, or approved in codex.

• Use one managed source per fleet, or set managedSourcesBehavior: "merge", so the source rule never surprises you.
• Do not set allowManagedHooksOnly unless your enforcement hook is itself delivered in managed settings: it blocks the user and project-scope hooks that failproofai config installs. Delivering the Failproof hook through managed settings is not a documented install path; talk to us about a managed deployment.
• Set "onFailure": "block" (v2.1.295+) on any managed policy hook, so a crash or timeout does not let the call through.
• Write effect-level policies (Terraform destroy, DNS deletes, .env reads) once in the policy layer, not as Bash patterns.
• Re-test after every Claude Code upgrade, and watch Observe → policy for unguarded actions on each machine.