Pi Open-Source Coding Agent: Why MCP, Subagents, and Plan Mode Are Not Built In
Editorial standards and source policy: Editorial standards, Team. Content links to primary sources; see Methodology.
Last checked: 2026-07-27.
While other coding agents add features, Pi deliberately subtracts them
Pi Agent Harness is an open-source project under the MIT license, with its official repository at earendil-works/pi. A harness is the runtime skeleton connecting a language model, tools, and a terminal interface. Pi does not try to become the platform that makes every workflow decision for a team.
Its defining choice is to omit built-in MCP, subagents, permission popups, plan mode, to-do lists, and background bash. MCP here means Model Context Protocol. Teams can add those capabilities through extensions, files, tmux, or a sandbox. The trade-off is equally important: Pi runs with the invoking user permissions by default, so the user owns the isolation boundary.
| What Pi keeps in the core | Main role |
|---|---|
pi-ai |
A unified interface for providers such as OpenAI, Anthropic, and Google |
pi-agent-core |
The agent loop and core runtime state |
pi-coding-agent |
The command-line entry point for coding work |
pi-tui |
The terminal user interface |
Source image: the Pi Agent Harness official site, accessed 2026-07-27. Project identity, philosophy, and installation details are checked against the site and repository README.
What “not built in” means in practice
Many coding agents ship an opinionated workflow: create a plan, start several subagents, prompt for command permissions, maintain tasks, and manage background processes. Pi keeps the core smaller. A team can store plans in files, use tmux for background work, connect protocols through extensions, and run commands inside Docker or another sandbox.
This is attractive to teams that already have engineering conventions. They can adopt the model loop without replacing their permission model, orchestration, and terminal habits. It is not the same as being secure by default. If the invoking user can read credentials, modify the main repository, or access an internal network, Pi and any loaded extension may reach those resources too.
The official material mentions the Gondolin extension, plain Docker, and OpenShell as isolation choices. They are approaches a team can adopt, not protection automatically enabled by running Pi. The MIT license covers the core repository; community extensions need their own code and license review.
Build an extension inventory before rollout
Pi's composable design means the review surface is larger than the core repository. It includes every extension, hook, external command, and model provider added by the team. A useful extension inventory records the source repository, pinned version, license, install scripts, readable paths, writable paths, network destinations, and an internal owner. A missing field is a reason to keep that component out of a persistent environment.
Break “permission to run commands” into actual capabilities. Reading source, writing a fixture, changing the main branch, reaching an SSH agent, reading cloud credentials, and connecting to an internal network are different grants. Start with a disposable repository and read-only dependency cache, then open capabilities individually. If an extension update expands its permissions, review it again instead of inheriting the previous approval.
The inventory also preserves attribution. A successful run may depend on Pi core, a community extension, the underlying model, or a shell tool. Without the exact combination, the team cannot reproduce the result or identify which layer failed after an upgrade.
Start with the package, not a platform project
The installation entry point is @earendil-works/pi-coding-agent:
npm install -g @earendil-works/pi-coding-agent
pi
For a source review, use an isolated environment and run npm install --ignore-scripts, npm run build, npm run check, and ./test.sh. Recheck npm before documenting an exact package version; a time-sensitive article should not freeze a version that may already have changed.
Internal CLI team: 3 files, 2 hooks, and 1 container
A sensible pilot does not need a production repository. Create a disposable fixture with 3 files, add 2 hooks whose inputs and outputs are logged, and execute every model-suggested command inside 1 container with no host credentials.
The useful questions are basic: did an extension write outside the fixture, did both hooks leave enough logs, and could the team roll back completely after failure? Stop if host secrets appear inside the container, an extension requires an unreviewed lifecycle script, or a result from a community fork is attributed to core Pi.
This case captures Pi's audience. It is closer to a box of standard parts for a CLI team: flexible and replaceable, but the assembly quality belongs to the team. An organization looking for a ready-made approval workflow and centralized governance may find the minimalism creates more setup work.
The broader open-source idea
Pi is not arguing that fewer features are always better. It draws a different line between core and surrounding tools: model access and the agent loop stay in the core; workflow, isolation, and background execution live where a team can control them. That is a compelling route for developers tired of large agent frameworks, provided they already know how to review extensions, isolate commands, and preserve logs.