Introducing pi-verdict — a minimal permission gate for pi: allow / ask / deny, one file, zero dependencies

[jesset]

pi's README says it plainly: "No permission popups. Run in a container, or build your own confirmation flow with extensions." pi-verdict is that confirmation flow — a permission gate in the style of Claude Code's auto mode, where every tool call gets checked before it runs.

Why you might trust it

For a security extension, shape matters as much as behavior:

• One ~900-line file, zero runtime dependencies. You can read all of it in one sitting before trusting it — which felt like the right response to pi's "review the source before installing" warning.
• No built-in allowlist — the built-in layer only makes deny claims. That decision came from testing, not intuition: testing the rule layer against bypass attempts found 8 ways around the original allowlist, each reproduced with a working payload, and 0.2.0 removed the allowlist entirely instead of patching it. Every "always allow" is yours to declare; the writeup ships in research/.

What it does

tool_call → (deny floor + your rules) → classifier with conversation context → allow | deny | ask

• The classifier can say ask — genuinely ambiguous actions get routed to you with a one-key confirm, not silently approved. In non-interactive sessions ask degrades to deny.
• Everything fails closed: classifier exception, timeout, or malformed output → deny. Never silently allow.
• The gate guards itself (ADR-0001): its own config and installed copy are user-editable only, with tamper detection, snapshot re-verification before every verdict, and auto-restore + fail-closed if the extension copy changes.
• denyPaths — protected paths you declare (new in 0.5.0): plain path prefixes in your config; the gate owns normalization — ~, $HOME, relative, .., symlink spellings all resolve — and any touch, including path tokens pulled out of bash command strings, routes to a deterministic ask you adjudicate (headless degrades to deny). Not even your own allow rules may touch them, and the classifier never learns the paths: it only ever sees a fixed existence hint, so no path plaintext leaves the machine.

Design decisions are measured, not vibes

The lab notes ship with the repo (research/):

• replayed 1.2k+ real classifier verdicts → measured cache hit rate (3.2%) → cache deferred
• forensic root-cause of thinking models burning the classifier budget → thinkingEnabled: false
• tree-sitter rule-engine port measured against 746 real bash calls → rejected (absorbed 0 gray calls)
• the rule-layer bypass testing above

Try it

Requires pi ≥ 0.84.

pi install npm:pi-verdict        # or try once: pi -e git:github.com/jesset/pi-verdict
/automode on

Your rules live in ~/.pi/agent/config/pi-verdict.json (JS regex allow/deny arrays; deny wins; denyPaths for protected paths). There's a comparison table against pi-automode / pi-permission in the README — we've converged on similar architectures with pi-automode; what stays distinct is the runtime ask, the removable deny floor, the self-protection layer, and the zero-dependency single file.

https://github.com/jesset/pi-verdict · https://pi.dev/packages/pi-verdict

Feedback very welcome, especially on:

1. the ask UX — when does a confirm dialog become annoying enough that you'd rather it just decided?
2. whether a cross-session tamper baseline (ADR-0001 phase 2) is worth the startup cost

[Santoshkumarpuppala]

Read 0.5.0 at 1386a952 against ADR-0002's priority order. For grep, find and ls the chain never reaches denyPaths when path is omitted — and omitting it is the documented normal form: pi declares path optional on all three with "(default: current directory)" (packages/coding-agent/src/core/tools/grep.ts:23, find.ts:30, ls.ts:12).

In extensions/pi-verdict.ts:

• :839-841 — the file-family branch, absent path → base = { verdict: "allow" }, with your own comment grep/find/ls: optional path, absent → plain allow.
• :467-468 — userRuleTarget returns null for a file tool with no path.
• :848 — if (target !== null) gates the whole block: user deny, the denyPaths hit at :856 (its only call site in the file), and user allow.
• :862 returns base, and :1325 returns it with source: "rule" before classifyWithModel at :1341.

So grep with a pattern and no path, run from a cwd containing a declared denyPath, returns matching content lines from inside that directory: no ask, no existence hint, no classifier call. ADR-0002 §4 states "denyPaths therefore overrides the user's own allow rules ('not even my allow list may touch these')". That holds for an explicit path and not for the absent one.

Read from the source, not run — I don't have pi installed, so treat the sequence as traced rather than reproduced.

Smallest fix that keeps the current shape: for a file-family tool with no path, treat cwd as the target instead of returning early — userRuleTarget returns path.resolve(cwd), hitDenyPaths then sees it, and a denyPath at or under cwd gets the ask. The read branch at :836-838 already takes that position for an empty path, and its comment gives the same reasoning.

Worth pinning with a rule-layer test in the schema-default shape: {} as grep input, cwd containing a denyPath, assert ask. If the existing denyPaths tests all pass a path explicitly, none of them can fail on this.

[jesset]

Reproduced and fixed — thank you for this exceptionally precise trace.

Released in 0.7.1.

Reproduction also surfaced a sibling shape: an explicit parent-directory path fell through as well — a declaration under the search scope is invisible to the one-directional compare.

The fix resolves an omitted/empty path to the cwd for both the user-rule target and the denyPaths candidate, and compares grep/find/ls bidirectionally. Two small corrections to the minimal fix as proposed: the candidate change had to land in the extractor (hitDenyPaths re-reads the tool input rather than userRuleTarget's return), and the descendant case needs the reverse compare direction. The shell-side siblings (rg pattern with no path argument) remain documented holes behind the classifier's existence hint (ADR-0002 amendment).