/guard — Block dangerous commands

AI agents make mistakes. Guard catches them.

How it works

/guard installs a PreToolUse hook that intercepts every shell command before execution. The hook checks the command against a set of block rules and either allows it, blocks it with an alternative, or warns and asks for confirmation.

/guard

Guard activated. 33 block rules, 9 warn rules loaded.
Mode: careful (warn on matches, block on critical)

The hook runs in the agent's process. No daemon, no background service. It only activates when you say /guard and deactivates when the session ends or you turn it off.

Four tiers of protection

Tier 1: Allowlist

Commands on the allowlist pass through without inspection. This covers everyday operations like git status, ls, cat, and npm test. The allowlist is intentionally short. If a command is not on the list, it goes to the next tier.

Tier 2: In-project check

Commands that modify files are checked against the project boundary. If an agent tries to write to /etc/hosts or ~/.ssh/, that is blocked regardless of what the command does. Writes must target the project directory or /tmp.

Tier 3: Phase-aware rules

Some commands are fine in one phase but dangerous in another. Running npm publish during the build phase is blocked. During /ship, it is allowed (if your config enables it). The hook knows which phase is active from the sprint state.

Tier 4: Pattern matching

The 33 block rules and 9 warn rules use pattern matching against the full command string. This catches things like rm -rf /, git push --force, chmod 777, and curl | bash regardless of context.

Example flow

Agent: Running "rm -rf node_modules dist build"

Guard: BLOCKED (G-001: Mass deletion pattern)
  Matched: rm -rf with multiple targets
  Alternative: rm -rf node_modules && rm -rf dist && rm -rf build
  Reason: Individual deletions are easier to audit and recover from.

Agent: Retrying with individual deletions...
  Running "rm -rf node_modules" ✓
  Running "rm -rf dist" ✓
  Running "rm -rf build" ✓

The agent receives the block reason and the suggested alternative. Most agents will retry automatically with the safer version.

Deny and continue

When a command is blocked, the agent does not stop the sprint. It receives a structured response with the denial reason and proceeds with its next action. If the blocked command was critical to the task, the agent will report that it could not complete the step and explain why.

This is different from a crash. The sprint stays intact, artifacts are preserved, and the agent can still complete other phases.

Activate and deactivate

/guard              # activate with default rules
/guard --careful    # warn mode (asks before blocking)
/guard off          # deactivate

Guard state does not persist between sessions. Start each session with /guard if you want protection active.