pi-extensions: a monorepo of installable extensions for the Pi Coding Agent
A monorepo of Pi Coding Agent extensions
At a glance
- What is it?
- The repository publishes independently installable Pi Coding Agent extensions under the @narumitw npm scope, from LSP diagnostics to Codex compaction. The design bet is granularity: install only the pieces you want, and accept that each one runs with your full user permissions.
- Who is it for?
- Adopt pi-extensions if you already run the Pi Coding Agent and want one capability at a time, installed with pi install npm:@narumitw/<package> rather than a bundle. Do not adopt it if you are not on Pi, or if you cannot review third-party code that runs with your full user permissions.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What pi-extensions is for, and who ends up installing it
Pi Coding Agent extensions are the unit of distribution here, not one big plugin. The README frames the repository as a collection of "independently installable" extensions plus reusable extension libraries, covering coding, research, browser automation, workflow management, observability and terminal ergonomics. The organising instruction is short: install only what you need.
That matters because the packages solve unrelated problems that happen to share a host. pi-lsp adds language-server diagnostics and code actions across JavaScript, TypeScript, Python, Rust, Go, Ruby, C/C++, JVM, .NET, Swift, shell and infrastructure formats. pi-usage answers a question about your Codex subscription limits or OpenRouter API-key spend. pi-caffeinate stops the machine sleeping while a long prompt runs. pi-starship matches Pi's footer to a Starship shell setup. There is no single user for all of them; the audience is someone who already lives in Pi and wants to fill a specific gap.
The README also lists what the author calls extensions used every day, including pi-btw for side questions that should not pollute the main context, pi-accounts for switching named subscription OAuth accounts, pi-sync for pushing configuration across devices through S3, and pi-stamp for per-response details such as timestamps. Treat that as a curated shortlist from the maintainer, not a quality ranking of the rest.
The monorepo layout and how packages reach you
The repository is a TypeScript monorepo. The README links each extension to a directory under packages/, for example ./packages/pi-btw, ./packages/pi-codex-compact and ./packages/pi-statusline, and each of those directories carries its own README. Published packages use the @narumitw npm scope; the README notes that package READMEs identify source-only exceptions. pi-subagents is one such exception, pointing to an install-from-source section instead of an npm command.
That split is the first thing to check before you install anything. A package listed in the tables with a pi install command is fetched from npm. A package that only links to a source install has to be built or cloned, and the repository does not pretend otherwise.
There is also a deprecated path. The combined pi-workflow package is described as deprecated with no atomic Plan-to-Goal replacement, and the README directs readers to archived migration instructions in ./deprecated/pi-workflow/README.md. Current Plan and Goal releases can coexist, according to the README, through what it calls an anonymous cooperative workflow mutex. If you were running pi-workflow, the migration is a manual read of that archived document, not a drop-in swap.
Running it: install commands and the permission warning
The README gives three patterns. To install an extension permanently:
pi install npm:@narumitw/pi-goal
To try one without adding it permanently:
pi -e npm:@narumitw/pi-statusline
To combine several for a single run:
pi -e npm:@narumitw/pi-goal \ -e npm:@narumitw/pi-statusline \ -e npm:@narumitw/pi-lsp
The -e flag is the low-commitment path and the one worth using first, since it lets you evaluate an extension without writing it into your setup.
The README carries an important note in its own callout: Pi extensions run with your full user permissions, and it advises reviewing an extension before installing it from any third party. That is a plain statement of the trust model. An extension is not sandboxed by the host as far as this material indicates. If you would not run an npm package's install scripts on your machine, the same reasoning applies here, with the added wrinkle that these extensions are wired into an agent that is already acting on your files.
Some packages expose their own entry points once installed. pi-file-context opens with a configurable Ctrl+Shift+X or the /file-context command. pi-usage, pi-accounts, pi-analytics and pi-codex-compact document slash commands (/usage, /accounts, /analytics, /codex-compact). pi-btw is invoked as /btw. The exact config keys for each are in the individual package READMEs, which this material does not reproduce.
Where the design gets awkward: overlap, credentials and version drift
Two packages in the accounts and data group touch the same surface. pi-accounts switches named OpenAI Codex, Anthropic, GitHub Copilot, Kimi For Coding, OpenRouter, Radius and xAI OAuth accounts. pi-usage reads current-account Codex subscription limits or OpenRouter API-key spend limits. They are complementary, but both sit on top of your provider credentials, and both are the kind of extension where a bug is a credential-handling bug rather than a cosmetic one. The README's permission warning applies with more force here than it does to pi-starship.
Version drift is the second friction point. The release list shows packages versioned independently: pi-stamp at 0.51.0, pi-btw at 0.58.1, pi-usage at 0.60.7, all within days of each other. Independent versioning is the point of the monorepo, but it means there is no single version number you can quote for "the pi-extensions release I am on". Reproducing a setup across machines means pinning each package name individually, or using pi-sync, which the README says syncs allowlisted Pi settings and optional sessions through Cloudflare R2 or S3-compatible storage. Note the word allowlisted: pi-sync is not a blanket copy of your configuration.
The third awkwardness is the one the README admits to directly. The deprecated pi-workflow package has no atomic replacement. Anyone who relied on the combined Plan-then-Goal flow has to reconstruct it from pi-plan-mode and pi-goal, and the README points at archived migration instructions rather than offering a command. That is a real cost, stated rather than hidden.
How this compares with a single all-in-one agent plugin
The obvious alternative is one plugin that ships every capability at once: LSP, browser control, usage reporting and status line in a single install. That approach gives you one version to track and one upgrade to run. pi-extensions takes the opposite position, and the README states it as a principle: install only what you need. The practical difference is blast radius. A broken status-line extension and a broken credential-switching extension are not the same incident, and separate packages let you keep the first while removing the second.
The cost is discovery and assembly. You have to read a table of roughly two dozen packages, decide which ones matter, and manage several version numbers. If your team wants a fixed, auditable set of tooling with one changelog, the granular model is more bookkeeping than you asked for. If you want to add browser automation through pi-chrome-devtools or pi-firecrawl without also pulling in a workflow manager, it is less.
A second comparison point is scope. Several of these extensions delegate to an external service rather than implementing the capability themselves. pi-firecrawl scrapes and crawls through Firecrawl. pi-langfuse sends agent runs, generations, token usage, costs and tool activity to Langfuse. pi-github-pr reads pull request checks and reviews through the authenticated gh CLI. pi-sync writes to R2 or S3-compatible storage. Adopting those packages means adopting those dependencies and their accounts, not just an npm install.
Maintenance, versioning and the MIT licence
The repository is MIT licensed, which is permissive and imposes few obligations on how you use or redistribute the code. That is a statement about the licence text, not legal advice; if you are vendoring packages into a product, read the LICENSE file in the repository and the licence field of each published package yourself.
Maintenance signals visible in this material are the release cadence and the version numbers. Three releases land on consecutive days in September 2026 (pi-stamp 0.51.0, pi-btw 0.58.1, pi-usage 0.60.7), and the repository's last push timestamp is the same day as the pi-stamp release. The minor versions are high and the patch versions keep moving, which is consistent with active iteration on packages that are still settling. The deprecated pi-workflow package is the counter-example: it is kept in the tree with archived migration instructions rather than removed, so the repository carries some historical weight.
Upgrade cost depends on how you installed things. With pi install, upgrading is per package. With pi -e, nothing persists and you re-specify the package each run, which means an unpinned name can resolve to a newer version than the one you evaluated. Pin versions explicitly if you care about that. The README does not describe a bulk upgrade command, and this material does not show one.
What to verify before you commit to a package
Start with the package README under packages/, not the top-level table. The table tells you what a package is for; the package README is where install exceptions, config keys and command names live. pi-subagents is the clearest case, since it has no npm install line at all.
Next, confirm whether the package you want is published or source-only. The README says published packages use the @narumitw npm scope and that package READMEs identify source-only exceptions, so the presence of an npm name in the table is your signal. If it is missing, plan for a build step.
Then decide between pi install and pi -e. For anything touching credentials, browser sessions or your configuration store, the -e trial path lets you watch behaviour before it becomes permanent. Given the README's own warning that extensions run with full user permissions, that trial is the cheapest review you can do.
Finally, check the release list for the package you are adopting and note its current version. With packages versioned independently and moving quickly, a setup that works today is a set of pinned package names, not a repository state.
Editorial conclusion
Adopt pi-extensions if you already run the Pi Coding Agent and want one capability at a time, installed with pi install npm:@narumitw/<package> rather than a bundle. Do not adopt it if you are not on Pi, or if you cannot review third-party code that runs with your full user permissions. Before installing anything, read that package's own README under packages/, check whether it is a published npm package or a source-only exception, and confirm the version you are pinning against the release list.
Community notes