The unsexy article. The one that decides whether Claude Code becomes infrastructure or becomes the story you tell during a postmortem.

Here is the rule you build everything else around:

That single rule clarifies 90% of the permission decisions. Everything else is operationalising it.

Reversibility, not "scariness"

Most teams configure allowlists by gut feel. "Tests feel safe; deletes feel scary." That is wrong.

Reframe around blast radius:

• Reversible: editing a file in your working tree, running tests, running pnpm install, creating a feature branch. If something breaks, git checkout/git stash saves you.
• Irreversible: git push, npm publish, DB migrations on prod, terraform apply, sending emails, charging cards, deleting cloud resources.

The first list should be on the agent's allowlist. The second list should require a human keystroke every time, no exceptions.

The minimal .claude/settings.json for a production repo

{
  "tools": {
    "shell": {
      "allow": [
        "pnpm test",
        "pnpm test:watch",
        "pnpm lint",
        "pnpm build",
        "pnpm db:migrate:dev",
        "pnpm db:reset:dev",
        "pnpm install",
        "git status",
        "git diff *",
        "git log *",
        "git stash *",
        "git checkout *",
        "git branch",
        "git add *",
        "git commit *",
        "ls *",
        "rg *",
        "cat *"
      ],
      "deny": [
        "git push *",
        "git rebase *",
        "git reset --hard *",
        "rm -rf *",
        "npm publish *",
        "pnpm publish *",
        "docker push *",
        "kubectl apply *",
        "terraform apply *",
        "aws *",
        "gcloud *",
        "psql -h prod*"
      ]
    }
  }
}

A few things to notice:

• git commit is allowed; git push is not. The agent can stage a change locally; you publish it.
• pnpm db:migrate:dev is allowed; the prod variant is not — and prod migrations should not be runnable from a dev machine anyway.
• aws * and gcloud * are blanket-denied. If you need a sub-agent that calls cloud APIs, give it a specific command, not the whole CLI.

The "files the agent must never edit" list

Even if you trust the agent, some files should require a human edit to change. Lock them in CLAUDE.md:

# Never modify
- /infra/terraform/   (humans only)
- /.github/workflows/release.yml
- /package.json "version" field
- Any file in /db/migrations/ that's already been applied
- /SECURITY.md

Claude Code respects CLAUDE.md instructions strongly. Combined with git diff review, this is enough for 99% of teams.

Sub-agent role separation = real defense in depth

We covered the 11 sub-agents in Article 5. The reason role separation matters for safety:

• code-reviewer cannot edit. So even if it "decides" something is fine, it cannot ship it.
• test-writer cannot touch production code. So a failing test is real evidence, not a flaky output.
• migration-runner can only run pnpm db:migrate. Even if compromised, the blast radius is one command.

That is real defense in depth — built out of constraint files, not security theatre.

Things you should not automate

A short list of "no, even if it works":

• Posting to public channels (Slack, Discord, Twitter). Latency is fine; an off-tone message in #engineering is not.
• Customer-facing emails. Generated content is fine in drafts. Sending is human.
• Money. Charges, refunds, payouts. Don't automate. Ever.
• Auth & identity. Adding a user, granting admin, rotating keys.
• Force pushes. Even on feature branches. The cost of an accidental force-push is too high.

The rule of thumb: if the worst-case cost is a postmortem, an apology email, or a regulator letter, keep a human keystroke between intent and execution.

Audit trail — the underrated feature

Every Claude Code session writes a transcript in ~/.claude/sessions/. On a team, ship those transcripts somewhere durable:

• A private S3 bucket.
• A Datadog log stream.
• A simple git log of .claude/transcripts/ committed to the repo.

You will not read them often. But the day you do — when something weird happened in the codebase and you need to know who/what changed it — they are gold.

A practical safety checklist

Before you let Claude Code run on a real codebase:

• .claude/settings.json has explicit allow and deny.
• CLAUDE.md has a "Never modify" section.
• .claude/agents/ includes at minimum code-reviewer and test-writer.
• git push is not in any allowlist.
• A teammate has reviewed the allowlist.
• You ran claude --dry-run (or the equivalent in your version) on a feature branch first.

Six items. Twenty minutes of work. Most production incidents come from skipping at least three of them.

---

Next article: Multi-Agent Pipelines — chaining sub-agents, running them in parallel, and the patterns for "review-while-coding" without losing your mind.