Show HN: Safety Guardrails for Claude Code

I'll pull the repo and HN thread so the paragraphs stick to real details—names, mechanics, and numbers only from those sources.A Show HN post points to groundwork, an open-source Claude Code harness from choiyounggi that packages safety guardrails, a development loop, and a memory system as installable plugins. The listing sits at one point with zero comments so far. The project is framed as a safe-by-default starter pack for giving an AI coding agent a shell without treating every Bash call as a one-shot trust decision.

Technically, groundwork is a marketplace of three plugins: guardrails, dev-loop, and memory-loop. The guardrails plugin is a Bash PreToolUse guard that blocks supply-chain patterns such as curl piped to sh, disk-destroying tools like dd and mkfs, and fork bombs; it prompts before rm -rf, force-push, DROP or TRUNCATE, kubectl delete, credential and .env access, cloud-resource deletion, and secret exports; and it writes a redacted local audit log. Rules are off, ask, or block, overridable per repo or globally via .groundwork/guardrails.json, including custom extraAsk and extraBlock patterns. The README states the deny still holds under --dangerously-skip-permissions. Hooks are covered by bats tests in CI, distinguishing mention of a dangerous command from actual execution. Install is via Claude Code plugin marketplace commands for each plugin à la carte or all three.

For engineers who run agents with broad shell access, the gap is clear: Claude Code’s built-in permissions are coarse and often session-scoped—approve Bash once and the prompt stops—while settings.json denials cannot express “block curl|sh and dd, ask on rm -rf and DROP, allow the rest, log with secrets redacted.” groundwork is aimed at that pattern-level policy layer, including the case where permission prompts are turned off for speed.

In market context it sits between Claude Code’s free built-in prompts and paid cloud guardrail services that send commands to an API. The project’s comparison table stresses zero-config install, local matching with no command exfiltration, team-shared config under .groundwork/, redacted local audit logs, CI-tested hooks, and MIT licensing. Adjacent pieces go beyond pure safety: dev-loop runs a wiki-grounded plan/verify loop (TDD / PDCA / Reflexion) and can orchestrate parallel worker sessions on Orca when present or plain tmux otherwise; memory-loop gates saved memories, uses tiered expiry with archive-not-delete, and distills habits into HABITS.md.

Practical next step after install is /guardrails:self-test, which feeds dangerous command shapes through the guard and reports block or ask without executing them. Teams should commit a shared .groundwork/guardrails.json, map dev-loop roles (verify, knowledge, explore, design) to real test, wiki, search, and design tools, and treat the roadmap’s team governance work—managed-settings hierarchy, policy-as-code, and audit aggregation—as the signal for multi-seat rollouts. Watch whether the deny path stays reliable across Claude Code updates in yolo mode and how early HN traction evolves beyond a single-point Show HN listing.