Pi Extensions: thirty-five registered source entry points, and one package documented as source-only

Extensions run with your full user permissions

The one warning in the documentation is also the most important line in it. Extensions for this agent run with the permissions of the user who launched them, and the readme's instruction is to review an extension before installing it from any third party. There is no sandbox, no permission prompt per tool call and no capability declaration to inspect. That makes the security model entirely procedural: the package you install has the same access to your machine, your files and your credentials as the terminal you launched it from. It also explains the repeated framing in the project, which is to install only what you need rather than a bundle. A personal setup with eight extensions is a different risk from installing thirty at once, because each one is a separate decision and each one is separately removable. The install surface is small enough to state in full:

pi install npm:@narumitw/pi-goal
pi -e npm:@narumitw/pi-statusline

One publish run, three version numbers that share nothing

The release feed is the clearest statement of how this monorepo versions itself. The three most recent tags are one usage package, one sync package and one subagents package, published within six seconds of each other on the same morning. Their numbers have nothing to do with each other: a zero-series with a double-digit minor, a different zero-series, and a three-series. Each package versions independently because each is published independently, which is the right model for independently installable things and the wrong one for anyone trying to reason about the repository as a single artefact. The root manifest is versioned at zero with a private flag, so there is no root version to track at all. The repository uses changesets for its release notes, so what you would look for in a changelog is one entry per package rather than one entry per release.

One package is documented as source-only while it is also published

Almost every row in every category table ends with the same shape of instruction: a command that installs a package from the registry. One row does not. The subagents package points at its own directory in the source tree and tells you to install from there. That is consistent with the note at the top of the readme, which says published packages use the shared scope and that individual package readmes identify exceptions that are source-only. It is also slightly confusing, because the release feed carries a published tag for that same package. So the package exists on the registry and the documentation does not tell you to install it from there. If you want the published build, you have to work out the command yourself; if you follow the table, you build from source. Worth knowing before you assume a table row is authoritative.

The manifest registers extensions the tables never document

The root manifest contains a list of extension entry points that is longer than the documentation's category tables, and the two do not line up. Each entry points at a package's source file directly rather than at a built artefact, which tells you how the monorepo itself loads them for development. Reading that list alongside the tables surfaces packages with no row anywhere in the readme: an analytics extension, a cache-hit monitor, a pull-request extension, an observability integration, a recall tool, a ticker, a general tool helper and a showcase for the terminal UI kit. That is not a complaint so much as a map. If you are evaluating this repository as a set of building blocks, the manifest is the real index and the readme is a curated subset, which is the opposite of the usual arrangement.

Search over a workspace without embeddings or a vector database

One group of extensions is explicitly labelled experimental and described as subject to change as they are evaluated in real workflows, which is the correct warning for a decision-theoretic layer built on an agent. Three packages sit in that group. One turns the agent's judgement about yes-or-no, fixed-choice and ordered-score questions into typed decisions with validated probabilities rather than free text. One uses that judgement to choose which older history to keep before the agent's own compaction step summarises it. The third is the interesting one for anyone who has already indexed their repository: it searches workspace files with SQLite's full-text search plus a semantic reranking pass, and the description states plainly that it uses neither embeddings nor a vector database. For a repository of a few thousand files that is a defensible trade, and for a very large one it is a question rather than an answer.

A deprecated package with a two-step migration and no atomic swap

The task workflow row carries a note that most readmes would have deleted. A combined workflow package is deprecated, and its replacement is not one package but two, a planning extension and a goal extension. The readme is explicit that there is no atomic replacement from the old one, and it sends you to archived migration instructions kept in a directory at the repository root. It also claims the two replacements can coexist on the runtime, protected by what it calls an anonymous cooperative workflow mutex. That phrase describes a lock with no owner identity, which is a reasonable way to stop two extensions from fighting over the same workflow state, and it is also an unusual thing to publish about your own locking. The pattern is honest: a deprecation with a documented multi-step path rather than a silent removal.

Almost every capability is described as bounded

One word does most of the design work in this repository: bounded. Background jobs started by the subagents extension are bounded. Chat rooms in the local chat extension are ephemeral and stay separate from sessions, prompts and model context. The fleet extension starts a second agent process in a split terminal and connects explicit local sessions for bounded messages and one-turn requests. The compaction extension persists and replays bounded opaque checkpoints. The context management extension offers bounded branch-history recall with branch-local notes. Read together, those descriptions say something coherent about the project's view of an agent: long-running work should be started deliberately with a known scope, background activity should not leak into a conversation, and a model's memory of a task should be a fixed window rather than an open-ended archive.

Editorial conclusion

Pi Extensions suits someone who wants the agent tool they already use to look and behave the way their shell does, and who is willing to install one package at a time rather than adopt a framework. Before you install anything from this scope, read the permission note: these extensions run with your full user rights, so the only review that matters happens before installation. Prefer the registry command over the source path, and note that one package is documented as source-only even though it has published releases. If you are evaluating the retrieval extensions, check whether the search without a vector database is enough for your repository size before reaching for something heavier.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. narumiruna/pi-extensions on GitHub
4. README
5. Releases