Workban

Guardrails for coding agents

Your agent may do a lot. Not everything.

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.

Protocolwbg check

  • deny: rm -rf ~. would delete your home directory (fs.rm-catastrophic)
  • deny: git push --force origin main. overwrites other people's commits on main (git.force-push)
  • deny: cat .env. would put secrets into the transcript and send them to the model provider (secrets.read-env)
  • deny: npm install reqeusts. the package does not exist, a typical made-up name (deps.not-found)
  • ask: git reset --hard. throws away uncommitted changes (git.discard-changes)
  • ask: pnpm db:reset. the script runs supabase db reset (db.destructive)

Real decisions from wbg check

  • Version 0.3.0
  • 39 rules
  • 33 detectors
  • Runs locally

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.
All rulesEvery rule and detector, and what Workban Guard does in each case.

It also checks what the agent reads.

A file, a web page or an MCP server's answer can carry instructions that did not come from you. Workban Guard looks for them locally, without a model, with 7 rules, and warns the agent and you. It cannot block anything here, because the text has already been read. The warning tells the agent to treat it as data, not as an order.

  • requests to drop earlier instructions
  • text that gives the agent a new role
  • commands that send secrets out
  • text hidden in invisible characters

Only what is new gets checked.

33 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
  • real email addresses, IBANs and card numbers in test data
  • .only in tests and assertions that always pass

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.

Cold review: no conversation context.

/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.

What you get.

39rules check every command and every file access.
33detectors 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.

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.

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