Show HN: Safety Guardrails for Claude Code

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.