How do you require human approval when Claude Code runs in auto mode?

How do you require human approval when Claude Code runs in auto mode?

There are two ways, and most organizations use both. Claude Code's own managed settings can turn auto mode off for everyone with permissions.disableAutoMode. A hook policy can read the permission mode on every tool call and refuse the call when the session is running without human approval, which also covers the other prompt-skipping modes and lets you measure how often they're used before you enforce anything.

Claude Code's permission mode decides which actions it takes without asking. In Manual mode it stops and asks before most edits, shell commands, and network requests. In auto mode, a separate classifier model reviews actions instead of a person. bypassPermissions skips checks entirely, and dontAsk denies anything that would have prompted. With Claude Code v2.1.283 or later, auto mode is the default starting mode for interactive terminal and VS Code sessions, so it's likely to be what your developers are running.

Which Claude Code permission modes skip human approval?

Claude Code reports its permission mode on every hook event. The following table shows each value and whether a person approves risky actions in that mode:

Manual mode arrives in the hook payload as default. OpenAI Codex reports the same values except auto, which it doesn't have, so a policy over this field covers both agents. GitHub Copilot and Cursor don't report a permission mode.

What can Claude Code's own settings do?

Start with Claude Code's managed settings, which outrank anything a developer configures:

• permissions.disableAutoMode: "disable" removes auto mode so that nobody can select it.
• disableBypassPermissionsMode keeps Claude Code's permission flow in place by preventing bypassPermissions.
• permissions.defaultMode sets the mode that sessions start in, though developers can still switch modes during a session.
• Deny and ask rules target specific tools. Deny rules block in every mode, including bypassPermissions, and ask rules still force a prompt in auto mode.

If your answer is "nobody runs in auto mode," the settings file is the control – deploy it through managed settings or MDM. For more information about deployment, see securing Claude Code in the enterprise.

What does a hook policy add?

A hook policy is useful when the answer is more nuanced than on or off, or when you want evidence before you decide:

• Measure first. Publish the policy in dry run and see how many sessions, and which teams, run in auto mode before you block anything.
• Cover every prompt-skipping mode in one rule. The same policy refuses auto, bypassPermissions, and dontAsk.
• Restrict risky tools only. Allow auto mode for reads and edits, and require Manual mode for shell commands and network requests.
• Record every decision. Each allowed and denied call appears in the session's activity, next to your other coding agent policies.

Arcjet's coding-agent.no-auto-mode starter policy runs with Execute on set to Tool call and refuses every tool call in an autonomous mode:

1
autonomous := {"auto", "bypassPermissions", "dontAsk"}
2

3
deny contains "autonomous-mode" if {
4
  input.values.permission_mode in autonomous
5
}

It allows calls in default, plan, and acceptEdits, and it allows calls from agents that don't report a mode. For the starter and its stored tests, see the Require human approval section of the coding agent policy docs.

To allow auto mode for everything except risky tools, add a condition on tool_kind:

1
autonomous := {"auto", "bypassPermissions", "dontAsk"}
2

3
needs_a_person := {"shell", "web", "mcp"}
4

5
deny contains "autonomous-risky-tool" if {
6
  input.values.permission_mode in autonomous
7
  input.values.tool_kind in needs_a_person
8
}

This variant still allows file writes in an autonomous mode, because editing code without asking is usually what developers want from auto mode. Add "file_write" to needs_a_person if a person needs to approve edits too.

When the policy denies a call, the agent receives the rule ID, and the developer can switch to Manual mode with Shift+Tab and approve the command themselves.

Can you allow a few commands in auto mode, then require approval?

Not with a count. Each tool call is decided on its own inputs, and there's no counter across calls on this path, so "allow 10 commands in auto mode, then stop" isn't something a policy expresses. Choose one of these instead:

• Block by tool kind, as in the preceding example, so auto mode covers low-risk work and a person approves the rest.
• Block by command or destination, with policies such as coding-agent.destructive-command and coding-agent.aws-access, and leave auto mode alone.
• Lock the session after a finding. Session tainting stops shell, web, MCP, and write calls after a prompt injection or a credential finding earlier in the session, whatever the mode. For more information, see what is session tainting?.

Isn't Claude Code's auto mode classifier enough?

The classifier is a real safety layer: it reviews actions before they run and blocks ones that escalate beyond the request or appear driven by hostile content. Anthropic's own documentation says that auto mode reduces permission prompts but doesn't guarantee safety, and recommends it for tasks where you trust the general direction.

A hook policy complements the classifier rather than replacing it. The classifier judges intent with a model; a policy applies rules your security team wrote and tested, the same way on every agent, with a record of each decision. For example, a policy can deny every request to an AWS host whatever the classifier thinks of the task. For how that works, see stopping coding agents using AWS credentials.

How do you roll out an auto mode policy?

1. Publish coding-agent.no-auto-mode in dry run. Arcjet starter policies arrive in dry run, so nothing is blocked yet.
2. Review a week of activity. In the Arcjet Console, check how many sessions ran in each mode and which tool calls the rule would have denied.
3. Decide the rule. Block all autonomous modes, block only risky tool kinds, or turn auto mode off in managed settings instead.
4. Tell developers before you enforce. A denied call in the middle of a long auto-mode task is confusing if nobody expected it.
5. Switch the rule to live.

Claude Code's HTTP hooks let an action through if the policy service times out, so pair the policy with the native settings for the modes you never want. For more information, see coding agent hooks fail open.