How to Restrict Claude Code

Published May 11, 2026

If you need to understand how to restrict Claude Code in a way that survives prompt drift, the practical answer is to put policy outside the model. Prompt rules are easy to bypass accidentally, especially when an agent is asked to debug, refactor, or execute shell commands under time pressure. A better pattern is a wrapper that intercepts actions, applies explicit rules, and records what happened. That is the problem agentcheck is built to solve: it wraps each Claude process with hook-based guardrails, logs tool calls to JSONL, and applies YAML rule packs to constrain agent behavior.

Why Restrict Claude Code at the Process Level

Claude Code is useful precisely because it can take action. It can read files, write files, run commands, and sometimes interact with networked tools. Those capabilities are valuable, but they also create failure modes that are not theoretical:

• Agents modifying files outside the intended project scope
• Shell commands that are too broad, destructive, or expensive
• Silent tool usage that is hard to audit after the fact
• Policy enforcement living only in the system prompt

When people ask how to restrict Claude Code, they usually mean one of three things: reduce the command surface area, require review for risky actions, and capture evidence of what the agent actually did. Those are governance problems, not just prompting problems.

How to Restrict Claude Code with AgentCheck

AgentCheck works as a behavioral control layer. Instead of trusting the agent to always obey natural language instructions, you define rule packs in YAML and let the wrapper enforce them around each Claude process. You also get JSONL logs for tool-level visibility.

The basic flow is straightforward: install AgentCheck, define a rule pack that blocks or constrains risky tools, then launch Claude Code through the wrapper. A minimal setup might block dangerous shell patterns, limit write locations, and record every tool call for later review.

npm install -g github:paprika-org/agentcheck

# example rule pack
cat > rules.yaml <<'YAML'
version: 1
rules:
  - id: block-destructive-shell
    match:
      tool: shell
      command_regex: '(^|\\s)(rm\\s+-rf|sudo|mkfs|dd\\s+if=)'
    action: deny

  - id: restrict-write-scope
    match:
      tool: write_file
      path_regex: '^/workspace/project/(src|docs)/'
    action: allow

  - id: deny-write-outside-scope
    match:
      tool: write_file
    action: deny

  - id: log-everything
    match:
      tool: '.*'
    action: log
YAML

agentcheck --rules ./rules.yaml -- claude

The exact CLI shape can evolve, so check the repository for current usage, but the model is stable: wrap the agent process, match tool events, and allow, deny, or log based on policy. This is a much stronger answer to how to restrict Claude Code than adding another paragraph to a system prompt.

What Good Rule Packs Look Like

Start narrow. Most teams make the mistake of writing one giant policy before they know what the agent actually does in daily work. A better approach is to log first, identify the real tool usage patterns, and then tighten rules around the top risks.

Useful first rules usually include:

• Write restrictions to specific directories such as src/ and docs/
• Shell denies for destructive commands and privilege escalation
• Review gates for package manager changes, migrations, or deployment scripts
• Logging requirements for every tool call, including denied actions

This approach also keeps policies reviewable in version control. A YAML rule pack is easier to diff, test, and discuss than a pile of hidden prompt instructions spread across local setups.

Honest Limitations and Security Boundaries

AgentCheck is a governance layer, not a full sandbox. That distinction matters. If the underlying runtime can still access the network or the filesystem, your hard boundary comes from the operating system, container runtime, CI permissions, or repository ACLs. AgentCheck improves control and auditability, but it should not be described as a substitute for system isolation.

There are also practical limits around tool visibility. Enforcement is strongest when the action passes through a hook the wrapper can observe. If a workflow invokes side effects outside that path, you need another control. The right design for sensitive environments is layered:

• OS or container isolation for hard boundaries
• AgentCheck for behavioral policy and logging
• Repository and secret management for least privilege

That is the technically honest answer to how to restrict Claude Code without overselling what any single tool can guarantee.

Common Mistakes

Mistake 1: relying on deny rules without testing normal workflows. If your rule pack blocks too broadly, developers will route around it. Start by logging, then add targeted denies for verified high-risk patterns. Restrictions only work if the allowed path remains usable.

Mistake 2: treating logs as optional. Without JSONL logs, you lose the ability to answer basic questions after an incident: which tool was invoked, with what arguments, and which rule allowed it. Logging is part of enforcement because it creates accountability and supports rule tuning.

Mistake 3: assuming prompt instructions are equivalent to policy. They are not. The point of an external rule pack is that it remains stable even when the conversation changes.

Frequently Asked Questions

Does AgentCheck sandbox Claude Code by itself?

No. AgentCheck is a governance layer around Claude Code. It enforces hook-based rules and logs actions, but it does not replace OS sandboxing, container isolation, or repository permissions.

Can I restrict network access with AgentCheck?

You can block or require approval for tool calls that would reach the network if those calls are visible to the hook layer. For hard guarantees, combine AgentCheck with firewall rules, containers, or CI isolation.

Why use YAML rule packs instead of prompt instructions alone?

Prompt instructions are advisory. YAML rule packs are external policy definitions that can be versioned, reviewed, and enforced consistently across sessions, which is better for repeatability and auditability.

What do the JSONL logs help with?

JSONL logs give you a machine-readable history of tool calls and policy decisions. That is useful for incident review, compliance evidence, regression testing, and understanding how an agent behaved over time.