Are Claude Code managed settings enough to stop dangerous commands?

the short answer

No, not on their own. Managed settings are the right way to lock Claude Code’s configuration: deny rules, bypass-mode controls, managed-only permission rules. But Bash deny rules match the command text Claude writes, and Anthropic’s docs say they are not a security boundary around the program. They also cover one harness. Use them as the base, and add a hook-level policy that judges effects across every agent your developers use.

Good for: Locking settings, disabling bypass mode, managed-only permission rules
Weak at: Absolute paths, bash -c, scripts and wrappers that do the same thing
Server-managed caveat: A client-side control, not a security boundary, per Anthropic
Scope: Claude Code only; Codex, Cursor and Copilot each have their own scheme
Hook caveat: Hooks fail open on crash or timeout unless onFailure: "block" (v2.1.295+)

What Managed Settings Do Well

That is real control, and you should use it. On the developer’s machine, the terminal, the VS Code and JetBrains extensions, the desktop app’s Code tab and Agent SDK sessions all read managed settings. Anthropic-hosted cloud sessions do not read the device file and need server-managed settings; Claude Tag and Cowork are configured separately.

Setting	Effect
Managed file or MDM profile	macOS `/Library/Application Support/ClaudeCode/managed-settings.json` or the `com.anthropic.claudecode` domain; Linux `/etc/claude-code/managed-settings.json`; Windows `C:\Program Files\ClaudeCode\managed-settings.json` or a `Settings` value under `HKLM\SOFTWARE\Policies\ClaudeCode`
Precedence	Managed settings beat command-line, project and user settings. Nothing in a user’s files overrides a managed key.
`permissions.disableBypassPermissionsMode: "disable"`	Rejects bypass mode and `--dangerously-skip-permissions`
`allowManagedPermissionRulesOnly`	Only managed permission rules count; user and project rules are ignored
`allowManagedHooksOnly`	Only managed hooks, Agent SDK hooks and hooks from force-enabled plugins run; user, project and local hooks are blocked

Where Deny Rules Fall Short

Anthropic’s permissions documentation is direct about it: a Bash rule matches the command text Claude writes and is not a security boundary around the program. Compound commands are split, and a deny rule applies when any part matches. What gets past is a different spelling of the same program, or the same effect through another program.

Intent	Deny rule	Still runs
No recursive deletes	`Bash(rm *)`	`/bin/rm -rf build/`, `bash -c 'rm -rf build/'`
No downloads	`Bash(curl *)`	`/usr/bin/curl ...`, `sh -c 'curl ...'`
No pushes	`Bash(git push *)`	`git -C . push origin main`
No reading secrets	`Read(./.env)`	A Python or Node script that opens the file itself
No DNS deletes	`Bash(aws route53 *)`	A `boto3` script, Terraform, a `Makefile` target

Server-Managed Settings Have a Stated Limit

Teams and Enterprise organizations can push settings from the Claude admin console, and Claude Code fetches them at startup and polls hourly. Anthropic’s docs describe them as a client-side control, not a security boundary: on unmanaged devices a user does not need admin rights to bypass them, and pointing Claude Code at Bedrock, Vertex or a custom base URL skips the fetch unless settings are delivered through a Claude apps gateway. Endpoint-managed files, protected by OS permissions, give stronger guarantees. Even those can be edited by a developer who is a local admin, which is why MDM tools redeploy them on a schedule.

Managed Settings and the Failproof Hook

failproofai config installs its Claude Code hooks at user scope, in ~/.claude/settings.json. That interacts with two managed keys you should understand before setting them.

`allowManagedHooksOnly` turns Failproof off. It blocks user, project and local hooks, which are exactly the scopes Failproof installs into. Only set it if the Failproof hook entries are also delivered through managed settings. That is not a documented Failproof install path; talk to us about a managed deployment.
A hook that crashes or times out lets the call through unless the hook entry sets "onFailure": "block" (Claude Code v2.1.295 or later). Failproof itself denies when its daemon is unreachable, but the agent’s own timeout handling decides what happens if the hook process never answers.
`disableAllHooks` in user or project settings cannot disable managed hooks, but it can disable user-scope hooks. Watch for it in the Observe → policy view, which reports unguarded actions per machine.

And They Only Cover Claude Code

Codex has requirements.toml and managed hooks; Cursor has enterprise hooks.json paths and team hooks; Copilot has root-owned CLI policy hooks and enterprise managed settings across Copilot CLI, VS Code, the Copilot app, the cloud agent and JetBrains. Each schema differs and none reads the others. A team that standardizes on one tool’s settings has to rebuild every rule when developers adopt another. See one policy across agents.

The Combination We Recommend

Deploy Claude Code managed settings through MDM with permissions.disableBypassPermissionsMode and disableAutoMode set to "disable", a short deny list for the obvious cases, and login pinned to your organization.
Install Failproof on every machine with failproofai config so its hooks run in every supported agent, and leave allowManagedHooksOnly off unless the Failproof hooks are in managed settings too.
Write effect-level policies once as custom Failproof policies: Terraform plan-only, Route 53 protection, approved AWS profile. They then run in Claude Code, Codex, Cursor and the other supported harnesses.
Add Jev review for the indirect cases string rules cannot see: Jev comes with Failproof, so install the FailproofAI/jev-policies pack and turn Jev on with failproofai jev setup whenever you choose. For rules of your own, we write custom checks.
Keep IAM least privilege underneath. Every layer above it reduces probability; IAM bounds the outcome.

FAQ

Do PreToolUse hooks override permission rules?

No. Per Anthropic’s docs, hook decisions do not bypass permission rules: a matching deny rule still denies. Hooks add checks; they do not remove managed restrictions.

Is the Claude Code sandbox a substitute?

It is a strong complement. The sandbox enforces filesystem and network limits on Bash commands at the OS level, but it is off by default, does not cover file tools, MCP servers or hooks, and by default can read most of the machine, including ~/.aws/credentials. See hooks vs sandbox vs managed settings.

Should we stop using managed settings if we use Failproof?

No. Use managed settings to lock the harness; use Failproof for the policy logic that must hold across agents and for fleet visibility.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.