pi-extensions is a personal collection of terminal coding agent extensions, sorted by how often they get used

A working collection, and the rating system that tells you what to trust

The README opens with a framing that is unusual for a repository of this kind: this is my working collection rather than a single polished suite. Some extensions are part of my daily setup, some are occasional tools, and others are experiments I may change or stop using.

That disclaimer is followed by a rating column on every entry, and the ratings are the most useful thing in the document. There are four core extensions marked with a flame, four marked moderate with an orange circle, five experimental with a flask, six very rare, and two marked not maintained with a prohibition sign, plus one explicitly deprecated with a different marker.

So a reader knows before installing anything how much attention that particular package gets. The four Core entries are the ones the author runs daily. The Moderate ones are occasional tools. The Experimental ones are things being tried. The Very rare ones exist but are almost never used. And the two at the bottom are not maintained, which is different from experimental: experimental means the author is still playing with it, not maintained means it is abandoned.

The table is also sorted roughly by how actively the author uses them, which is stated in the intro, so the ordering itself carries information.

The packages cover a spread of concerns rather than one feature. pi-minimal-footer is a minimal footer with a context gauge and subscription usage bars. pi-session-recall searches and queries past sessions, framed as remember when we tried X. pi-auto-permissions provides context-aware Bash permissions with automated guardian review. pi-codex-subagents adds session-scoped subagents with templates, waits, steering and a live overlay. pi-codex-compaction brings native OpenAI Codex compaction, with Pi 0.84.4 or newer resuming in-run and a safe fallback for older Pi. pi-herdr-worktree-jump moves the active session into a new Herdr worktree or back to its main checkout. pi-anthropic-image-cap trims old images from Anthropic requests so image-heavy sessions do not hit the 32 MB limit.

The rest are narrower. pi-quit-and-delete adds a keyboard shortcut to quit pi and permanently delete the active session file. pi-ssh-tools toggles explicit SSH tools on demand through an /ssh command without replacing the local tools. pi-fork-plus forks from the session tree, including editable assistant-message forks. pi-herdr provides Pi-native tools for Herdr layouts, terminal panes and coding agents. pi-model-agents loads model-specific AGENTS.md instructions based on the active pi model, and pi-model-thinking auto-sets and remembers thinking levels per model. pi-ghost is an ephemeral side conversation overlay, a temporary ghost session inside the current pi UI. pi-ghostty-theme-sync syncs the pi theme with Ghostty terminal colors. pi-sketch is visual sketching in the terminal. pi-tmux is tmux pane management, noted as largely superseded by Herdr. pi-worktree relocates the active session to a git worktree while preserving conversation history. pi-goal is a long-running goal mode with automatic linked-session handoff. pi-handoff transfers context to a new session with a full briefing. And pi-web-browse is deprecated, with the pointer to a separate agent-skills repository for web browsing.

Installing one extension, and what the monorepo actually publishes

Installation is one command, and it takes the package name rather than a path:

pi install npm:@ogulcancelik/<package-name>

The npm: prefix is what tells pi to fetch the package from the registry rather than from a local directory, and the placeholder is the package name from the table, so pi install npm:@ogulcancelik/pi-session-recall installs the session recall extension.

That the packages are published to npm rather than being installed from this repository is worth noting for two reasons. It means the extension you install is a published artefact with its own version, and it means the git history of this monorepo is not what you get. The README also says to see each package's README for setup and usage, which is the instruction that matters, because the monorepo README is a catalogue and not a manual.

