Pi extensions¶

ID: pi
Links: Home page · Documentation · Repository
Upstream stars: ⭐ 112,859
Last commit: 2026-10-06
Platforms: 🐧 Linux · 🍎 macOS · 🪟 Windows
Operations: installed · install · upgrade · upgrade_all · remove
purl types: pkg:pi/
CLI name: pi
Issues and PRs: 📦 manager: pi
Source: pi.toml

The extension manager of the Pi coding agent (https://pi.dev), which installs packages that add tools and resources to the agent.

A package is a source spec carrying its scheme, npm:@scope/name or git:github.com/user/repo or a URL or a local path, and that spec is what every verb takes: the listing prints it, and install, remove and the single-package update all accept it, so ids round-trip without translation.

Parsing notes, verified against pi 0.84.2 on macOS:

Bare pi update updates pi itself, not the packages: --self is its documented default when no target is given. upgrade_all therefore names --extensions explicitly, and upgrade_one uses --extension <source>, which was checked to name the package it is given rather than sweeping everything.
The listing is a two-line record, the source spec then the directory it resolved to, under a User packages: heading. Only the first carries the id, so the pattern keys on the two-space indent that the four-space path line and the unindented heading both fail.
The inventory carries no version, only a spec and a path, which is a supported shape rather than a gap: installed_version is optional, the same reading rustup and pyenv settled.
An empty inventory prints No packages installed. and exits 0, so it is honest rather than a failure.

Caution

pi list reports user and project packages together and takes no scope flag, where install and remove both take -l to choose. Run from a directory carrying a .pi/settings.json, the inventory therefore includes that project’s packages alongside the machine’s. Anywhere else it is user-scoped, which is what mpm wants.

What `mpm` adds to `pi`¶

mpm reaches across every manager at once, not pi alone: mpm installed and mpm outdated cover pi alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Your `pi` commands, in `mpm`¶

You already know pi: each operation maps one-to-one onto mpm, in an interface shared by every manager.

To…	With `pi`	With `mpm`
List what’s installed	`pi list`	`mpm --pi installed`
Install a package	`pi install <package_id>`	`mpm install pkg:pi/<package_id>`
Upgrade one package	`pi update --extension <package_id>`	`mpm --pi upgrade <package_id>`
Upgrade everything	`pi update --extensions`	`mpm --pi upgrade --all`
Remove a package	`pi remove <package_id>`	`mpm remove pkg:pi/<package_id>`

Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.

Operations¶

Operation	Supported
`installed`	✅
`outdated`
`orphans`
`search`
`install`	✅
`upgrade`	✅
`upgrade_all`	✅
`remove`	✅
`sync`
`cleanup`
`doctor`

Configuration¶

Ignore pi on the mpm CLI by passing the --no-pi option.
Ignore it for every run in your configuration:
```
[mpm]
pi = false
```
Raise the timeout of all pi calls:
```
[mpm.overrides.pi]
timeout = 900
```

Run mpm config-template pi to print all overridable settings for your configuration file:

[mpm.overrides.pi]
cli_names = [
    "pi",
]
cli_search_path = []
dry_run = false
ignore_auto_updates = true
plan = false
post_args = []
pre_args = []
pre_cmds = []
stop_on_error = false
unmaintained = false
version_cli_options = [
    "--version",
]
version_regexes = [
    "(?P<version>\\d+\\.\\d+\\.\\d+)",
]

Recipes¶

A few jobs you would otherwise script around pi, one mpm command each:

Snapshot and clone a machine: mpm --pi dump pi.toml, then mpm restore pi.toml on the next one.
Export a compliance SBOM: mpm --pi sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation¶

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

None of its operations is privileged.

See privilege escalation for the full policy.

Cooldown¶

State of Pi extensions’s release-age gating, from the cooldown support table:

Status: ❌ None (a source spec names no version, let alone a date)

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

Registry: Pi package sources
Retraction: Upstream withdrawal: a package is a source spec resolved straight from npm or a git remote, so it is withdrawn wherever that source lives rather than through any index pi owns
Publish date: ❌ the listing records a spec and a path, with no version and no date

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --cooldown best-effort opts back in.

Reference traces¶

A collection of raw native outputs captured from the manager’s own CLI and recorded in the bundled definition. If you know Pi extensions well and a transcript below looks wrong, or a newer release changed its output format, report it.

$ pi list
User packages:
  npm:@earendil-works/pi-telemetry
    /tmp/mpm-drive/.pi/agent/npm/node_modules/@earendil-works/pi-telemetry

Version check¶

The version is probed by running:

$ pi --version
0.84.2

and extracted with:

r"(?P<version>\d+\.\d+\.\d+)"

Upstream project¶

Metrics	`earendil-works/pi`
Activity
Popularity
Metadata

Changelog¶

8.0.0 (2026-09-20)
- Add the Pi extensions manager with inventory, install, remove and upgrade of the packages that extend the Pi coding agent.