Pi's agent harness ships without a permission system, and that is the point

The Pi agent harness is a monorepo of six npm packages from earendil-works, and the most interesting thing in its README is an admission. Pi ships no built-in permission system. It cannot restrict filesystem, process, network, or credential access. By default it runs with the permissions of the user and process that launched it. The docs say so plainly, then hand you three containerization patterns and move on.

That is a deliberate position, and it is worth arguing about, because most coding agents in 2026 take the opposite stance. Claude Code, Cursor, and the various terminal agents ship approval prompts, allowlists, and sandbox modes, and they market those as features. Pi looks at the same problem and says the sandbox is your job.

What is actually in the repo

The package list is specific. @earendil-works/pi-ai is a unified multi-provider LLM API covering OpenAI, Anthropic, and Google. @earendil-works/pi-agent-core is the agent runtime with tool calling and state management. @earendil-works/pi-coding-agent is the interactive coding CLI. @earendil-works/pi-tui is a terminal UI library with differential rendering, which is the unglamorous piece that decides whether an agent’s output flickers or holds still. There is also @earendil-works/chord, described as a standalone application-composition runtime for services, replicated state, RPC, and plugins, and @earendil-works/pi-telemetry, which publishes vendor-neutral telemetry contracts, a reference adapter, conformance tests, and typed schemas.

The project is MIT licensed. The pi.dev domain was donated by exe.dev. Slack and chat automation live in a separate repo, earendil-works/pi-chat.

None of that is novel on its own. Unified provider APIs are a crowded category. What is unusual is the packaging discipline around it.

The supply-chain section is the real story

Scroll past the feature list and the README turns into a document about npm trust. Direct external dependencies are pinned to exact versions. Internal workspace packages stay version-ranged. The .npmrc sets save-exact=true and min-release-age=2, which blocks any dependency published within the last two days from resolving. package-lock.json is declared the ground truth, and a pre-commit hook blocks accidental lockfile commits unless PI_ALLOW_LOCKFILE_CHANGE=1 is set.

The published CLI package carries its own npm-shrinkwrap.json, generated from the root lockfile, so transitive dependencies are pinned for anyone who installs it. Shrinkwrap generation runs against an explicit allowlist for dependency lifecycle scripts; a new dependency with a lifecycle script fails checks until a human reviews it. CI installs with npm ci --ignore-scripts. A scheduled GitHub workflow runs npm audit --omit=dev and npm audit signatures --omit=dev. Release smoke tests build, pack, and create isolated npm and Bun installs outside the repo before anything gets tagged.

Read that list again. It is a response to a specific threat model: the npm worm, the typosquatted package, the compromised maintainer account, the postinstall script that exfiltrates an SSH key. Treating dependency changes as reviewed code changes is a stance most agent projects have not taken, and it is the opposite of the move-fast posture that coding agents usually ship with.

There is a tension here worth naming. Pi declines to sandbox the agent’s runtime access, then applies extreme paranoia to the dependency graph that the agent runs inside. Those are two different attack surfaces. The first is the user’s own machine and the user’s own judgment. The second is code the user never sees. The project’s bet is that the second one is where the real risk lives.

The containerization escape hatch

The three patterns in packages/coding-agent/docs/containerization.md are worth reading as a design statement.

The Gondolin extension keeps Pi and provider auth on the host while routing built-in tools and ! commands into a local Linux micro-VM. Plain Docker runs the whole Pi process in a local container. OpenShell runs the whole process in a policy-controlled sandbox. Each one trades convenience for a different boundary.

The Gondolin pattern is the interesting one, because it separates the credential from the tool execution. Your API keys stay on the host. The agent’s shell commands run somewhere else. That is a cleaner split than the usual “approve this command?” prompt, which trains users to click yes.

Pi declines to sandbox the agent’s runtime access, then applies extreme paranoia to the dependency graph the agent runs inside.

Session sharing and the data question

The README ends with a request: if you use Pi or other coding agents for open source work, share your sessions. The pitch is that public OSS session data improves agents with real-world tasks, tool use, failures, and fixes instead of toy benchmarks. The tooling is badlogic/pi-share-hf, which needs a Hugging Face account, the Hugging Face CLI, and the share script. The maintainer publishes their own pi-mono sessions to badlogicgames/pi-mono on Hugging Face and links a video walkthrough.

This is a real contribution to the evaluation problem. Benchmarks like SWE-bench measure a narrow slice of agent behavior on curated issues. Actual sessions contain the mess: the wrong file opened first, the test that passed for the wrong reason, the three-turn detour through a bad hypothesis. If that data lands in public, it is more useful to agent researchers than another synthetic eval.

The catch is the same one that dogs every session-sharing effort. Sessions contain proprietary code, internal URLs, and credentials that leaked into a terminal. The README does not describe a scrubbing pipeline. Publishing your sessions to Hugging Face is a manual decision with manual consequences, and the project treats it that way.

What this means for agent builders

Two things are true at once. Pi is a competent, well-factored agent harness in a category that already has strong entrants, and its differentiator is not capability but hygiene. The unified API, the agent loop, and the TUI are table stakes. The .npmrc settings, the shrinkwrap allowlist, and the release smoke tests are not.

For anyone building agents on top of npm, the supply-chain section is a checklist worth copying regardless of whether you use Pi. For anyone shipping an agent to end users, the permission question is the one Pi punts on, and the punt is defensible only if your users can run a container. The README’s own framing, that you should containerize or sandbox if you need stronger boundaries, is an honest answer to a question the rest of the category answers with a prompt that users learn to dismiss.

Pi’s next move is whether the session-sharing effort produces a scrubbing path. Until it does, the public data will come from people comfortable enough with the risk to publish anyway.