Claude Code — Part 7 — Permissions, settings.json, and Hooks

Introduction

Part 4 made a point of noting that CLAUDE.md is context, not enforcement. Claude reads it and tries to follow it, but nothing physically stops it from deciding otherwise on a bad day. This post covers the two mechanisms that do physically stop it: permission rules and hooks.

The Permission System

Every tool call Claude Code makes is checked against a set of rules before it runs. There are three outcomes: an allow rule lets it run without a prompt, an ask rule prompts you for confirmation, and a deny rule stops it outright. Rules are evaluated in that order, deny first, then ask, then allow, and the first match wins regardless of how specific a competing rule is.

Read-only actions like file reads need no approval within your working directory. Bash commands and file edits need approval by default, with edits generally auto-accepted for the rest of a session once you approve the first one.

Permission Rule Syntax

Rules follow the pattern Tool or Tool(specifier). A bare tool name matches every use of that tool. A specifier narrows it to specific commands, paths, or domains.

Wildcards can appear anywhere in a Bash pattern. Bash(* --version) matches any command ending in --version, and a single * can span multiple words, so Bash(git * main) matches both git checkout main and git merge main.

Where Rules Live: settings.json

Permission rules and hooks are configured in a settings.json file, at one of several scopes. Higher scopes win when the same rule appears in more than one place.

A minimal project settings file, denying access to secrets while allowing routine commands, looks like this:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Permission Modes

Beyond individual rules, a session-wide mode controls the general approval behaviour.

Hooks: Enforcement, Not Instruction

A hook is a shell command that fires at a fixed point in Claude Code’s lifecycle, such as before a tool runs or after a file edit completes. Unlike a CLAUDE.md instruction, a hook always runs. It does not depend on Claude choosing to comply.

PreToolUse hooks can inspect a tool call before it happens and block it outright. This example logs every Bash command to a file, then runs a script that denies anything matching a destructive pattern by exiting with status 2.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r .tool_input.command >> ~/.claude/bash.log"
          },
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-rm-rf.sh"
          }
        ]
      }
    ]
  }
}

block-rm-rf.sh receives the tool call as JSON on standard input, checks whether the command contains rm -rf, and exits with status 2 to deny it if so. Claude Code enforces that exit code regardless of what the model wanted to do. The same lifecycle mechanism applies whichever shell tool a session is using, so the same pattern covers a Windows-native session as much as a Bash one.

CLAUDE.md, Skills, Permissions, or Hooks?

By this point in the series it is worth pulling the four mechanisms together, since they solve genuinely different problems.

Final Thoughts

CLAUDE.md, Skills, permissions, and hooks are not competing ways to do the same thing. They sit at different levels of strictness, from a suggestion Claude tries to follow, to a wall it cannot cross regardless of what it decides. On a machine with real access to real infrastructure, that distinction is the whole point.

Most of what has gone wrong in this series so far has been “Claude did something I didn’t expect.” The next post covers what to do when something goes wrong at the tool level itself.