Pi leaves command permissions to your environment
Start Pi inside a repository and its commands inherit the rights of the process that launched it. The README's permission warning makes the adoption decision unusually clear: you supply the boundary around the agent. That's a reasonable bargain for a developer who wants control over tools and model providers. It's a poor default for a team expecting every consequential command to require approval.
The word "minimal" describes Pi's product choices. Our checkout contained 1,986 files and roughly 412,591 lines of source across a TypeScript monorepo. The CLI sits alongside libraries for model access, agent execution, and terminal interfaces. You can use the terminal, automate through print or JSON output, control a process over RPC, or embed the SDK. That breadth helps explain why customizing Pi can become application development.
What happened when we ran it
Our run installed 323 npm packages in 32 seconds and built Pi in 19 seconds. We cloned commit 42a3497 on October 10, 2026, into a fresh, unprivileged Debian container using lab-node:22, without secrets. The checkout occupied 24.3 MB. Installation and compilation succeeded, so the repository cleared those basic setup steps on the environment we actually used.
The test command exited 1 after 459 seconds. The supplied summary reports 91 passed and 0 failed out of 91 Vitest tests, but the log tail also shows a group with 5 failed test files and no tests collected. Separate passing groups report 55, 43, 133, 44, and 15 tests. Those fragments don't establish a single complete-suite total. They show passing tests alongside a failed overall command, without revealing the underlying exceptions.
Npm audit reported 2 known vulnerabilities, both high severity, with none classified as critical, moderate, or low. The supplied results don't name the packages or describe exposure. Our scan also found 13 CI workflow files, workspace configuration, no Dockerfile, and no tests directory. The absence of that directory doesn't mean there are no tests: the command output plainly records them.
The installer pins more than the npm route
The 485 MB installed footprint is modest enough to budget explicitly for a development container, but it excludes any model service you choose to run. Pi requires Node.js 22.19 or newer. Its managed installer pins transitive dependencies, while the README says a direct npm installation doesn't. The documented npm command uses --ignore-scripts. For a shared rollout, I'd choose one installation route and pin it across the team.
Run /login to connect a supported subscription or API key before asking a hosted model to work. Provider access is separate from getting the CLI running. The source build normally refreshes model data, while build:offline uses existing data. That distinction matters behind restricted networks. The sandbox result proves the supplied build passed, without establishing that every offline, provider-authentication, or platform path works.
Extensions give you the workflow Pi omits
A successful 19-second build gets you a harness whose README deliberately omits built-in plan mode and subagents. TypeScript extensions can register tools and commands, respond to events, and change session context. Skills and prompt templates cover instruction changes. This suits a team with a particular review loop it wants to encode. If you're only trying to avoid configuring another coding assistant, extension work is an additional job.
The extension documentation says extensions run inside Pi with its operating-system permissions and can inspect credentials and history. A confirmation hook can block a tool call, but loading that hook is itself a trust decision. Treat a shared Pi package as executable code. I'd keep a reviewed extension set rather than ask every developer to assemble a different agent from npm.
Tool isolation can leave extension tools on the host
Our sandbox had 3 CPUs and 8 GB of RAM, with no secrets and no elevated privileges. Those conditions explain where the setup findings apply. They don't establish that Pi protects a normal workstation. The containerization guide distinguishes isolating the whole process from routing selected tools elsewhere. That distinction matters because an extension can perform work outside the routed tools.
Plain Docker puts Pi and its extensions inside the container, although writable mounts still expose host files. Gondolin keeps Pi on the host and sends built-in tools into a micro-VM. Other extension tools stay on the host unless they delegate too, and VM commands inherit host environment variables. OpenShell supplies policy-controlled isolation. Choose based on which files and credentials commands can actually reach, then inspect the mounts and environment.
A current push doesn't make the failed suite green
Our scan found 13 files defining CI workflows, but the complete test command still failed. Separately, GitHub showed a last push on October 11, 2026, 114,229 stars, and 325 open issues and PRs combined. Release v1.1.0 shipped October 7. Recent reports include an Anthropic image-error rejection, with pull request 10795 proposing a fix. That's active maintenance with unfinished work.
Pi auto-closes new contributors' issues and PRs, then reviews submissions for reopening. A closed report therefore doesn't necessarily mean a fix shipped. Its MCP client supports stdio and streamable HTTP, but explicitly rejects legacy SSE. If existing tools only offer SSE, migration is part of adoption. The permission boundary and that transport limitation are concrete reasons to choose another agent, even when you like Pi's extension API.
OpenCode includes planning, while Aider centers Git
The 459-second failed test step makes me cautious about adopting Pi as an unattended default. OpenCode includes a read-only plan agent and a general subagent. Aider emphasizes a repository map and automatic Git commits. Choose Pi when you specifically want to own the agent's behavior. Before it works on a valuable checkout, decide which host files its commands may change and which credentials its extensions can read.