Statewright
A guardrail system that limits which tools an AI coding agent can use at each stage of a task — read-only while planning, edit access only while implementing — so it can't take an action outside its current job.
🔗 Visit Statewright
Description
AI coding assistants are usually handed every tool at once: read files, write files, run commands, delete things. If the agent misreads the task or hallucinates a step, nothing stops it from doing something destructive mid-conversation. Statewright works more like a building with keycard access per floor: the agent only gets the keys for the phase it's actually in — read-only while it's exploring the code, edit tools once it's implementing, test commands once it's verifying — so a wrong turn can't cascade into a wrong action.
Statewright is a Rust-built engine that enforces phase-specific tool allowlists for AI coding agents via workflows defined in JSON (states, transitions, guards, approval gates). It integrates through MCP and hooks with Claude Code, Codex, Cursor, OpenCode, and Pi, and can route different LLMs to different states (e.g., a cheap model for read-only exploration, a stronger one for implementation). It's open source (Apache 2.0, with some components on a delayed FSL license converting to Apache 2.0 in 2029) and self-hostable via Docker Compose, with an optional managed cloud tier for workflow storage and the MCP gateway.
💬 Our review
The short version: if you're running AI coding agents somewhat autonomously and the thing keeping you up at night is "what if it edits or deletes something it shouldn't," Statewright is a real, working answer — but it's a young, narrow tool solving a narrow (if growing) anxiety, not something every AI-assisted developer needs today.
The core idea — deterministic, non-LLM enforcement of tool access by phase — is sound and differs meaningfully from prompt-based guardrails, which an agent can talk itself out of. Statewright's guards run in a Rust engine outside the model's control, so a jailbroken or confused agent literally cannot call a disallowed tool. The reported benchmark result (small local models going from 2/10 to 10/10 on a constrained SWE-bench subset with guardrails on) is a useful signal, though it's a small sample and self-reported.
The honest limits: at ~490 stars and a young codebase, this is early-stage tooling — expect rough edges, a narrower ecosystem than more established dev-tool categories, and a learning curve to define workflows in JSON. It's also a solution shaped for a specific risk profile: teams giving agents broad, semi-autonomous access to a real codebase. If your usage is closer to "AI suggests, I approve every diff," the guardrails solve a problem you don't really have yet.
💰 Pricing
📊 Global score
🤖 AI-enriched data
Moteur open source (Apache 2.0 / FSL) auto-hébergeable via Docker Compose ; cloud managé avec palier gratuit pour le stockage des workflows et la passerelle MCP.
Pros
Application déterministe (moteur Rust hors du modèle) — un agent ne peut pas contourner les restrictions par du prompt engineering
Restrictions par phase de workflow (lecture seule en planification, édition en implémentation, etc.)
S'intègre à Claude Code, Cursor, Codex, OpenCode, Pi via MCP/hooks
Auto-hébergeable gratuitement (Docker Compose), licence open source
Cons
Projet jeune (~490 étoiles GitHub) — écosystème et documentation encore limités
Nécessite de définir les workflows en JSON — courbe d'apprentissage
Résout un problème de sécurité spécifique aux agents semi-autonomes ; peu utile si vous validez déjà chaque diff manuellement