command-guard

$npx mdskill add JKHeadley/instar/command-guard

Prevent destructive commands by blocking dangerous operations before they execute

  • Ensures that irreversible deletions and Git history destruction are prevented.
  • Depends on Claude Code's built-in hook system for intercepting shell commands.
  • Decides what to block based on a predefined list of risky operations.
  • Delivers results by automatically blocking dangerous commands before they run.

SKILL.md

.github/skills/command-guardView on GitHub ↗
---
name: command-guard
description: Set up a PreToolUse hook in .claude/settings.json that blocks dangerous commands — rm -rf, force push, database drops, and others — before they execute. Teaches the pattern of safety hooks for any Claude Code project. Trigger words: safety, guard, block dangerous, protect, prevent destructive, safe mode, dangerous commands, risky operations.
license: MIT
metadata:
  author: sagemindai
  version: "1.0"
  homepage: https://instar.sh
---

# command-guard — Block Dangerous Commands Before They Execute

Claude Code runs shell commands, edits files, and manages infrastructure with real consequences. Without guardrails, a misunderstood instruction or a hallucinated flag can delete data, corrupt history, or expose credentials. This skill installs a PreToolUse hook that blocks the most dangerous operations before they run.

No external tools required — this uses Claude Code's built-in hook system.

---

## What Gets Blocked

The guard intercepts `Bash` tool calls and checks the command against a blocklist before execution. By default it blocks:

**Irreversible deletions**
- `rm -rf` on non-temporary paths
- `git clean -f` (untracked file deletion)

**Git history destruction**
- `git push --force` / `git push -f` (without explicit user confirmation)
- `git reset --hard` on shared branches
- `git rebase` on pushed branches

**Database operations**
- `DROP TABLE`, `DROP DATABASE`, `TRUNCATE` in SQL
- `db:reset`, `db:drop` npm/prisma scripts

**Credential exposure**
- Commands that `cat`, `echo`, or `curl` files containing `SECRET`, `KEY`, `TOKEN`, `PASSWORD` to stdout

---

## Installation

### Step 1: Create the hook script

```bash
mkdir -p .claude/hooks
```

Create `.claude/hooks/command-guard.py`:

```python
#!/usr/bin/env python3
"""
command-guard.py — PreToolUse hook that blocks dangerous Bash commands.
Claude Code calls this before executing any Bash tool call.
Exit code 2 = block the command and show the message.
Exit code 0 = allow the command.
"""
import sys
import json
import re
import os

# Load the tool call input from stdin
try:
    payload = json.load(sys.stdin)
except Exception:
    sys.exit(0)  # Can't parse — allow (fail open)

tool_name = payload.get('tool_name', '')
tool_input = payload.get('tool_input', {})

# Only intercept Bash calls
if tool_name != 'Bash':
    sys.exit(0)

command = tool_input.get('command', '')

# --- Blocklist rules ---
# Each rule: (regex pattern, reason shown to agent)

BLOCKED = [
    # Irreversible deletions
    (r'\brm\s+-[a-zA-Z]*r[a-zA-Z]*f\b', 'rm -rf is blocked. Use rm with explicit paths, or move to trash instead.'),
    (r'\bgit\s+clean\s+-[a-zA-Z]*f\b', 'git clean -f is blocked. List untracked files with --dry-run first.'),

    # Force push
    (r'\bgit\s+push\s+.*--force\b', 'Force push is blocked. Confirm with the user before rewriting remote history.'),
    (r'\bgit\s+push\s+.*-f\b(?!ile)', 'Force push (-f) is blocked. Confirm with the user before rewriting remote history.'),

    # Hard reset
    (r'\bgit\s+reset\s+--hard\b', 'git reset --hard is blocked. Use --soft or --mixed, or confirm with user first.'),

    # Database destructive ops
    (r'\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b', 'Destructive SQL (DROP/TRUNCATE) is blocked. Confirm with the user before destroying data.', re.IGNORECASE),
    (r'\b(db:reset|db:drop|prisma.*reset)\b', 'Database reset scripts are blocked. Confirm with the user — this destroys all data.'),

    # Credential leakage to stdout (basic check)
    (r'\b(cat|echo|curl|printf)\b.*\.(env|secret|secrets|pem|key)\b', 'Printing credential files to stdout is blocked. Use secure variable injection instead.'),
]

for rule in BLOCKED:
    pattern = rule[0]
    message = rule[1]
    flags = rule[2] if len(rule) > 2 else 0
    if re.search(pattern, command, flags):
        print(json.dumps({
            "decision": "block",
            "reason": f"[command-guard] {message}\n\nBlocked command: {command[:200]}"
        }))
        sys.exit(2)

# All clear
sys.exit(0)
```

Make it executable:

```bash
chmod +x .claude/hooks/command-guard.py
```

---

### Step 2: Register the hook in .claude/settings.json

If `.claude/settings.json` doesn't exist, create it. If it does, add to the `hooks` array:

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

---

### Step 3: Verify the hook is registered

Restart Claude Code, then ask it to run a blocked command:

```
Run: rm -rf ./test-dir
```

The agent should receive a block message rather than executing the command.

---

## Customizing the Blocklist

Edit the `BLOCKED` list in `command-guard.py` to add project-specific rules.

**Example: Block deploys to production from feature branches**

```python
(r'\bdeploy.*production\b', 'Direct production deploys are blocked. Merge to main first, then deploy via CI.'),
```

**Example: Block overwriting specific config files**

```python
(r'\bcp\b.*\b(\.env\.production|secrets\.json)\b', 'Overwriting production config files is blocked. Edit manually.'),
```

