How to Enforce Claude Code Rules With Hooks and Permission Settings

When you use Claude Code in a project, a CLAUDE.md file gives it ongoing instructions, covering coding conventions and preferred commands, along with notes about the codebase. These instructions guide Claude’s choices, but they do not control which actions Claude Code permits. To block an action, add a rule to Claude Code’s permission settings or enforce it with a hook, a user-defined command that runs at a specific point in Claude Code’s activity.

Set permission settings to allow or deny tool actions, or require approval. Use a pre-tool hook when a deterministic check must run before an action, and keep CLAUDE.md for context and guidance. This division makes restrictions more reliable without discarding useful project instructions.

Put blocking rules in permission settings

Claude Code permissions decide whether Claude Code can use a tool, must ask for approval, or must stop. The three rule types are allow, ask, and deny. Claude Code checks them in order of priority. A matching deny rule wins over an ask or allow rule, even if the allow rule is more specific. The permissions documentation describes how the rules work.

For example, a project could allow its lint and test commands. It could ask before a Git push and deny reads of environment files:

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

These patterns show one policy, but they do not cover every way Claude Code could perform those actions. Permission rules match specific tools and actions, so test them against the commands and paths your project uses. A rule for a Bash command does not automatically control other tools that could affect the same files or resources.

To share project rules, put them in .claude/settings.json and commit the file. User-level settings go in ~/.claude/settings.json, while personal project settings belong in .claude/settings.local.json. Anthropic’s settings documentation also describes organization-managed settings and how settings differ across environments. Claude Code applies allow rules in shared project settings only after a user trusts the folder. It applies deny and ask rules immediately.

Use a pre-tool hook when a check must run first

A hook is a command or other handler that runs at a defined point in Claude Code’s activity. A PreToolUse hook runs before Claude Code calls a tool. It can allow, deny, or ask about the call, so use it when a rule must be checked before Claude Code acts. A PostToolUse hook runs after the tool finishes. It can trigger tests or formatting, but it cannot undo an edit that has already happened. The hooks reference describes the available events and outcomes.

This example registers a command to inspect Bash calls before they run:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 .claude/hooks/check-command.py"
          }
        ]
      }
    ]
  }
}

This registration tells Claude Code when to run the checker. The script must read the hook input, the data Claude Code passes to it, and decide whether to allow, deny, or ask about the call. For a command hook, exit code 2 blocks a PreToolUse call. The same exit code from PostToolUse does not reverse the completed action; it reports information to Claude instead.

A quick text match is not a complete Bash security check. Shell commands can combine commands or run them through wrappers, so a simple substring check may miss them. Keep the policy narrow, test both blocked and allowed examples, and check that the hook covers the tool calls you intend to control.

Keep instructions in CLAUDE.md

A CLAUDE.md file remains useful for explaining project conventions and the reasons behind them. It can tell Claude which test command developers prefer, how the codebase is organized, or which patterns to follow. But Claude Code treats the file as context, not as enforced configuration. Anthropic’s project memory documentation recommends permission rules or a PreToolUse hook when an action must be blocked.

Put “Run the project’s tests before proposing a change” in CLAUDE.md. Use permissions or hooks for rules such as “deny access to these files” or “require approval before this matching command runs.” Guidance helps Claude choose an approach; enforcement controls whether a matching action proceeds.

Treat hooks as code with user-level access

A command hook runs with the current user’s permissions. It can access, change, or delete files the current user can access, so a careless hook creates its own risk. Review hook commands before adding them, and keep scripts small and version-controlled. Test behavior in three cases: the check passes, the check fails, or it times out. Decide explicitly whether a failed check should block the tool call or allow it to continue.

Permissions and hooks do not replace operating-system isolation. A permission rule controls which tool actions Claude Code authorizes, while a sandbox limits what a running process can access. Anthropic warns that an approved Bash command can write outside Claude Code’s working directory as the user. For stronger boundaries, pair Claude Code controls with sandboxing to limit what a running process can access. Use relevant infrastructure or CI checks as additional safeguards, as described in the security guidance.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com