Pi Agent Has No Sandbox: Four Community Guardrails That Stop Dangerous Commands

Users of Claude Code are accustomed to high-end models running commands directly with confirmation dialogs. Pi Agent, however, executes bash commands immediately without popups or secondary confirmation. This is not a bug; the official security.md states that Pi has no built-in sandbox —read, write, edit, and bash tools all run with the launching user's permissions. The design rationale is that in-process half-baked sandboxes only create a false sense of security; true isolation should be handled by the OS or containers.

The clean design carries significant risk: a single rm -rf path hallucination or a mistaken git push --force will actually hit the disk. Fortunately, the extension system exposes tool_call interception, and the community has produced several guardrail solutions. The article reviews four approaches.

pi-guardrails: One Package, Four Gates

Mechanism: aliou/pi-guardrails is the most complete solution in the ecosystem. A single installation yields four extensions: guardrails manages file protection policies (.env, private keys, local credentials, database dumps—unauthorized read/write blocked), path-access controls access outside the working directory (allow/block/ask), permission-gate handles confirmation and blocking of dangerous commands, and herdr reports approval status to Herdr.

Highlights: Usability leads by a wide margin. pi install npm:@aliou/pi-guardrails installs everything; first run /guardrails:onboarding interactively guides configuration; /guardrails:settings adjusts anytime; /guardrails:examples adds common presets with one click—no manual config files. path-access ask mode supports one-time, session, and permanent authorization; permission-gate includes a "deny and terminate this turn" option.

Boundaries: Four gates mean a non-trivial configuration surface; the default policies deserve ten minutes of onboarding review before starting work.

Best for: Individual users who want out-of-the-box complete guardrails—install this one and you're covered.

cc-safety-net: Semantic Interception, 13 CLIs Supported

Mechanism: kenryu42/cc-safety-net is a pre-execution guard supporting 13 coding CLIs including Pi. Unlike regex-list components, it parses command semantics—wrapping in bash -c / python -c, reordering arguments—none of it hides the true intent. It covers two risk classes: destructive commands ( git reset --hard, rm -rf dangerous targets, find -delete, etc.) and secret access (SSH private keys, .env, ~/.aws), covering shell, read, edit, write, and search tools.

Highlights: Highest engineering polish. npx one-command install; GUI policy tuning with Standard/Strict/Paranoid presets; official rule packs cover Terraform/AWS/gcloud/Azure; custom rule packs can only add blocks, never disable built-in protections; policy directory .cc-safety-net/ can be committed to git for team and cloud session sharing; explain traces layer-by-layer why a command was blocked; local logs keep audit trails.

Boundaries: Refuses execution at tool-call time but does not enforce filesystem permissions, network egress, or process constraints. Paranoid mode even blocks rm -rf inside the project.

Best for: Developers mixing multiple AI CLIs, and teams needing version-controlled, shared security policies.

pi-permission-system: Policy-as-Config Permission Gate

Mechanism: MasuRii/pi-permission-system ports OpenCode's permission model into Pi. Agents are defined in ~/.pi/agent/agents/<name>.md YAML frontmatter; the permission section centrally declares five gate categories: tools, bash, mcp, skills, special. Glob rules follow "last declaration wins" and support path scoping like read:/home/alice/project/*.

Highlights: "Policy as config"—no popup interaction, declarative rules that are centralized, deterministic, and diffable, suitable for committing to project repos. OpenCode migrants face near-zero migration cost; the README provides a direct concept mapping table.

Boundaries: Rules must be written manually—no interactive onboarding; frontmatter only supports simple key-value and nested maps, not full YAML features (arrays, anchors unsupported), so complex policies must be split across entries.

Best for: OpenCode migrants and engineering teams that prefer "permissions in config files, version-controlled".

Containerization: The Official YOLO Mode Done Right

Mechanism: Official containerization.md outlines three modes: Gondolin extension (Pi stays on host, built-in tools read/write/edit/bash routed into local micro-VM), Plain Docker (entire Pi process containerized), NVIDIA OpenShell (policy-controlled sandbox with file, process, network, credential control).

Highlights: security.md advises: run untrusted repos, unattended generated code, or headless automation in a controlled environment. Gondolin keeps auth on host—sandbox never touches API keys; OpenShell can even keep model keys outside the sandbox, injected via gateway.

Boundaries: Documentation warns: docker run -v "$PWD:/workspace" read-write mounts mean container writes still land on host—"in a container" ≠ "isolated". Do not mount host ~/.pi/agent or sessions, settings, and credentials leak. Another overlooked constraint: extensions follow the Pi process; when host runs Pi with tool-routing extensions, only routed built-in tools enter the isolated environment—other custom extension tools still execute on host.

Best for: Anyone wanting to safely enable YOLO mode. Interception popups prevent "misoperation"; containers prevent "trusting the wrong object".

Combination Recommendations

Pick one interception layer: pi-guardrails for out-of-the-box completeness (best interactive onboarding); cc-safety-net for multi-CLI coverage and team policy sharing (most accurate semantic blocking); pi-permission-system for declarative config (policy in version control).

Do not stack two confirmation-type components on the same layer: tool_call listeners run serially in extension load order; any block return halts the call, and component errors fail-safe to block. Stacking doesn't increase safety—it just asks twice for the same rm -rf, causing confirmation fatigue that drives users away faster than the risk itself.

Daily personal use: guardrails or cc-safety-net Standard; teams commit cc-safety-net policy dir to repo; OpenCode migrants choose permission-system; untrusted code always containerized—YOLO freely enabled.

Pi has no built-in sandbox, no built-in confirmation popup—it hands full tool-call interception capability to the extension layer.