Workban Guard

Guardrails for coding agents

Your agent may do a lot.

Workban Guard runs inside Claude Code and Codex CLI and checks every command before it runs. rm -rf ~, a force push to main or supabase db reset never reach your system, not even hidden in a heredoc or a package script. After every edit it checks the new lines. The agent is only done when typecheck, lint and tests are green.

InstallStart with Workban

Version 0.2.0 · for Claude Code and Codex CLI · runs locally

  • Claude Code
  • Codex CLI
  • 39 rules
  • 30 detectors
  • p95 < 80 ms

Protocol

wbg check

  1. denyrm -rf ~would delete your home directoryfs.rm-catastrophic
  2. denygit push --force origin mainoverwrites other people's commits on maingit.force-push
  3. denycat .envwould put secrets into the transcript and send them to the model providersecrets.read-env
  4. denynpm install reqeuststhe package does not exist, a typical made-up namedeps.not-found
  5. askgit reset --hardthrows away uncommitted changesgit.discard-changes
  6. askpnpm db:resetthe script runs supabase db resetdb.destructive
Real decisions from wbg check

01 · Before it runs

Dangerous commands stop before they run.

Workban Guard parses every shell command instead of searching the text for patterns. It descends into $(…), heredocs, bash -c, package scripts and make targets. What an agent should never do is denied (deny). What is rare but legitimate needs your confirmation (ask).

File system
rm -rf on home, the project or .git. Deleting outside the project only after asking.
Git
Force push and push to main, --no-verify, reset --hard, secrets in commits.
Database
supabase db reset, DROP, TRUNCATE, DELETE without WHERE, removed Docker volumes.
Secrets
Reading .env and keys, writing secret literals into files, printing tokens.
Packages
Made-up packages, typosquats, brand-new and barely used packages, checked against npm and PyPI.
Deploys
vercel --prod, supabase db push, terraform apply or npm publish only after asking.
Self-protection
The agent can neither switch Workban Guard off nor change its config.

02 · After every edit

Every new line gets checked, not the legacy code.

30 detectors run on the lines the agent has just written. When one finds a problem, Workban Guard reports it back at once, and the agent fixes it before moving on.

  • any, @ts-ignore and disabled lint rules
  • empty catch blocks and placeholders instead of code
  • SQL and shell commands built from concatenated strings
  • secrets in code, disabled TLS checks, MD5 for passwords
  • tables without row level security, the service role key in client code
  • .only in tests and assertions that always pass

03 · Before it is done

Done means: typecheck, lint and tests are green.

When the agent wants to stop, the project's checks run over the files it changed in this session. If something is red, it keeps working. After two rounds the gate lets go and tells you what is still open, instead of going round in circles.

Checks
typecheck, lint and test from package.json, or your own from the config. Tests only for the affected files.
Findings
Errors from the checks after each edit that are still in the code.
Hints
Code changed without tests or docs. A hint by default, blocking if you want.
Limit
At most two forced rounds per task.

04 · Cold review

A review without the conversation.

/wbg:review starts independent reviewers as separate processes. They see only the diff and the code, not your conversation. Five roles check security, tests, sloppiness, architecture and your own rules. Every finding is re-checked in a throwaway copy and only counts as confirmed once it reproduces.

  • The review uses the agent you are working in. Another AI only when you name it explicitly.
  • With review.engines a project decides which AI a review may send code to at all.
  • Rules in the project's .claude/rules/ replace global rules of the same name.

05 · Numbers

What you get.

  • 39rules check every command and every file access.
  • 30detectors check every new line.
  • < 80 msper check (p95). The agent does not get noticeably slower.
  • localRuns on your computer, without telemetry. Package names go to npm and PyPI, diffs only to your AI when you start a review.

06 · For teams

Rules that come with the project.

  • A .workban-guard.json in the repository tightens the rules for everyone. Loosening them takes your approval with /wbg:trust.
  • Custom rules as a regular expression or a path glob, for example: no connection to the production database.
  • Mode plan allows only reading until you approve, autopilot is for unattended runs.
  • Every decision is recorded in the audit log .workban-guard/audit.jsonl, with secrets masked.
  • /wbg:allow lets exactly one blocked action through once, when you do want it.

Access through Workban

Workban Guard is not public.

Access goes to a whole workspace in Workban. Signing up creates one. As its owner or an admin, you then request activation in Workban under Settings → Workban Guard. Once it is granted, every member installs Workban Guard with their Workban account, without a token of its own.

Start with WorkbanGo to installation