Loading…
Open-Policy Exchange
~5 min to deploy
Claude Code Destructive-Shell Gate
Never let an agent run `rm -rf`, a force-drop, or a disk-level command without a human approval on the tool call.
For: Engineers running Claude Code with write access to a real repo or machine
SOC 2 CC8.1ISO 27001 A.8.32Change evidence
What it enforces
Recursive delete block
Blocks any Bash tool call whose command matches a recursive or forced delete before the host executes it.
Disk and device guard
Blocks disk-level commands (format, dd to a device, filesystem wipe) outright — there is no approving path.
Out-of-workspace write escalation
Escalates writes that resolve outside the repository root to a named approver instead of denying silently.
claude-code-destructive-shell-gate.yaml
# Claude Code Destructive-Shell Gate
# Fork: adjust the command patterns and the workspace root for your setup.
# Wire it at PreToolUse in .claude/settings.json so the agent cannot choose
# whether to consult the gate.
apiVersion: decionis.dev/v1
kind: PolicyPack
metadata:
name: claude-code-destructive-shell-gate
surface: claude_code
standards: [SOC2-CC8.1, ISO27001-A.8.32]
defaults:
mode: shadow # shadow | enforce
emit_dossier: true
fail_closed: true # parse/eval failure denies the tool call
rules:
- name: recursive_delete_block
when: "tool == 'Bash'"
decision: |
BLOCK IF command matches '(^|\s)rm\s+(-[a-zA-Z]*r[a-zA-Z]*f|-[a-zA-Z]*f[a-zA-Z]*r)'
ALLOW OTHERWISE
reason_code: destructive_delete_blocked
- name: disk_and_device_guard
when: "tool == 'Bash'"
decision: |
BLOCK IF command matches '(mkfs|diskutil eraseDisk|dd\s+.*of=/dev/)'
ALLOW OTHERWISE
reason_code: disk_level_command_blocked
- name: out_of_workspace_write
when: "tool in ['Write', 'Edit', 'NotebookEdit']"
decision: |
ESCALATE IF not path.startswith(workspace.root)
ALLOW OTHERWISE
reason_code: write_outside_workspace
Fork it, change the thresholds to match your environment, and deploy in shadow mode first — it defaults to listen-only so nothing in your live pipeline changes.
How to install it
Follow the install path for this surface, then paste the forked YAML as your policy config.
What to do next
This recipe is one step in a path. The same five steps apply to every recipe in the exchange.
- Simulate this recipe
Run the policy against a realistic action in the browser. Push it past what the rules allow and watch the verdict come back. No account.
- View the signed Decision Dossier
See exactly what was decided and why: the rule that fired, the evidence it read, the policy version in force, and an Ed25519 signature you can verify yourself.
- Deploy in shadow mode
Measure what the policy would have caught on your own traffic without touching the live path. Every recipe defaults to shadow, so the first deployment carries no execution risk.
- Connect a real workflow
Point the same policy at the system where the action actually originates — a checkout, an ERP posting, a Zap, an agent's tool call.
- Share the verified result
Publish the proof: a public verification link, an embeddable badge, a PR comment, or an anonymized shadow-mode finding. This is how the next person discovers Decionis.