**Example: Allow force push only to personal branches**

Replace the force push rule with a more nuanced check:

```python
# Allow force push to personal/feature branches, block on main/master/staging
if re.search(r'\bgit\s+push\s+.*(-f|--force)\b', command):
    if not re.search(r'\b(main|master|staging|production)\b', command):
        sys.exit(0)  # Allow: not targeting a protected branch
    print(json.dumps({"decision": "block", "reason": "Force push to protected branches is blocked."}))
    sys.exit(2)
```

---

## Understanding the Hook Pattern

Claude Code hooks are scripts that fire at specific points in the agent's tool lifecycle:

| Hook Type | When It Fires | Use Cases |
|-----------|--------------|-----------|
| `PreToolUse` | Before any tool call | Block dangerous operations, inject context |
| `PostToolUse` | After any tool call | Log actions, update state, send notifications |
| `Notification` | On system events (compaction, etc.) | Recovery, awareness updates |

The hook receives a JSON payload on stdin and communicates back via stdout + exit code:
- **Exit 0**: Allow the tool call to proceed
- **Exit 2**: Block the tool call; the `reason` in stdout is shown to the agent

Hooks are composable. You can chain multiple hooks for the same event, and each runs independently.

---

## What This Does Not Cover

This guard blocks the most common dangerous operations. It does not:
- Inspect file contents before writes (use a `Write` tool hook for that)
- Validate SQL in ORM calls (only raw SQL strings)
- Prevent API calls that delete remote resources

For production systems where the agent has access to critical infrastructure, layer additional guards specific to your environment.

---

## Going Further

This guard works when you're watching. But what about when you're not? If your agent runs a scheduled job at 2 AM and hits a destructive edge case, a command-guard hook still blocks it — but nobody sees the block message until morning. And command blocking is just one layer of safety.

**Instar adds the safety infrastructure that autonomous agents need.** Identity grounding hooks fire before the agent sends any external message — so it can't accidentally email or post something off-character. Every tool call across every session gets audit-logged for post-hoc review. And the command guard is installed automatically as part of setup, along with all the other hooks.

Safety is important, but it's just the foundation. With Instar, your agent also gets:
- **A job scheduler** — recurring tasks on cron, running while you sleep
- **Background sessions** — spawn parallel workers for deep tasks
- **Telegram integration** — two-way messaging from your phone
- **Persistent identity and memory** — context that survives across sessions

One command, about 2 minutes:

```bash
npx instar
```

Your agent goes from guarded-when-you're-watching to safe-when-you're-not. [instar.sh](https://instar.sh)

More from JKHeadley/instar

SkillDescription
agent-passportView this agent's digital passport (identity + trust + allowed/forbidden actions) and verify a peer's passport against a proposed action (EXO 3.0).
agent-readinessScore a task or workflow on its coordination-vs-judgment ratio to tell whether it's a good agent candidate (EXO 3.0 task-decomposition matrix).
autonomousEnter autonomous development mode with STRUCTURAL enforcement. Uses a stop hook to prevent premature exit. Generates stop conditions and confirms with user before starting. Work independently for a specified duration with progress reporting.
credential-leak-detectorPostToolUse hook that scans Bash tool output for leaked credentials — API keys, tokens, private keys, and secrets — before they reach the conversation. Blocks critical leaks, redacts high-severity matches, and warns on suspicious patterns. 14 detection patterns covering OpenAI, Anthropic, AWS, GitHub, Stripe, Google, Slack, SendGrid, Twilio, PEM keys, bearer tokens, and generic secrets. No external dependencies. Trigger words: security, credential leak, secret exposure, key detection, token scan, API key leaked, credential guard, secret scanner, prevent credential leak.
instar-devInstar-specific development skill used by the instar-developing agent (Echo, or any agent assigned instar-dev responsibilities). Wraps /build with mandatory side-effects review, signal-vs-authority principle check, and artifact generation. Structural enforcement via pre-commit/pre-push hooks — the instar repo refuses commits and pushes that didn't come through this skill. NOT a user-facing skill — end users should never invoke it.
instar-feedbackSubmit structured feedback about instar bugs, feature requests, improvements, or innovations worth sharing. Use when something isn't working, when a feature is missing, when you've built something that could benefit all agents, or when the user mentions a problem with instar. Also use proactively after building significant features — ask yourself if other agents would benefit. Feedback is relayed agent-to-agent to instar maintainers. Trigger words: bug report, feedback, issue, something's wrong, feature request, this isn't working, improvement, suggest, built something useful, other agents could use this.
instar-identityEstablish and recover persistent agent identity that survives context compaction, session restarts, and autonomous operation. Use when an agent needs to know who it is, recover after context compression, orient at session start, or understand the identity infrastructure. Trigger words: who am I, remember, identity, after restart, compaction, context loss, who am I working with, my principles.
instar-projectRegister, inspect, and drive multi-spec projects via the instar /projects API. Twelve subcommands cover the full Phase 1 surface — create / status / next / advance / drift / run-round / halt / ack / resume / abandon / accept-partial / claim-ownership.
instar-schedulerSchedule recurring agent tasks using cron expressions. Use when the user asks to run something on a schedule, check something periodically, automate a recurring task, set up a cron job, or wants work to happen while they're away. Trigger words: schedule, recurring, cron, every hour, every day, run daily, periodic, automated.
instar-sessionSpawn, monitor, and communicate with persistent Claude Code sessions running in the background. Use when a task needs to run without blocking the current session, when the user asks to do something in the background, or when a long-running task needs its own context window. Trigger words: background task, spawn session, persistent, run in background, parallel, separate session, async task.