Copybook中文Search

Settingsconfig

Claude Code permissions: deny, ask and allow

Claude deleted a config that ‘looked unused’: risky commands blocked, pushes ask first, routine ones run, deny always wins.

662 saves on X, as of Posted

.claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(*--force*)",
      "Edit(.env*)",
      "Edit(*.pem)"
    ],
    "ask": [
      "Bash(git push*)",
      "Bash(npm publish*)",
      "Edit(src/config/*)"
    ],
    "allow": [
      "Bash(npm run*)",
      "Bash(git commit*)",
      "Bash(git add*)",
      "Read(**)"
    ]
  }
}

Next Put it in .claude/settings.json in your project, then edit the lists to fit it.

One day, Claude was fixing a bug and casually deleted a config file that “looked unused.” That file was the secret key reference entry for the production environment.

I spent half an hour configuring .claude/settings.json after that.

Priority: deny > ask > allow. Deny is highest. If a command matches deny, it won’t execute even if allow also matches.

Array-valued settings like permission lists merge across scopes rather than replacing each other. So a deny rule at the user level (~/.claude/settings.json) and another at the project level (.claude/settings.json) both apply.

I deny business risks at the project level, like deleting migrations. I deny safety baselines at the global level, like executing rm -rf. Two layers, maintained independently.