The repository structure is a pnpm-style workspace monorepo. The package.json is marked private, so it is not itself published, and the workspaces array globs packages/*. The interesting part is the pi key, which is the manifest's own extension registry:

  "pi": {
    "extensions": [
      "./packages/pi-anthropic-image-cap/index.ts",
      "./packages/pi-auto-permissions/index.ts",
      "./packages/pi-codex-compaction/index.ts",

Each entry points at a TypeScript source file inside the package, which is what pi loads when you run it from a development checkout. The list is not the same as the README table, and the differences are revealing.

Two extensions appear in the manifest and not in the table: pi-flicker and pi-spar. And pi-handoff is registered as ./packages/pi-handoff/handoff.ts rather than index.ts, and pi-session-recall as ./packages/pi-session-recall/session-recall.ts rather than index.ts. So the entry point file name is not uniform across packages, which is the kind of small inconsistency you find in a collection that grew by addition rather than by a template.

There is also a skills array, separate from extensions, with a single entry pointing at ./packages/pi-web-browse/SKILL.md. That is the deprecated web browsing extension, registered as a skill rather than as an extension, which suggests the two mechanisms in pi are related but not identical.

The devDependencies are the pi packages themselves at ^0.80.10, three of them: pi-ai, pi-coding-agent and pi-tui. And @sinclair/typebox at ^0.34.0, which is a schema and validation library, so at least one extension declares structured schemas that pi can act on.

The four Core extensions and the problems they solve

The Core group is where the author's actual daily workflow lives, and reading it as a set tells you what a heavy user of a terminal coding agent ends up needing.

Context visibility comes first. pi-minimal-footer is a minimal footer with a context gauge and subscription usage bars. Both numbers matter for different reasons: the context gauge tells you how full the model's window is before it silently truncates, and the subscription usage bar tells you how much of your metered allowance is gone. Neither is exotic, and both are the kind of information you check constantly.

Then the memory problem. pi-session-recall searches and queries past sessions, which addresses the question remember when we tried X. A terminal agent has no memory between runs, so the answer to that question normally means grepping through whatever you saved, and this extension makes the past sessions queryable.

Permissions are the third. pi-auto-permissions provides context-aware Bash permissions with automated guardian review, and context-aware is the operative word. A permission system that asks about every command is unusable; one that infers from context and has a guardian review the approval asks about commands rather than rubber-stamping them.

Subagents come next, in pi-codex-subagents, which are session-scoped with templates, waits, steering and a live overlay. The features describe the coordination problem: templates for a repeatable task shape, waits for a subagent to finish, steering to redirect a running one, and a live overlay so you can see what it is doing rather than waiting blind.

Context management is pi-codex-compaction, native OpenAI Codex compaction, where Pi 0.84.4 or newer resumes in-run and older Pi gets a safe fallback. Compaction is what keeps a long session going: the conversation gets summarised so the important parts survive. The version condition and the fallback are notable because they mean the extension degrades rather than breaks on an older pi.

Then pi-herdr-worktree-jump, which jumps the active session into a new Herdr worktree or back to its main checkout. That is about isolation: running an agent in a worktree means the changes it makes do not land in your working tree until you have looked at them.

And pi-anthropic-image-cap, which trims old images from Anthropic requests like Claude Code so image-heavy sessions do not hit the 32 MB limit. It is a request-shaping extension, and the 32 MB limit is a concrete API constraint rather than a preference.

The abandoned and deprecated entries are still in the registry

The bottom of the table is worth reading closely, because it shows how the author handles things that stopped working.

pi-goal is a long-running goal mode with automatic linked-session handoff, marked not maintained. pi-handoff transfers context to a new session with a full briefing, also not maintained. And pi-web-browse is marked deprecated with an explicit pointer: use the agent-skills repository for web browsing.

The interesting decision is that these packages remain installable and remain registered in the manifest. pi-goal/index.ts and pi-handoff/handoff.ts are both in the pi extensions list. So the registry advertises the full history, and the README tells you which parts of that history is dead.

That is a defensible approach for a personal collection, where removing a package would break anyone whose setup referenced it, and it is the approach that makes the rating column worth having. If a not-maintained package had been deleted, the reader would have no way to know it existed and would have to search for it.

The deprecated one is different in kind. pi-web-browse is not merely unmaintained, it has been superseded by a different mechanism in a different repository, and the README says so and gives the link. And the migration is visible in the manifest too: the package is still present, but it is registered under the skills array rather than the extensions array, alongside the SKILL.md file inside it.

Two things follow for someone adopting these. The extension list in the manifest is not a curated set, it is a complete inventory including the dead parts, so a script that reads it will load extensions the author does not recommend. And the packages listed in the manifest that are not in the README table, pi-flicker and pi-spar, have no description anywhere in the documentation available here, so you would be installing them on the strength of the name alone.

Where this collection is the wrong dependency

Three limits, and the first is about what a collection is.

The first is that it is one person's setup. The README says so directly: some extensions are part of my daily setup, some are occasional tools, and others are experiments I may change or stop using. There is no compatibility matrix, no support policy and no release cadence for the packages themselves. The repository has no GitHub releases, the top-level entries are just a .gitignore, a LICENSE, a README, a package-lock.json, a package.json and the packages/ directory, and the licences are MIT.

For a personal machine where you read the code before you install it, that is fine and is in fact the point. For a team standardising on pi, or for a package you intend to build on, it is the wrong shape. You would want a curated set with versioned releases, and the closest thing to that here is the Core group, which is one person's judgement rather than a committee's.

The second is the version coupling to pi itself. The devDependencies pin the pi packages at ^0.80.10, and one extension explicitly requires Pi 0.84.4 or newer for its in-run behaviour with a fallback for older versions. That kind of version check inside an extension is a warning sign, because it means the extension is tracking a fast-moving host API. A terminal coding agent that ships breaking changes regularly will break extensions that were written against an earlier interface, and there is no compatibility layer here beyond that one fallback.

The third is that the extension mechanism itself has two faces. The manifest registers most packages under extensions pointing at a TypeScript file, and one under skills pointing at a SKILL.md. Those are different kinds of integration, and the deprecated package shows a migration between them. If you are an extension author, the practical question is which mechanism to target, and the answer changes with the pi version.

The alternative approach is to write your own extension, which for a project like this is a realistic option, because the pi packages are published as ordinary npm dependencies and the extension format is a TypeScript file you point the manifest at. The difference in approach is that this repository saves you the discovery work and gives you implementations that have been used daily, while writing your own gives you exactly the behaviour you want and no version coupling. The author's own framing, a working collection rather than a suite, is a fair description of what you are adopting.

Editorial conclusion

Adopt pi-extensions if you already run pi as a terminal coding agent and want the author's own workflow around it, because each package installs with one pi install command and the Core set covers session recall, context-aware permissions, compaction and image trimming. Do not adopt it as a curated extension registry, because the README describes it as a working collection rather than a polished suite, and several entries are marked not maintained or deprecated. Verify first that the extension you want matches the pi version you run, since the compaction package requires Pi 0.84.4 or newer and falls back for older versions, that you read the per-package README before installing anything marked Experimental, because the author says those may change or stop being used, and that the packages are pulled from npm rather than from this repository, so the version you get is whatever was last published under that package name.

Frequently asked questions

Official sources

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