Add first-class Pi coding agent support

[gvkhosla]

Problem

Buzz can manage Goose, Claude Code, Codex, and Buzz Agent runtimes, but Pi users currently have to configure a custom ACP command manually. That skips Buzz's runtime discovery, guided installation, onboarding, model switching, and managed-process integration.

Proposal

Add Pi as a first-class ACP runtime using pi-acp:

• discover pi and pi-acp
• offer guided CLI and adapter installation
• expose Pi during desktop onboarding
• preserve Pi's existing credentials, models, extensions, project context, and canonical .agents/skills discovery
• normalize Pi's zero-argument ACP startup
• include Pi in managed process cleanup
• document direct buzz-acp usage

Validation plan

• runtime catalog and argument-normalization tests
• onboarding ordering/selection tests
• ACP model-discovery handshake
• live local relay test where a Buzz mention is handled by Pi and Pi posts a reply through buzz-cli

I have a focused implementation ready and will link the PR here.

[nicola]

came here to ask for it!

[donaldxdonald]

need this!

[wpfleger96]

🤖 hey @gvkhosla — thanks for filing this. Requests like this one are exactly what convinced us to solve harness support generically instead of one runtime at a time.

That work landed in #2773 and ships in v0.5.0: pi-acp can be registered from Settings as a custom harness with no code change, and a one-click Pi preset is now a tiny data-entry PR away if you want to open one. Closing as handled.

[antonioc-cl]

I'd like to add Pi (pi.dev) as a narrowly scoped Tier-2 preset on top of the BYOH architecture merged in #2773, rather than revive the larger runtime-specific implementations in #2257 or #3201.

Before I open that PR, could a maintainer confirm the exact integration contract Buzz wants standardized?

• npm package name and upstream repository
• pinned version
• executable/arguments Buzz should launch
• minimum Node.js version
• whether Pi must also be installed separately or the adapter embeds the Pi SDK
• whether the adapter forwards ACP session/new MCP servers (so Buzz's MCP/reply tooling works without a Pi-specific config bridge)

There are multiple similarly named pi-acp implementations, and #2257 and #3201 used different adapters. Once the preferred adapter is confirmed, I can keep the PR to the preset catalog entry, licensed logo/credits, documentation, and focused tests.

[patrick-xin]

For anyone landing here looking for a working pi-acp to register as a custom harness — I built one that runs against a live Buzz relay and is open-sourced here.

It is a pure custom-harness adapter (zero Buzz source changes — just drop pi.json into custom_harnesses/). What sets it apart from a minimal stdio proxy is that it was debugged through the real failure modes that make a naive adapter silently hang or drop content:

• Model deadlock — once you advertise configOptions, Buzz sends the model via session/set_config_option instead of session/set_model. If you only ACK without applying it, the session stays on the default model and every prompt hangs. The adapter actually resolves and applies the model.
• System prompt forwarding — the systemPrompt from session/new (persona + collaboration rules) is appended to pi's own system prompt via appendSystemPrompt, so @mention / callback / memory rules actually reach the model.
• Tool + reasoning visibility — pi emits tool calls as nested toolcall_end events and thinking as thinking_delta; both are translated to ACP tool_call / tool_call_update and agent_thought_chunk so they render in the UI.
• Resilience — auto-retry with surfaced attempts, a 5-min inactivity watchdog, and an empty-turn fallback so a dead provider never leaves the UI spinning.

It reads the host ~/.pi/agent config directly (your existing models/keys just work). MIT licensed, bilingual README (English + 中文).

Install is two steps: git clone + npm install, then copy pi.json.template into the custom_harnesses/ folder.