Permission denials

Permission rules decide what Claude Code may read, edit, and run (Bash, MCP tools, and more). Deny rules are a useful built-in-tool boundary, but they do not make files universally invisible to arbitrary subprocesses.

Official references: Permissions and Settings.

Deny sensitive paths

The same Read(./.env) style rules introduced under Protecting secret files scale to sensitive paths:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./**/id_rsa)",
      "Read(./secrets/**)"
    ]
  }
}

Use project .claude/settings.json for rules the whole team should share; use .claude/settings.local.json for personal experiments. Managed policy can enforce org-wide denies (see managed settings).

id_rsa.pub is a public key, so it is not included unless hiding host or user metadata is an explicit policy. Avoid Read(./.env.*) if .env.example must remain readable; deny rules do not support a negated exception.

Deny vs allow vs ask

• deny blocks matching operations before they run.
• allow can pre-approve safe patterns (narrower is better).
• ask prompts you when a tool use matches; useful for commands that are sometimes safe and sometimes not.

Combine them so routine work is smooth but high-risk paths and commands still surface a human decision.

Execution hygiene

• Prefer Plan mode when exploring unfamiliar or sensitive areas so analysis stays read-only until you approve edits.
• Avoid bypass modes unless you understand exactly what you are unlocking.
• Re-read Understanding Security with AI agents for vulnerability classes that permission rules do not fix on their own (logic bugs, authz, etc.).

Example prompt

We are bootstrapping Claude Code on a new Node + Postgres API repo. Propose a starter `permissions.deny` block in JSON: block reading .env and common key paths, and block broad destructive Bash patterns you would expect on day one. Keep allows out of this answer, I only want the deny array content.

Related