pi-warden and the Pi Guardrail Ecosystem

The Pi coding agent doesn't ship a built-in guardrail layer, so its community built one. Two projects, pi-warden and pi-jev-auto-mode, add rule enforcement and auto-approval gates on top of Pi specifically. A wider pattern shows up around them: three separate, unrelated repositories are all named jev-guard, each solving a version of the same problem — deciding whether a tool call is safe — for different hosts and with very different amounts of supporting evidence.

This article covers both threads: the Pi-specific tooling, and what a name collision like jev-guard × 3 tells you about how fast this space is moving. For the underlying idea, see what Jev is and typed decisions vs free text.

Key Takeaways

• pi-warden is the most evidenced project in this cluster. Its README reports 18,075 guarded operations across 315 sessions, a hold rate of about 3 per 1,000 calls, and 11 of 13 labeled holds clearing on retry.
• pi-jev-auto-mode fails closed. Undecidable cases block by default rather than allow — the opposite default from some of its peers.
• Three unrelated repos share the name jev-guard. leepokai's is the most cross-agent and best documented; the other two are thinner.
• Evidence varies by an order of magnitude. leepokai's jev-guard has 27 stars and multi-agent testing; muratcakmak's and ClemensSchartmueller's versions have 7 and 3 stars respectively, with less independent verification.
• None of these replace a sandbox. Every project in this cluster says so explicitly in its own README.

pi-warden: supervision, not just permission

pi-warden (MIT, 137 stars as of September 2026, /skills/pi-warden-devmortimer) sits over the Pi agent and watches for more than dangerous commands. Its guards cover: holding irreversible actions like force pushes and recursive deletes, checking edits against a project's own Markdown rules, verifying "done" claims against an actual test or build run, scanning for hardcoded secrets and injection risks, and catching an agent stuck repeating the same failed approach.

Jev is the default backend for these judgments, with OpenRouter available as an alternative. The README's own numbers are the most substantial in this cluster: 18,075 guarded operations across 315 sessions, a hold rate of roughly 3 per 1,000 calls, and a 150-run paired comparison where the ungated control hit 6 rule violations against zero with pi-warden active. Of 13 labeled holds, 11 cleared on retry — the project's own read on its false-positive rate. A separate run reports 13,952 guard cases across 109 cycles with no measured drift.

Two caveats matter. The project redacts secrets before sending summaries to a judgment provider, which is the right default, but it still means the check point is off-machine. And it's designed for single-agent workflows — it doesn't claim to coordinate guardrails across a multi-agent session. Requires Pi 0.85+ and Node 22.19+; install with pi install npm:pi-warden.

pi-jev-auto-mode: a fail-closed gate for the same agent

pi-jev-auto-mode (MIT, 23 stars, /skills/pi-jev-auto-mode-jomatsu) takes a narrower job: deciding whether to auto-approve a bash, write, or edit call. It runs deterministic policy first — hard-deny patterns and protected paths — and only escalates to Jev for the cases those rules don't resolve.

The default matters here: an undecidable case is blocked, not allowed. The README documents this as measured behavior, not just a setting — unrequested git reset --hard, npm publish, rm -rf, and sudo came back blocked, while unrequested mv, cp, tar, chmod +x, and node -e were allowed through. Latency for judged calls ran 193–642 ms in the author's measurements; fast-path calls that match a known-safe pattern cost nothing extra. It needs a TypeSafe API key (currently early access) to run the semantic layer at all — without one, only the deterministic rules apply. Project-level overrides that loosen the gate work only inside checkouts marked trusted, which limits how much an untrusted repo can weaken its own guardrails.

Three jev-guards, one problem, different evidence

Search "jev-guard" on GitHub today and you'll find three independent projects, none affiliated with the others.

leepokai/jev-guard (MIT, 27 stars, /skills/jev-guard-leepokai) is the broadest: it runs across Claude Code, Codex, GitHub Copilot CLI, Gemini CLI, Cursor, pi, OpenCode, and ACP clients like Zed and JetBrains. It scores every tool call on risk, approval need, and whether the call was actually user-requested or planted by untrusted content, then allows, asks, or denies. Its README quotes a cost of roughly $0.00004 per tool call and reports 580 ms p50 latency through the Vercel AI Gateway. This is the same project covered in more depth in jev-guard, jev-mcp and Safer with Jev under a different write-up angle.

muratcakmak/jev-guard (MIT, 7 stars) is a Claude Code plugin specifically, adding rule scoring, a deploy confirmation gate, background-task management for long commands, and a check on whether a final answer is actually supported by the turn's own evidence. It batches Jev calls and degrades gracefully — "every failure path passes the call through" — which is a fail-open default, worth noting against pi-jev-auto-mode's fail-closed one above. It ships a CI companion script for diff analysis outside the live agent loop. Evidence here is thinner: no independently measured latency or accuracy figures appear in the public README.

ClemensSchartmueller/jev-guard (MIT, 3 stars) targets Claude Code, Codex CLI, and Antigravity together, scoring three primitives — whether an operation stays inside the workspace, its destructive blast radius (0–3), and a violation category for things like credential leaks or workspace escapes. It advertises a local fastpath with sub-millisecond checks for cached safe operations. At 3 stars and without independent testing beyond the author's own description, this is the earliest-stage project in the cluster; the README's own liability disclaimer is a fair summary of where the evidence stands.

What to do next

1. If you're on Pi specifically, pi-warden has the most operational evidence in this group — start there, in monitoring mode, before trusting it to hold anything automatically.
2. Pick a fail-open or fail-closed default deliberately. pi-jev-auto-mode fails closed; muratcakmak's jev-guard fails open. Neither is wrong, but you should choose, not inherit whichever the library shipped with.
3. Don't assume "jev-guard" means one project. Check the star count, the author, and which agents it actually supports before you install.
4. Treat low-star, single-author security tools as unverified until you've tested them yourself. See how to evaluate Jev projects honestly for the checklist, and browse the wider field at the Awesome Jev radar.