What you will be able to do
- Explain why reviewing every action wears down the quality of human oversight
- Pick the permission mode that puts the right amount of human review on a given workload
- Configure always_allow, always_ask and auto permission policies for Managed Agents tools
- Read evaluated_permission and reason_code to audit which calls a human reviewed
1.Why reviewing everything is not the safest setting
You might expect the safest design to ask a human about every action. Anthropic's experience with Claude Code suggests otherwise. By default, Claude Code asks before it runs commands or modifies files. Users approve 93% of those prompts, and over time they stop reading them closely. Anthropic calls this approval fatigue. A reviewer who clicks approve by reflex no longer provides validation.
So calibrating human-in-the-loop review is a design task: save the person's attention for the calls where it matters and settle the rest some other way. Claude Code and the Agent SDK do this with permission modes, each of which sets how much reaches a human.
| Mode | What runs without asking | Best for |
|---|---|---|
| default | Reads only | Reviewing every action yourself, sensitive work |
| acceptEdits | Reads, file edits, and common filesystem commands (mkdir, touch, mv, cp, etc.) | Iterating on code you're reviewing |
| plan | Reads, plus classifier-approved commands when auto mode is available | Exploring a codebase before changing it |
| auto | Everything, with background safety checks | Long tasks, reducing prompt fatigue |
| dontAsk | Reads and pre-approved tools; anything that would prompt is denied | Locked-down CI and scripts |
| bypassPermissions | Everything | Isolated containers and VMs only |
Auto mode takes a middle path. Model-based classifiers make the approval decision in place of a person, and Anthropic describes the transcript classifier as a substitute for a human approver. It aims to block dangerous actions the user did not intend and let the rest run without prompts.
2.What each mode does to the approval callback
For an Agent SDK builder, the practical question is whether a mode still sends calls to your canUseTool callback. In default, any call that needs approval and matches no allow rule goes to the callback. The Agent SDK starts in default, so the human gate is live unless you change the mode. plan sends file-edit and shell-write tools to the callback even when allow rules would approve them, so nothing gets written during planning without a person's approval. acceptEdits auto-approves file edits and common filesystem commands.
The two unattended modes take the human out in different ways. dontAsk denies anything that would have prompted, and never calls the callback. bypassPermissions approves nearly everything, and the docs reserve it for isolated containers and VMs. Some controls apply in every mode. Deny rules, explicit ask rules and hooks are checked before the mode and can still block a tool. A rule such as Bash(rm *) in disallowed_tools denies matching calls even under bypassPermissions. You can also change the mode during a session, for example with setPermissionMode("acceptEdits"), to loosen or tighten review as the task changes.
Nobody. In dontAsk, any call that would otherwise prompt is denied and canUseTool is never called. To get a human review, run in default mode, or pre-approve exactly the commands the job needs.
Sources3
3.Permission policies in Claude Managed Agents
Managed Agents express the same choice per tool through permission policies. always_allow runs the tool without confirmation. always_ask pauses the session until you approve. auto has the server evaluate each call. The agent toolset defaults to always_allow. MCP toolsets default to always_ask, so a tool newly added to an MCP server cannot run in your application without approval. Policies are set in the agent's tools configuration. Running sessions keep the configuration they were created with, so an update only applies to sessions created after it.
---
name: Coding Assistant
model: claude-opus-5-5
tools:
- type: agent_toolset_20260401
default_config:
permission_policy:
type: always_allow
configs:
- name: bash
permission_policy:
type: always_ask
---Custom tools are outside this system. Your application executes them, so any human checkpoint on a custom tool is one you build yourself.
A DevOps team runs a Claude agent unattended inside a CI pipeline to triage failing builds. No human is available to respond to interactive approval prompts during the run, so any tool call that isn't already pre-approved must be denied outright rather than left waiting on a prompt. Which permission mode configuration achieves this?
Correct answer: A — Set permissionMode to "dontAsk" and list the CI-safe tools in allowedTools, so listed calls run automatically and everything else is denied without ever reaching canUseTool.
- A. Correct. dontAsk converts any call not pre-approved by allowedTools, settings.json allow rules, or a hook into an outright denial and never calls canUseTool, which is exactly the unattended behavior the pipeline needs.
- B. Incorrect. Omitting a callback under default mode is not documented to resolve as an automatic denial; default mode expects canUseTool to be present to answer unmatched calls.
- C. Incorrect. acceptEdits only auto-approves file edits and specific filesystem commands; anything else still falls through to canUseTool rather than being denied, which would hang an unattended run.
- D. Incorrect. plan mode still runs read-only tools normally and routes file-edit or shell-write tools to canUseTool, so approval prompts are not eliminated and CI triage needing real tool calls would stall.
Sources4
4.Auto policy: when the human is still called, and how to audit it
Under auto, each call has one of three outcomes. If the server judges the call safe, it runs. If the server judges it high-risk, it is denied: the agent receives an error tool result, the session continues, and your client cannot override the denial. If the server cannot decide, the session pauses exactly as under always_ask and waits for a person. The human is the fallback for calls the server cannot settle.
Pay attention to whose words count as intent. Content in user.message events is treated as your intent, and it can get a call allowed. Tool results, fetched webpages and MCP responses are not. If you pass untrusted end-user text into user.message, the server treats it as your intent too. Put always_ask on any tool you would not let that end user run without review.
{
"type": "agent.tool_use",
"id": "sevt_01pqr...",
"name": "bash",
"input": {
"command": "rm -rf /workspace/reports"
},
"evaluated_permission": "deny",
"evaluation": {
"type": "auto",
"evaluated_permission": {
"type": "deny",
"reason_code": "high_risk"
}
},
"processed_at": "2026-03-25T14:05:12Z"
}Each tool-use event records evaluated_permission (allow, ask or deny) and usually an evaluation object naming the policy that produced it. That tells you, after the fact, which calls a human reviewed and which were settled automatically. Under auto, reason_code (indeterminate or high_risk) is meant for your client to branch on and store in audit records, not to show to end users. Write your client to tolerate values it does not recognise.
An engineering lead wants to use a Claude agent to investigate a suspected security vulnerability across a large codebase, but insists that no file be modified until she has personally reviewed and approved the exact diff Claude intends to make. Which configuration best matches this workflow?
Correct answer: A — Run the session with permissionMode "plan" so Claude can freely use read-only tools to investigate, while any file-edit or shell-write tool it proposes is routed to the canUseTool callback for her review, regardless of matching allow rules.
- A. Correct. plan mode lets Claude investigate freely with read-only tools while never auto-approving file edits, so every proposed change routes to her for review before anything is written, matching the requirement exactly.
- B. Incorrect. acceptEdits writes files immediately without a pre-write review step, which violates the requirement that no file change happen before her explicit approval.
- C. Incorrect. Manually deny-listing and unlisting every source path is impractical at scale and does not give per-diff review of the exact content of each proposed change.
- D. Incorrect claim. Deny rules are also evaluated before the permission-mode step, not just ask rules, so the statement misdescribes the evaluation order, and this setup is a needlessly risky way to reach the same outcome as plan mode.
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.dontAsk mode sends uncertain calls to a human through the canUseTool callback.Why is that wrong?
dontAsk denies every call that would otherwise prompt. The callback is never invoked, so only pre-approved calls run.
Covered in What each mode does to the approval callback
2.Setting always_ask on a Managed Agent puts a human gate on its custom tools as well.Why is that wrong?
Permission policies govern only server-executed tools. Your application runs custom tools, so it must supply their approval step.
Covered in Permission policies in Claude Managed Agents
3.Under the auto policy, a human reviewer can override any call the server denies.Why is that wrong?
A high-risk denial is final. Only calls where the server reaches no determination pause for human approval.
Covered in Auto policy: when the human is still called, and how to audit it
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://www.anthropic.com/engineering/claude-code-auto-modeSecondary source
“Manual prompts sit in the middle, and in practice users accept 93% of them anyway.”
↩︎ Why reviewing everything is not the safest setting“evaluates each action against a set of decision criteria before it executes, acting as a substitute for a human approver”
↩︎ Why reviewing everything is not the safest setting - 2.https://code.claude.com/docs/en/permission-modesOfficial docs
“Reviewing every action yourself, sensitive work”
↩︎ Why reviewing everything is not the safest setting - 3.
“calls that need approval and match no allow rule trigger your canUseTool callback”
↩︎ What each mode does to the approval callback“Claude explores and plans without editing your source files; file edits are never auto-approved and prompt through your canUseTool callback”
↩︎ What each mode does to the approval callback“Deny rules, explicit ask rules, and hooks are evaluated before the mode check and can still block a tool.”
↩︎ What each mode does to the approval callback“Calls matching rm * as written are denied in every permission mode, including bypassPermissions.”
↩︎ What each mode does to the approval callback“Any call that would otherwise prompt is denied.”
↩︎ Exam trap 1 - 4.
“The session pauses and waits for your approval before executing.”
↩︎ Permission policies in Claude Managed Agents“This ensures that new tools added to an MCP server do not execute in your application without approval.”
↩︎ Permission policies in Claude Managed Agents“Running sessions keep the toolset configuration they were created with.”
↩︎ Permission policies in Claude Managed Agents“When the server reaches no determination, the session pauses as it does under always_ask.”
↩︎ Auto policy: when the human is still called, and how to audit it“Configure always_ask on the tools you would not let that end user run without review.”
↩︎ Auto policy: when the human is still called, and how to audit it“A reason_code is a value for your client to branch on and keep in audit records, not text to display to end users.”
↩︎ Auto policy: when the human is still called, and how to audit it“Custom tools are executed by your application and controlled by you, so they are not governed by permission policies.”
↩︎ Exam trap 2“The session keeps running, and your client cannot override the denial.”
↩︎ Exam trap 3