AnthropicClaude Certified Architect – Foundations2026-100 Prerequisites
Check availability before approving tool use
Completed by the knowledge check
Learning objective
Distinguish available, pre-approved, and denied tools and identify when human approval is required
Core idea
Ask two questions about any tool: can Claude request it, and may this particular call execute? Availability answers the first, permissions the second. An available tool can still need a person’s confirmation, and a pre-approval rule still loses to an explicit denial. Claude Code enforces both outside the model: an instruction in a prompt or CLAUDE.md changes what Claude asks for, not what it is allowed to do.
How it works
Available
The --tools flag restricts which built-in tools exist for a session: --tools "Bash,Edit,Read" selects three, and --tools "" disables them all. It does not affect MCP tools; the CLI reference points to --disallowedTools "mcp__*" to deny those too. A deny rule that names a bare tool, such as Bash, also removes it from Claude’s context entirely.
Pre-approved
--allowedTools (also --allowed-tools) lists tools that execute without prompting. It does not restrict the session to those tools — the CLI reference sends you to --tools for that. A rule can be scoped: Bash(git diff *) pre-approves matching commands, not every shell operation. The persistent equivalents are permissions.allow, permissions.ask and permissions.deny in settings. A skill’s allowed-tools frontmatter is likewise a grant, not a restriction; 3.2.5 owns that case.
Denied
A scoped deny such as Bash(rm *) leaves Bash available and blocks matching calls. Rules are evaluated in order — deny, then ask, then allow — and the first match decides; specificity does not change the order. If a tool is denied at any level, no other level can allow it: a managed deny cannot be overridden by --allowedTools. Deny rules block in every permission mode, including bypassPermissions.
Human approval
A call that no rule or mode resolves reaches a person. In an interactive session that is the permission prompt. In the Agent SDK it is your permission callback, canUseTool in TypeScript or can_use_tool in Python, which also receives Claude’s clarifying questions as AskUserQuestion calls. The callback never fires for a call already approved by an allow rule or a mode such as acceptEdits, so pre-approval removes the person from that call. In dontAsk mode Claude Code auto-denies every call that would otherwise prompt: no prompt means refused, not approved.
Separating these gates from business-policy checks in code, and testing that a prohibited call never executes, is taught in 1.5.3; the permission flags and modes for an unattended CI job in 3.6.1.
Key distinctions and trade-offs
| Gate | Mechanism | Effect |
|---|---|---|
| Available | --tools, bare-tool deny | Whether Claude can request the tool at all |
| Pre-approved | --allowedTools, permissions.allow | Matching calls run without a prompt |
| Ask | permissions.ask | Matching calls need confirmation, even if an allow also matches |
| Denied | permissions.deny, --disallowedTools | Matching calls never run, in any mode |
Rules are evaluated deny, then ask, then allow, and a call that would prompt reaches a person unless the mode is dontAsk.
Narrow pre-approval removes repeated prompts for a known operation; broad pre-approval removes the person from more calls than you may intend.
Architecture / decision scenario
A review workflow exposes Read, Edit and Bash, pre-approves Bash(git diff *), asks for Bash(git push *) and denies Bash(rm *); its MCP tools are reviewed separately because --tools does not cover them. Interactively, a diff runs without a prompt, a push reaches the reviewer, and a removal is blocked. Run unattended in dontAsk, the push is denied rather than silently approved, so publishing waits for a run with an approval path. A personal allow for rm cannot reopen what the project denies.
Common exam traps
- Reading
--allowedToolsas the list of the only available tools. - Assuming
--toolsalso restricts MCP tools. - Treating a narrower allow as an exception to a broad deny.
- Treating
dontAskas approval of unresolved calls. - Assuming
bypassPermissionsoverrides a deny rule. - Treating a prompt instruction as a permission rule.
What to remember
Availability, pre-approval, denial and human approval are four gates. Use --tools for exposure and permission rules for calls; deny beats ask, ask beats allow, and a deny at any level stands.
Knowledge check
An unattended review job must leave Read as the only built-in tool Claude can request. Which flag does that?
--tools "Read"--allowedTools "Read"--permission-mode dontAsk--disallowedTools "mcp__*"--tools restricts which built-in tools exist in the session. --allowedTools only pre-approves calls; unlisted tools stay available and go through the permission flow. dontAsk refuses unresolved calls without hiding any tool, and denying mcp__* covers MCP tools, which --tools does not — a separate concern from the built-in set.Project settings deny Bash(rm *). A developer adds a personal allow rule for the narrower Bash(rm -rf build/*). What happens when Claude runs rm -rf build/cache?
bypassPermissionsbypassPermissions .A job runs in dontAsk mode. Its settings hold an ask rule for Bash(git push *) and no allow rule that matches. Claude tries git push origin main. What happens?
dontAsk auto-denies every call that would otherwise prompt. With no approval path, the absence of a prompt is a refusal, never an approval, so publishing must wait for a run that has one.An Agent SDK application routes approvals to a person through its canUseTool callback. For convenience it also sets allowedTools: ["Bash"]. Reviewers see a routine shell command run with no approval request. No ask or deny rule matches, and the active mode permits pre-approval. What explains it?
AskUserQuestion callsallowedTools disables the callback for the whole sessionbypassPermissions modeReferences
- Anthropic, CLI reference
- Anthropic, Configure permissions
- Anthropic, Choose a permission mode
- Anthropic, Handle approvals and user input