Claude Code Permissions & Settings Precedence (CCA-F Guide)

An agent that can edit files and run shell commands is useful and, unmanaged, a little terrifying. Claude Code's permission system is the layer that makes autonomy safe: it decides which actions run freely, which pause for your approval, and which are forbidden outright. The CCA-F exam treats this as core Configuration & Workflows material, and it is one of the least-competitive topics to rank for because most write-ups skip it. This guide covers the rules, the precedence order, and the scenarios the exam builds on them.

The Three Verdicts: Allow, Ask, Deny

Every action an agent attempts is resolved against permission rules into one of three outcomes:

• allow: the action runs without interruption
• ask: the agent pauses and requests your approval before proceeding
• deny: the action is blocked outright, no prompt

Rules target tools and can be scoped narrowly. Bash(npm run test:*) allows a family of test commands; Read(./.env) can be denied to keep secrets out of context; Edit(./src/**) can be allowed while writes elsewhere still ask. The specificity is the point: you grant fast paths for the safe, common actions and reserve friction for the consequential ones.

The mental split versus hooks (covered in the hooks guide): permission rules are declarative allow/ask/deny lists the system evaluates; a PreToolUse hook is a program that can apply arbitrary logic and block with feedback. Use rules for "these commands are fine, these are forbidden"; reach for a hook when the decision needs conditions a static rule cannot express.

Settings Precedence: Who Wins

Permission rules (and every other setting) come from several files, and the exam's hardest Configuration questions turn on which one wins. The precedence, strongest first:

1. Enterprise managed policy (organization-deployed): overrides everything, non-negotiable
2. Command-line flags for the current invocation
3. Local project settings (.claude/settings.local.json, your personal per-project file, gitignored)
4. Shared project settings (.claude/settings.json, committed to the repo)
5. User settings (~/.claude/settings.json, your global defaults)

More specific and higher-authority sources override broader ones. Two consequences the exam tests:

• A deny in enterprise policy cannot be undone by a project or user setting. Security boundaries set by the org hold no matter what a repo's config says.
• Shared vs local project settings is the collaboration distinction: settings.json is committed so the whole team inherits it; settings.local.json is your personal overrides that stay out of git. Putting a personal convenience allow-rule in the shared file (and pushing it) is the kind of mistake a scenario question is built around.

Permission Modes

Beyond individual rules, Claude Code runs in a permission mode that sets the baseline posture:

Mode and rules compose: even in a permissive mode, a deny rule still blocks. Plan mode is a frequent exam answer for "how do you let the agent investigate a sensitive system without risking changes" because it removes the capability rather than trusting the agent to abstain.

The Security Scenarios the Exam Builds

Representative shapes, all resolvable from the rules above:

• "The agent must never read .env or secrets/." A deny on those paths; the safest place is enterprise or shared project settings so it is not one careless local override away from disappearing.
• "Let the agent run tests freely but confirm before installs." allow the test command family, ask on npm install.
• "A junior wants to loosen a security rule the company set." They cannot; enterprise policy outranks project and user settings. This is the exam testing whether you know the precedence direction.
• "Investigate a production incident with zero risk of mutation." Plan mode: capability removed, not merely discouraged.
• "Autonomous CI job editing files unattended." Auto-accept or bypass, but only because it runs sandboxed; the same setting on a dev laptop is the wrong answer.

The through-line the exam rewards: security is layered. Untrusted content can prompt-inject an agent's reasoning, but it cannot rewrite a deny rule or forge an enterprise policy. Hard boundaries belong in the permission and hook layers, not in advisory prose that a clever injection can talk around. This is the same principle the context and reliability material builds on.

Key Takeaways

• Every action resolves to allow, ask, or deny; scope rules narrowly to tools and paths
• Precedence, strongest first: enterprise policy > CLI flags > local project > shared project > user settings
• Enterprise deny rules are absolute; project and user configs cannot override org security
• settings.json (shared, committed) vs settings.local.json (personal, gitignored) is the team-vs-you split
• Permission modes set the baseline; plan mode removes edit capability entirely for safe investigation
• Hard boundaries live in permissions and hooks, never in advisory instructions

The Claude Code course makes you the permission system in a Level 5 interactive resolver, and Preporato's CCA-F practice tests drill precedence and permission scenarios across 390 explained questions.

Frequently asked questions

Sources:

• Claude Code Documentation: Settings
• Claude Code Documentation: IAM & Permissions
• Anthropic Academy

Last updated: July 10, 2026