Claude Code Permissions: Safe Defaults for Shell and Files

Claude Code with full permissions is a brilliant intern with root access and no sense of self-preservation: extraordinarily capable, occasionally catastrophic. Permissions are how you keep the brilliance while bounding the blast radius — allow-lists for the routine, approval gates for the dangerous, and defaults that fail safe rather than convenient. This guide sets up permission tiers that match real projects, explains which gates must never open, and shows how teams share and evolve guardrails without slowing development to a crawl.

Safe defaults that stay usable

Start every project restrictive: read-only exploration everywhere, writes scoped to the working tree, shell execution behind approval gates, destructive operations requiring explicit confirmation always. This feels slow for exactly one afternoon; then muscle memory adapts and the gates become invisible on safe work while catching the dangerous moments that justify everything.

Defaults must fail safe, not convenient: unknown operations ask, destructive ones confirm twice conceptually, irreversible ones never auto-approve regardless of trust accumulated. The asymmetry is deliberate — a thousand unnecessary approvals cost less than one unreviewed recursive delete. Calibrate from this baseline outward with evidence, never inward from full access with hope.

• Read-only exploration by default
• Scoped writes, gated shell
• Destructive ops always gated
• Fail safe, never convenient

Expand permissions with evidence

Loosen gates only from proven patterns: commands run safely dozens of times earn allow-listing; novel operations keep their gates. Each removed gate should have a written reason — what was observed, over what period, with what blast radius. Evidence-based expansion preserves safety while removing friction exactly where friction proved pointless.

Never pre-approve destructive categories no matter how trusted the workflow feels. Deletes, force pushes, mass rewrites and external side effects keep human confirmation permanently; speed here is not worth any price. Impatience is the only argument for removing these gates, and impatience is never a security argument. The teams with the smoothest agent operations maintain the strictest destruction gates — correlation that surprises only newcomers.

• Allow-list from proven patterns
• Never pre-approve destruction
• Evidence per removed gate
• Impatience is not a reason

Teams share guardrails

Version-control permission configurations so every team member inherits identical guardrails automatically. Review permission diffs in code review with security-sensitive scrutiny — a widened allow-list deserves the same attention as a firewall rule change. Consistency across the team beats individual optimization; one developer's convenient exception becomes everyone's incident vector.

Onboard new members onto the standard configuration, not personal improvisations. Document why each gate exists with incident references where available; reasons survive personnel changes, bare rules do not. Centralize learning: every near-miss updates the shared config, so the whole team benefits from each individual's scare. Guardrails as team infrastructure compound safety the way shared libraries compound velocity.

• Shared configs versioned
• Permission diffs reviewed
• Identical guardrails for all
• Consistency over heroics

Audit and evolve

Audit permissions quarterly at minimum and after every incident without exception: which approvals fired, which were bypassed or rubber-stamped, what nearly escaped. Approval telemetry reveals gate fatigue — blanket approvals signal gates needing redesign, not removal. Near-misses deserve full post-mortems; they are free lessons about the next real attempt, which will resemble them closely.

Tighten from evidence continuously: patterns that proved safe earn allow-listing, patterns that surprised earn gates. The configuration should visibly evolve — a static permission file is either perfect (unlikely) or unreviewed (likely). Treat permission evolution as security hygiene with the same cadence as dependency updates: unglamorous, regular, and the reason disasters stay hypothetical.

• Quarterly audits always
• Approval and bypass telemetry
• Near-misses as free lessons
• Tighten from evidence

Think in blast radius

Evaluate every permission by blast radius: what is the worst outcome of misuse, mistake or prompt injection through this gate? Size controls proportionally — read access gets latitude, shell gets gates, destruction gets ceremony. This single mental model resolves nearly every permission debate faster than rule lists: imagine the worst case, price it, gate accordingly.

Combine permissions with sandboxing and recovery plans rather than relying on any single layer. Gates prevent, sandboxes contain, backups resurrect — defense in depth for agent operations. Maintain tested recovery for the working tree and critical data independent of agent tooling. Paranoia should scale with the power granted; brilliant interns with root access deserve brilliant oversight to match.

• Blast radius thinking always
• Recovery plans before permissions
• Sandbox plus gates combined
• Paranoia proportional to power

Frequently asked questions

What are safe permission defaults?

Read-only exploration and scoped writes by default, approvals for shell execution and destructive operations, explicit allow-lists for trusted commands. Convenience grows with trust; destructive power never defaults on.

How permissive should a new project be?

Start restrictive with approval gates everywhere, then allow-list specific commands as patterns prove safe. Expand permissions from evidence, never from impatience — each gate removed should have a reason written down.

Should destructive actions ever auto-approve?

Yes. Destructive operations (deletes, force pushes, mass rewrites) always require explicit approval regardless of trust level. Speed never justifies unreviewed destruction; the one disaster outweighs years of saved seconds.

How do teams share permission setups?

Version-control the configuration so the whole team inherits identical guardrails. Review permission diffs in code review like any security-sensitive change. Consistency beats individual heroics for safety.

How do permissions evolve over time?

Audit quarterly and after every incident: which approvals fired, which were bypassed, what nearly escaped. Tighten from evidence, and treat each near-miss as a free lesson about the next real attempt.

Related guides

• API Key Management for Teams: Rotation, Scopes and Offboarding
• Best AI coding tools 2026: an honest shortlist

Last updated: 2026-09-28