The pi.dev 1.0 Hype Bandwagon, From Inside a Sandbox

On 1 October 2026 the terminal coding agent pi shipped version 1.0 — MIT-licensed, alongside Pi Durable, its substrate for long-running agentic applications — and a very 2026 phenomenon kicked off: the bandwagon. Anyone who has spent a weekend with an agent is suddenly an authority. This article is the counterweight, reporting two things that survive contact with reality: a workshop in which researchers with no development background built CI-validated research repositories, and an adversarial probe of pi's security advice that found both the "recommended" and the "hardened" answers wanting.

The workshop ran on 30 September — the day before 1.0 shipped — at the Max Planck Institute for Multidisciplinary Natural Sciences in Göttingen, as "Agentic AI in der Praxis" (IT4Science Days). Its one hard success criterion: at least 60% of participants leaving with their own CI-validated research repository, green check and all. It held — for reasons that had little to do with the models and everything to do with the harness and spec discipline.

Two applications, one morning

The workshop opened with a deliberate paradox. Application 1 (15 minutes): each participant dropped their own research topic into pi or OpenCode as a single prompt without a scaffold, a repo, or a spec, and watched the agent work. The results were impressive — and unusable. Three questions exposed why: checked? citable? repeatable? — and the demo fails all three. A pile of highlights, not evidence.

Application 2 (25 minutes): the same topic, same agent, on skeleton-research — a forkable skeleton for a data-driven, self-validating literature review. papers.yaml is the spec; AGENTS.md the contract; CI the test — weekly re-fetches (arXiv, OpenAlex, dblp, Crossref, EuropePMC) that validate. They forked it, set their topic in config/taxonomy.yaml, pushed — and the CI verdict, not the agent's confidence, decided what survived. Each did a miniature OpenSpec change with real pytest behind it — the loop felt, not lectured.

The contrast is the point: the same model produces a highlight-reel in a bare prompt and a reproducible pipeline behind a spec. The difference is the workflow.

The Spec · Contract · Test lens

The organising metaphor was a pyramid:

Level	What it is	Role
Spec (top)	Behaviour as contracts (SHALL/MUST/SHOULD)	source of truth, the why
Contract (middle)	The delta-spec the agent consumes — proposal → design → specs → tasks	the agent's prompt
Test (bottom)	Verification — validate, pytest, CI pass/fail	the objective arbiter

Read as a loop: Spec governs → Contract implements → Tests verify → Spec evolves. A task is done only when verification is green, never on the agent's word.

pi.dev: minimal by design

The harness that carried Application 2 was pi, Earendil Workshop's terminal coding agent — deliberately minimal, deliberately extensible. Our workshop ran on the final 0.99 build; the day after, on 1 October, the project shipped Pi 1.0 (MIT-licensed) alongside Pi Durable, an experimental substrate for long-running agentic applications. That timing — 0.99 in the workshop, 1.0 the next morning — is exactly where bandwagons form, so this piece stays narrow — scoped to what we actually ran (0.99 in the workshop, 1.0 pinned in the sandbox image). Treat 1.0's changelog like every agent claim: verify, or don't believe it.

Pi Durable will fuel the loudest takes: not a second agent but a substrate for long-running agentic applications. A harness opens over a storage backend — memory, SQLite, JSONL, or your own on Postgres — and every step of a run is a task that checkpoints before moving on, so a restarted process resumes unfinished work: a cut-off model request is resent, a tool call reruns only if the tool declares itself safe to replay. That replay rule is the genuinely good idea — decide per tool what a restart does before the first crash. The rest — forking conversations, background compaction, hot-swapped extensions, several humans steering one agent — we did not run, and Earendil calls Durable experimental, the API may change. Noted, not endorsed.

The philosophy, in its own words: "Minimal agent harness — adapt Pi to your workflows, not the other way around." Minimal is appealing — and precisely what you must test yourself. pi is the terminal lane of the 2026 agent wave; the editor lane is just as crowded, and Zed makes the strongest open-source case: an agent panel built in, MCP support, no provider lock-in — Ollama, LM Studio and llama.cpp work out of the box. Zed's local-model usage tripled in ten weeks this spring: same models, your hardware, your data.

What that means in practice:

