Try a permission rule before you write a mod

What this step is for

Before you write a guard as a mod, try the cheapest rung that holds. We climb this ladder for every problem, and stop at the first rung that works:

1. A permission rule in settings.json: one line, no code, checked before anything runs.
2. A fix to the skill that keeps doing the wrong thing.
3. A settings hook: a shell script on an event.
4. A mod: only when you need to ask a question, keep state, or draw.

Our 11 scheduled vault runs hit 48 permission denials, about 5 a run. An allow list on the run fixed all of them, with no mod and no code (measured from our own transcripts, 2026-10-06). Then seven deny rules covered every foot-gun we had written down.

Do it

Three facts about rules decide whether yours works:

• Deny beats ask, and ask beats allow. A deny rule holds even when a broader allow rule, or a mode, would let the call through.
• The pattern form is a space and a star: Bash(git log *). The older :* form only works at the very end of a pattern.
• A compound command must match in every part. cd app && npm test is checked as two commands.

Open your user settings, ~/.claude/settings.json, and add a permissions.deny list. These are our seven, each one a mistake we made at least once:

{
  "permissions": {
    "deny": [
      "Bash(bunx tsc *)",
      "Bash(bunx eslint *)",
      "Bash(pkill -f *)",
      "Bash(archon complete *--force*)",
      "Read(~/.claude/.credentials.json)",
      "Read(~/.vercel/**)",
      "Read(~/.local/share/com.vercel.cli/**)"
    ]
  }
}

Why each one:

Rule	What went wrong
bunx tsc	in our Bun workspace it re-resolved the dependencies, rewrote the lockfile and left node_modules without react, next or payload
bunx eslint	our apps pin eslint 9; bunx silently fetched eslint 10 and reported against the wrong rules
pkill -f	the Bash tool runs each command inside bash -c '…', so the pattern also matched that wrapper and the command killed itself halfway
archon complete --force	archon complete deletes a finished branch and its worktree, and refuses a branch that was never pushed; --force skips that check
the three Read rules	credential files: printing one with its token field masked still leaked the refresh token beside it (2026-10-05)

Keep the ones that fit your machine and write your own the same way: one rule per mistake you have actually made.

Check it

Ask a headless session to run a denied command while you allow everything else:

claude -p "Run exactly: bunx tsc --version" --allowedTools "Bash(bunx *)"

Claude reports that it could not run the command: the deny rule held even though Bash(bunx *) was allowed. Run /status in an interactive session: the setting sources list includes your user settings.