What you’ll be able to do
- Order permission settings correctly across enterprise, project, and user scope
- Design an allow/deny list that’s safe by default for a shared team setup
- Predict which setting wins when scopes disagree
What you need to know
Permissions resolve by precedence, not by averaging
Claude Code permission settings — which tools and commands are allowed, denied, or require approval — can be set at more than one scope: an organization-wide enterprise policy, a project's own settings, and an individual user's settings. When these disagree, they don't average out or merge loosely; they resolve by a defined precedence, with broader, more restrictive scopes generally able to set a floor that narrower scopes cannot loosen.
The architectural design principle follows directly: put the safe default at the top (enterprise or project level) and treat narrower scopes as places that can only tighten further, never as an escape hatch a user could set to bypass an organization's baseline.
Designing the allow/deny list itself
A permission list that's safe by default names specific dangerous operations to deny or gate behind approval, and leaves everyday development work unobstructed. The failure modes run in both directions:
- Too permissive — an allow list broad enough to auto-approve a destructive or irreversible command (deleting cloud resources, force-pushing, running arbitrary network requests) because it was scoped by category rather than by specific risk.
- Too restrictive — requiring approval for every routine action turns into a stream of confirmations people click through without reading, which defeats the purpose of having a gate at all.
The design target is: deny or gate the small set of genuinely irreversible or high-blast-radius actions specifically, and leave routine, reversible development work unblocked.
Verifying effective permissions, not just configured ones
Because settings compose across scopes, what a specific team member can actually do is the result of enterprise policy, their project's settings, and their own user settings resolved together — not any single file read in isolation. An architect designing a team rollout checks the effective permission set for a representative new team member, not just that each individual settings file looks correct on its own.
Key concept
Permission scopes resolve by precedence, with broader scopes able to set a floor narrower scopes can’t loosen. Design the safe default at the top; verify the effective result, not each file in isolation.
When a scenario asks which setting wins across enterprise, project, and user scope, the exam is testing precedence — not which file was edited most recently.
Practice scenario
Work it through, then open this
The user-level allow rule does not override the enterprise-level deny. Broader, more restrictive scopes set a floor that narrower scopes can tighten but not loosen — that’s the entire point of having an enterprise policy layer. The correct fix for a legitimate use case blocked by an overly broad enterprise rule is to narrow the enterprise rule itself (or add a scoped exception at that same level), not to route around it from a lower scope.
Build exercise — Trace effective permissions across scopes
Intermediate · 20 min
What you’ll learn
- Reading enterprise, project, and user settings together instead of in isolation
- Predicting which setting wins when two scopes disagree
- Spotting an allow list that’s broader than the risk it’s meant to gate
-
For a specific risky operation, find where it’s addressed at each scope (enterprise, project, user) and note whether they agree.
- Why: The effective permission is the resolved result across all three, not whichever one you looked at first.
- You should see: Either consistent policy across scopes, or a conflict worth resolving at the right level.
-
Check an allow list for any rule broad enough to also approve an operation more dangerous than the one it was written for.
- Why: A rule scoped by category rather than by specific command can auto-approve more than intended.
- You should see: Either a tightly scoped rule, or a broader one worth narrowing.
Exam traps
Assuming user-level settings can override an enterprise-level restriction
Broader scopes set a floor narrower scopes can’t loosen — a user-level allow rule doesn’t defeat an enterprise-level deny.
Setting permissions only at the project level and ignoring enterprise policy
The effective permission set is the resolved combination across all configured scopes, not whichever one was edited.
Writing an allow list so broad it approves risky operations by accident
Scope allow rules to the specific safe operation, not a broad category that happens to include it.
Not testing what a new team member’s effective permissions actually are
Each settings file can look correct in isolation while the resolved, effective result is wrong — verify the composed outcome.