Set Claude Code Deny Ask and Allow Rules Before the First Edit

At a glance

• Turn the risky task into a short in-scope / out-of-scope checklist in Claude Desktop before any edit.
• In Claude Code, open `/permissions` and set explicit allow, ask, and deny rules while still in plan mode.
• Confirm deny wins, then leave plan mode only for the files and commands on that list.

A risky repo session fails in the first five minutes, not at the last commit. Claude Code can read files, run shell, and edit the tree as soon as the session starts. Claude Desktop is where you freeze the scope. Claude Code is where you enforce it. The checklist is not the fence. The allow, ask, and deny rules are.

Why it matters

Claude Code evaluates permission rules in a fixed order: deny, then ask, then allow. The first match wins. Specificity does not change that order, so a broad deny such as `Bash(aws )` blocks a narrower allow such as `Bash(aws s3 ls)`. User, shared-repo, and personal-repo settings all merge; if a tool is denied at any level, no other level can allow it. Write the scope in Claude Desktop, then copy only the fence into Claude Code. Do not edit while tools are still on product defaults.

{
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "ask": [
      "Bash(git commit *)",
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(curl:*)",

... click "Show full code" below to expand

{
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "ask": [
      "Bash(git commit *)",
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)"
    ]
  }
}

• Rules are enforced by Claude Code, not the model. A prompt that says you may edit `.env` does not override a deny.
• A bare Bash deny removes the tool from context; a scoped deny such as `Bash(curl:)` leaves Bash available and blocks matching calls.
• Bash patterns are prefix matches and can be bypassed. Keep dangerous verbs on deny or ask; do not treat an allow list as a sandbox.
• Compound commands split on `&&`, `||`, `;`, and `|`. An allow on the first half does not approve the second half.
• Skip `–dangerously-skip-permissions` and `bypassPermissions` on a risky repo. If checklist and `/permissions` disagree, the dialog wins.

Recommended AI prompt

Copy this paragraph into ChatGPT, Claude, Gemini, Grok, or whatever you use.

You are reviewing a Claude Code permission fence before any repo edits. I will paste my Claude Desktop scope checklist, the current `/permissions` list (with which settings.json file each rule came from), and `.claude/settings.local.json` or `~/.claude/settings.json` if I have it. Map every checklist item to an allow, ask, or deny rule using Tool or Tool(specifier) syntax. Flag gaps: readable secret files, allowed network tools, git push or cloud CLIs with no ask/deny, and allows that cannot override a broader deny. Restate evaluation order (deny, then ask, then allow; first match wins). Say whether the fence belongs in `.claude/settings.local.json` or `~/.claude/settings.json`. Give a plan-mode verification script in words, then return a rewritten settings.permissions block, a short pass/fail table, and the first sentence I should type in Claude Code after the fence is confirmed. Do not invent Claude Code features or URLs.