We're excited to announce Guardrails—workspace rules that intercept Claude Code's tool calls before they run, enforced for every member through the SuperClawd CLI.

Claude Code, supercharged—your team's standards, every session.

The Problem: Agents Act Faster Than You Can Review

Claude Code doesn't just suggest changes—it edits files, runs shell commands, and fetches from the web on its own. Most of the time that's exactly what you want. But "most of the time" isn't a safety policy.

  • A session runs rm -rf against the wrong directory.
  • A git push --force quietly rewrites a shared branch.
  • An edit lands in your auth or payments code with no second look.
  • A write commits an API key straight into a config file.

You can put "please be careful" in an instruction file and hope. But hope isn't enforcement, and every teammate's machine is a fresh chance for something to slip through.

The Fix: Rules That Intercept the Call

A guardrail is a rule that sits in front of Claude Code's tools. When a tool call matches the rule, the guardrail acts before anything happens. An admin defines it once in the SuperClawd app, and it's enforced in every member's Claude Code session—no per-machine setup.

Each guardrail has an action that decides what happens on a match:

  • Deny — block the call outright. The tool never runs.
  • Ask — prompt the member for approval before proceeding.
  • Warn — note the concern and let the call proceed.

That spread matters: not every risk deserves a hard stop. Block the truly destructive, gate the sensitive, and surface the merely noteworthy—without turning every session into a wall of prompts.

Matching: Precise About What You Catch

A guardrail decides what it applies to by matching on one or more dimensions:

  • Tools — Edit, Write, MultiEdit, Bash, WebFetch, or all tools (*).
  • Path globs — match by file path, e.g. **/auth/** (for Edit/Write/MultiEdit).
  • Command patterns — a regex matched against the shell command, e.g. \brm\s+-rf\b (for Bash).
  • Content patterns — a regex matched against the content being written, e.g. AKIA[0-9A-Z]{16} (for Write/Edit).

Combine them to be as broad or as surgical as you need: a Bash-only rule that fires on force pushes, or an Edit rule scoped to a single sensitive directory.

When a guardrail fires, it shows the member a message you write—so the rule explains itself in the moment instead of being a mystery block.

Three Rules Worth Adding Today

A few examples of what guardrails are made for:

  • Block destructive shell commands. A Deny on Bash matching rm -rf, git push --force, and friends. The call never runs.
  • Require approval near sensitive code. An Ask on Edit/Write scoped to **/auth/** or **/payments/**, so changes to the code that matters most get a human in the loop.
  • Warn on possible secrets. A Warn on Write whose content pattern looks like an API key or token—a nudge, not a blocker.

Start from a preset to get one of these in a couple of clicks, or build a custom guardrail with your own tools, patterns, and action.

Versions and Releases: Change Rules Without Surprises

A guardrail is a safety policy, so changing one shouldn't be a gamble. Guardrails now work like the rest of SuperClawd—skills, agents, commands, workflows—with immutable versions and releases.

You edit a draft, and when it's ready you Publish a release—a frozen snapshot. Your first publish is automatically promoted to stable, the version every member's session enforces. Tweak the rule later and publish again, and you decide when that new version goes live: Promote it to stable when you're confident, or, if a release turns out to be too aggressive, promote an older one to roll back instantly. Need to pick up where a past version left off? Restore it into the draft and keep editing.

Until a guardrail has a stable release, it isn't enforced at all—so a half-written rule never silently blocks anyone.

Test a Draft Before It Lands for the Team

Guardrails use the same two-key experimental gate as Skills and Agents. A normal Claude Code session always enforces the stable release. An experimental session enforces the live draft—but only for guardrails you've flagged experimental.

That means you can sharpen a Deny pattern or a path glob, run it against your own experimental session to make sure it catches what you intend (and nothing you don't), and only then publish and promote it for everyone. No more shipping a rule blind and finding out in someone else's terminal.

Built a guardrail worth reusing elsewhere? There are two ways to move it.

  • Share links — generate an unlisted, revocable link to a guardrail (requires a stable release to share). Pin it to a specific version or have it follow stable, and optionally set an expiry or a maximum number of imports. The recipient opens the link, previews the rule, and imports a copy into their own workspace. Revoke it anytime.
  • JSON export/import — download a guardrail as JSON—name, description, match, action, message, preset, and experimental flag—and import it into another workspace. Name collisions auto-rename, and an imported guardrail lands as an enabled draft, so you review and publish it before it enforces anything.

Enabled and Who Manages

A couple more controls round things out:

  • Enabled — turn a guardrail off without deleting it. Disabled rules stop being enforced.

Owners, admins, and maintainers create, edit, publish, promote, restore, enable/disable, share, and delete guardrails. Members don't configure them—they just get the protection, automatically, in every session.

Get Started

Guardrails are available now in your SuperClawd workspace.

  1. Go to app.superclawd.com
  2. Open the Guardrails page in your workspace
  3. Add a guardrail from a preset—or configure a custom rule
  4. Your team's next Claude Code session is protected automatically

Want the full details on actions, matchers, and enforcement? Read the docs at docs.superclawd.com.

Pro tip: Start with one Deny on the command you never want an agent to run. It's the highest-leverage rule you'll ever add.