Including pi extensions?

[cschneid]

What is the suggested approach to using pi extensions? I have a few that I like, mostly on the UI side of things. But it looks like little-coder ignores any in ~/.pi/ - is that correct? Is there a different location that I should be putting them?

[itayinbarr]

Hey! Thanks for your message, will look into it over the weekend

[itayinbarr]

@cschneid — I owe you an apology for the delay here. I said "will look into it over the weekend" in May and then answered this in code without ever coming back to the thread.

This works now, as of v1.12.0. Your read was right: little-coder launches pi with --no-extensions, which is why ~/.pi/ extensions were ignored. There are three ways in now:

1. --with-pi-extensions (or LITTLE_CODER_PI_EXTENSIONS=1) — drops --no-extensions, so pi discovers its own from ~/.pi/agent/extensions and ./.pi/extensions. This is the one you were asking for.
2. A user extension directory — ~/.config/little-coder/extensions/. Each direct child is one extension (a .ts/.js/.mjs file, or a directory with an index.ts). Loaded after the bundled set, so yours can override ours, and it survives npm install -g little-coder@latest.
3. LITTLE_CODER_EXTRA_EXTENSIONS — a path-delimited list, for one-offs.

/extensions shows what actually loaded and where each one came from, which is the command I'd reach for first if something isn't appearing.

Worth being straight about the tradeoff, since you asked specifically about UI extensions: --with-pi-extensions gives up a real guarantee. The fixed extension set is what keeps cold-start context near 7k tokens and makes behaviour predictable across machines, and with discovery on, a cloned repo can contribute extensions from its own .pi/ directory (pi's trust prompt still gates that code). For UI-side extensions specifically that's usually a fine trade. Option 2 keeps the guarantee and is what I'd suggest first.

One correction to something I said elsewhere on this topic: pi themes were never blocked. --no-extensions gates extensions only; theme discovery is governed by a separate --no-themes flag that little-coder never passes, so themes in ~/.pi/agent/themes have always worked.

Full write-up: docs/extensions.md.