prototype: Goose agent type over ACP - #1010

Draft prototype: a bundled Goose agent type that runs goose locally over ACP. Built on goose's MCP-over-ACP support in aaif-goose/goose#12882.

What it does

• One goose-acp process per agent, one ACP session per conversation. That's a thread, a whole DM, or a channel when the agent is set to one session per channel. A quiet session closes after 15 minutes. Watch and timer wakes each run in a one-off session.
• Buzz tools over MCP-over-ACP.
  • Each session declares {type:"acp", name:"buzz", serverId:"buzz"} in both mcpServers and _meta.enabledExtensions, alongside goose's developer extension.
  • goose sends mcp/message requests back over the same pipe, and the plugin answers them with the in-process respond() from buzz-mcp. Calls are signed by the agent's native-held key, so goose never holds a Buzz key.
  • BUZZ_PRIVATE_KEY, BUZZ_AUTH_TAG and BUZZ_RELAY_URL are removed from goose's environment.
• Buzz prompt. It reuses the Claude plugin's systemPrompt(): the base prompt, the Buzz tools prompt, the session model, attention, memory and instructions. It's applied after session/new with _goose/unstable/session/system-prompt/set, mode: "append". Append keeps goose's own system.md, which carries the extensions' tool instructions; set would drop that and render our text as a template.
• Session titles. _meta.sessionTitle is sent as Agent · #channel · <root8>, matching the harness format. goose's own session naming is off (GOOSE_DISABLE_SESSION_NAMING).
• Steering. A message that arrives mid-turn goes through _goose/unstable/session/steer with the turn's _meta.goose.activeRunId as expectedRunId. If it arrives before goose reports the run ID, it waits for it. If the steer is rejected because the turn just ended, the message runs as the next turn.
• Finishing. A successful send with final: true settles the turn. If goose only writes text and never calls a Buzz tool (for example, when it reports a provider error), the turn fails and the text is posted as "⚠️ I couldn't finish that: …". Otherwise nobody would see it.
• Provider and model come from ~/.config/goose/config.yaml. An agent can override them in its settings, which sets GOOSE_PROVIDER / GOOSE_MODEL. goose runs with GOOSE_MODE=auto, and permission requests are answered with allow.

Not in this prototype: bundling goose-acp, a provider/credentials dialog, a model catalog or per-message picker, transcripts, session resume across restarts, and Windows.

How to test

1. Build goose-acp from prototype: serve client tools over MCP-over-ACP aaif-goose/goose#12882. Run a whole-workspace build from the goose checkout root:

   cargo build --profile lean --bin goose-acp

   Don't add -p goose. That skips features other workspace crates enable, and the resulting binary can't reach the provider ("Network error: Could not connect to …").

2. Put it on the app's PATH as goose-acp. The app checks ~/.local/bin first on macOS. If a goose-acp is already there, remove it first rather than copying over it:

   rm -f ~/.local/bin/goose-acp && cp target/lean/goose-acp ~/.local/bin/goose-acp

3. Check that goose works with your config, for example goose run -t "say hi". This prototype adds no provider setup.

4. In the app (macOS or Linux desktop): run with just desktop

   1. Create a Goose agent. Leave Provider and Model empty to use your goose config.
   2. @mention it in a thread. It should show steps (shell, send, …) and reply in the thread.
   3. Send a second message while it's still working. That message should be folded into the same turn, not answered separately.

Checks

• tsc --noEmit and biome are clean.
• vitest run src/bundled src/plugins src/features/agents: 2,640 passed. The new goose suites run against a fake goose-acp speaking ACP.
• cargo test -p buzzodz-plugins passes.
• Live tests (above) pass against the #12882 build with a Databricks provider.
• Not yet done: a human run in the app.

🤖 Generated with Claude Code