# install (or: npm i -g --ignore-scripts @earendil-works/pi-coding-agent)
curl -fsSL https://pi.dev/install.sh | sh

# minimal by default: four tools, no sub-agents, no plan mode
pi install git:github.com/tobias-weiss-ai-xr/pi-saia-plugin   # GWDG/SAIA models
pi install npm:opencode-ponytail                              # YAGNI as a skill

Ask pi itself (abridged):

The transcript as a terminal graphic — one pane with the session's hotkeys, commands and the sandboxing tip.

pi deliberately skips opinionated features: no sub-agents, no plan mode — you add capabilities (extensions, skills, themes) via npm/git packages, or ask pi to build the feature and hit /reload. The honest trade-off: pi performs no sandboxing of its own — it runs with your permissions. More in a moment.

What sandboxing pi taught us

The workshop was the constructive half; this is the sceptical half, probing the question we'd deliberately dodged: how do you give an agent real credentials and still sleep at night? The pi-sandbox repo runs a fixed escape-attempt probe across Windows, Linux and macOS hosts, then the real product, then a genuine exfiltration attempt. The baseline: an unsandboxed pi session reads six secret-shaped env vars (eight on the Linux host), your real SSH key and pi's ~/.pi/agent/settings.json credential store, writes outside the workspace, and reaches the open internet. Pi's own docs agree: "watching the transcript, using project trust, and reviewing changes do not create a security boundary".

Three results reframe the usual advice:

1. Mounts, not Docker, decide exposure. Documented recommended mounts hide every host secret — until you also mount host ~/.pi/agent or ~/.ssh (the docs' #1 warning) and the real key appears inside.
2. Network-open runs leak, measured. With the standard single-key setup, an in-sandbox process holding that key POSTed it to a synthetic attacker collector — LEAK-CONFIRMED; --network none blocked the delivery. The recommended setup is safe only against accidental leaks: a deliberately malicious agent or extension exfiltrates the one real key passed via -e.
3. Hardening has a catch the probe can't see. --network none --read-only --tmpfs /tmp fixes the probe, but pi crashes on startup: a read-only root makes the session directory unwritable (ENOENT mkdir /root/.pi/agent/sessions). A writable tmpfs home boots, but without egress it cannot reach a remote model. Hardening is per-task: offline → hardened; network-bound → accept egress, one scoped key per task.

Boundary	Whole pi?	Egress	Credential story	Today
Direct on host	—	open	all exposed	runs (the threat)
Docker, recommended mounts	yes	open	hidden by default	✅ tested
Docker hardened (+ writable home)	yes	none	hidden	⚠️ offline only
Docker Sandboxes (sbx)	yes	managed	key stays on host	❌ not installed
OpenShell (fs/proc/net/cred/inference)	policy	policy	policy	❌ not installed
Gondolin micro-VM	bash/tools only	open	inherits host env	❌ QEMU missing
sandbox-runtime extension	bash only	allowlist	none	⚠️ bash-jail

Two rules matter more than any single flag. Extensions, custom tools and hooks run inside pi's process — a container confines them all, while bash-only wrappers (Gondolin, sandbox-runtime) leave read/write/edit and SDK extensions on the host with full access. stdio MCP servers are pi's children; remote MCP is just network, off with --network none. When a plugin needs a host-only service, forward one port instead of mounting the host (the repo's socat pattern). The pattern we ship is boring on purpose: plain container, non-root, --cap-drop ALL, --no-new-privileges, never pass real secrets via -e, fetch-only remote so push stays human — and never rely on project trust as a boundary.

Takeaways

Both halves distilled to three lessons; each argues the bandwagon has the wrong emphasis. Pick the harness and the spec, not the model — the model is replaceable monthly; the workflow compounds. Treat agent output as untrusted until CI says otherwise — the Spec · Contract · Test loop turns a demo into evidence; it's how a room of non-developers left with repos they could defend. Sandbox the agent like a hostile actor — the "recommended" Docker recipe leaks, the "hardened" one crashes, and both surprises are cheap to find if you probe instead of assume. Board the bandwagon if you like — just take the sandbox with you.

Everything is public: the workshop repo, the pi-sandbox report, the skeleton-research skeleton, and pi.dev. To reproduce it: fork the skeleton, pick one topic, run both halves bare and spec'd.