What you will be able to do
- Explain why an agent needs human checkpoints and where they fit in an agent loop
- Choose a Claude Code permission mode based on how much human review a task needs
- Use allow, ask and deny rules to decide which actions stop for a human
- Identify the actions that still require a human even in the most permissive modes
Key concept
Approval checkpoint — A point where the agent holds a proposed tool call until a human allows or denies it. Designing human-in-the-loop validation means deciding which actions reach a checkpoint and which run without one.
1.Why agents stop for a human
An agent differs from a single model call because it acts in a loop. It gets a task, plans, calls tools and reads the results, and it can keep doing this for many steps. Anthropic's guidance on building agents says that once the task is clear, agents operate independently, "potentially returning to the human for further information or judgement." It also names two moments when that return happens: agents "pause for human feedback at checkpoints or when encountering blockers."
So human-in-the-loop validation is not a single review at the end. It is a design decision about *which* steps an agent may take alone and which ones must wait for a person. In Claude Code, that decision is expressed through permission settings, which the documentation sums up as controls for "whether Claude asks before acting." Each tool call is either auto-approved, held at a prompt for a human, or refused outright. The rest of this page covers how you set that up.
Checkpoint 1 of 5· Check yourself
According to Anthropic's agent guidance, when does a well-designed agent return control to a human?
The guidance has agents pause for human feedback at checkpoints or at blockers, partway through the loop and not only at the end. Iteration limits are described separately, as stopping conditions that keep control.
“Agents can then pause for human feedback at checkpoints or when encountering blockers.”Source: www.anthropic.com
2.Permission modes: how much the human reviews
The permission mode sets how much reaches a human by default. Think of the modes as a dial. At one end is default, shown as Manual in the UI, which "Prompts for permission on first use of each tool." The documentation recommends it for reviewing every action yourself, for sensitive work and for unfamiliar code. plan keeps Claude to reading and exploring: "Claude Code blocks edits until you approve a plan", so the human checkpoint covers the whole plan rather than each edit. acceptEdits takes file edits out of the review loop when you are already reviewing the code as it changes.
Further along the dial, the human sees less and less. auto runs without routine prompts and relies on background safety checks. dontAsk never asks, and it denies anything that would have prompted. bypassPermissions runs everything and is meant for isolated containers and VMs only. Choosing a mode is a human-in-the-loop decision. Weigh how much harm an unreviewed action could do against how much prompt fatigue you can tolerate.
| Mode | What runs without asking | Best for |
|---|---|---|
| default | Reads only | Reviewing every action yourself, sensitive work |
| acceptEdits | Reads, file edits, and common filesystem commands | 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 |
Checkpoint 2 of 5· Match them up
Match each situation to the permission mode the documentation recommends for it
Tap a term, then the definition that fits it.
The less a person reviews, the more isolation the mode requires. default puts a human on every new tool, and bypassPermissions is limited to isolated environments.
“Prompts for permission on first use of each tool.”Source: code.claude.com
Checkpoint 3 of 5· Exam question
A fintech company's Claude-powered agent can initiate wire transfers through a custom MCP tool. Even though the operations team has configured allowedTools to auto-approve most read and reporting tools, they want every wire-transfer tool call to require a human's explicit approval no matter what permission mode the session is later switched to, including bypassPermissions. Which approach best satisfies this requirement?
Correct answer: A — Register a PreToolUse hook scoped to the wire-transfer tool that returns permissionDecision "ask" for every call, since hooks execute before deny rules, ask rules, the permission mode check, and allow rules, and their decision holds even under bypassPermissions.
- A. Correct. Hooks run first in the evaluation order and a PreToolUse hook's decision applies regardless of permission mode, including bypassPermissions, guaranteeing the prompt for this tool.
- B. Incorrect mechanism. A bare allow-rule entry auto-approves every matching call and the call never reaches canUseTool, so this design silently removes the intended approval step.
- C. Incorrect. acceptEdits only auto-approves file edits and specific filesystem commands; other tools still fall through to normal permission handling, which could still resolve via an existing allow rule rather than always prompting.
- D. Incorrect. Deny rules are evaluated before canUseTool in the flow, so the callback has no mechanism to reverse a deny decision for a specific call.
3.Allow, ask and deny rules, and what the human sends back
Modes set the baseline. Rules adjust it for individual tools and commands, so you can put checkpoints exactly where the risk is. There are three kinds of rule. Allow rules let a tool run without manual approval. Deny rules block it completely. Ask rules force a checkpoint: they "prompt for confirmation whenever Claude Code tries to use the specified tool." A rule can match a whole tool, such as Bash, or a specific call, such as Bash(npm run build).
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
"deny": [
"Bash(git push *)"
]
}
}A checkpoint can do more than say yes or no. At a prompt, the reviewer can attach a comment. If they choose Yes, Claude Code runs the action and then passes the comment to Claude. If they choose No with a comment, Claude Code "sends your comment to Claude as the reason for the denial, and Claude continues working", so the agent gets corrected and keeps going. If they choose No without a comment on a prompt from the main conversation, Claude Code stops the turn. The comment is how the human steers the agent instead of only blocking it.
Checkpoint 4 of 5· Check yourself
A reviewer rejects a prompt from the main conversation by selecting No and leaving the comment field empty. What does Claude Code do?
Without a comment, a No on a main-conversation prompt ends the turn. With a comment, Claude gets the comment as the reason for the denial and keeps working.
“If you select No without a comment on a prompt from the main conversation, Claude Code stops the turn.”Source: code.claude.com
Sources3
4.Checkpoints no setting removes
Some checkpoints are built in, so a permissive setting doesn't silently remove the human from high-stakes actions. Even bypassPermissions "Skips permission prompts, except for the actions no mode auto-approves." These include tools matched by an explicit ask rule, the built-in AskUserQuestion tool, MCP tools marked requiresUserInteraction, and "rm and rmdir removals targeting a critical path, which no allow rule or PreToolUse hook \"allow\" approves."
Manual mode adds more safeguards. Matching is fail-closed: "unmatched commands require approval by default." Command injection detection still asks about a suspicious bash command even if it was allowlisted before. The other half of the loop is the reviewer. The security guidance tells users to "Review suggested commands before approval", because a checkpoint is only useful if the person at it actually reads what they approve.
Checkpoint 5 of 5· Check yourself
A team sets an allow rule for Bash in Manual mode. Claude then proposes a bash command that looks like a command injection attempt. What happens?
Command injection detection overrides an earlier allowlisting in Manual mode, so the human gets the call back for review.
“Command injection detection: In Manual mode, suspicious bash commands require manual approval even if previously allowlisted”Source: code.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.bypassPermissions removes every human checkpoint, so nothing ever prompts.Why is that wrong?
Some actions are never auto-approved by any mode. Examples are explicit ask rules, AskUserQuestion, and rm/rmdir targeting a critical path.
Covered in Checkpoints no setting removes
2.dontAsk is a quieter version of asking, and calls that need approval are queued for a human later.Why is that wrong?
dontAsk denies anything that would prompt. AskUserQuestion and tools marked requiresUserInteraction are denied even if they are allowed.
Covered in Permission modes: how much the human reviews
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/permission-modesOfficial docs
“Control whether Claude asks before acting.”
↩︎ Why agents stop for a human“Claude Code blocks edits until you approve a plan”
↩︎ Permission modes: how much the human reviews“rm and rmdir removals targeting a critical path, which no allow rule or PreToolUse hook "allow" approves”
↩︎ Checkpoints no setting removes - 2.https://www.anthropic.com/engineering/building-effective-agentsSecondary source
“potentially returning to the human for further information or judgement”
↩︎ Why agents stop for a human“Agents can then pause for human feedback at checkpoints or when encountering blockers.”
↩︎ Why agents stop for a human - 3.https://code.claude.com/docs/en/permissionsOfficial docs
“Prompts for permission on first use of each tool.”
↩︎ Permission modes: how much the human reviews“Ask rules prompt for confirmation whenever Claude Code tries to use the specified tool.”
↩︎ Allow, ask and deny rules, and what the human sends back“No: Claude Code sends your comment to Claude as the reason for the denial, and Claude continues working.”
↩︎ Allow, ask and deny rules, and what the human sends back“Skips permission prompts, except for the actions no mode auto-approves”
↩︎ Exam trap 1“Auto-denies every call that would otherwise prompt”
↩︎ Exam trap 2“Auto-denies every call that would otherwise prompt”
↩︎ Prediction“If you select No without a comment on a prompt from the main conversation, Claude Code stops the turn.”
↩︎ Checkpoint - 4.https://code.claude.com/docs/en/securityOfficial docs
“Fail-closed matching: In Manual mode, unmatched commands require approval by default”
↩︎ Checkpoints no setting removes“Review suggested commands before approval”
↩︎ Checkpoints no setting removes“Command injection detection: In Manual mode, suspicious bash commands require manual approval even if previously allowlisted”
↩︎ Checkpoint
Also cited
“The session pauses and waits for your approval before executing.”
↩︎ Key concept