Bundle goose as default agent harness

[jamadeo]

Goal: Package goose in Buzz as the default agent, replacing buzz-agent

Objective: Replace the built-in buzz-agent with goose (https://github.com/aaif-goose/goose/) as Buzz's default bundled ACP agent. Buzz's harness (buzz-acp) is already agent-agnostic - goose is a supported runtime today - so this is primarily a packaging change plus closing a small set of product-feature gaps.

Buzz can use a "lean" build of goose, cutting many optional features in favor of a lightweight ACP-only harness.

Open questions:

Build from source or download release binary?

• Build goose from source (vendored rev or git dependency) in CI. Reproducible and signable as our own artifact, but adds a goose build to every release pipeline. Pros: buzz can opt in/out of build-time features, control supported platforms
• Download binary: this would require goose to publish "lean" binaries for all supported platforms. Buzz would pin to a version

Migrating existing user agent configs

• Managed-agent records (managed_agents.json per community): existing agents with agent_command: "buzz-agent" — do we auto-rewrite them to goose, mark them broken with a guided migration UI, or keep recognizing
  the id as an alias that maps to bundled goose? Auto-rewrite must also translate env: BUZZ_AGENT_MODEL/PROVIDER/THINKING_EFFORT/MAX_* → GOOSE_MODEL/PROVIDER/THINKING_EFFORT/MAX_TOKENS/CONTEXT_LIMIT, and there's
  no goose equivalent of BUZZ_AGENT_MAX_ROUNDS.
• Personas (buzz-persona): runtime: buzz-agent personas emit BUZZ_AGENT_* env vars; snapshots/exports (buzz-agent-snapshot v1 format — note the format name survives, it's agent-definition export, not the agent)
  may embed the runtime id and be re-imported on other machines. Import path needs a mapping or rejection policy.
• Provider/model settings: users configured on Databricks via buzz-agent's picker — does their model selection carry into goose's Databricks provider (different model-id namespace? databricks_v2 vs goose's
  provider naming)? Internal builds baked BUZZ_BUILD_BUZZ_AGENT_PROVIDER/MODEL defaults — what's the goose-equivalent baked default?
• OAuth token caches in ~/.config/buzz-agent/ — migrate, ignore, or clean up? (Reset paths already delete them.)
• K8s/shared-compute descriptors: deployed agents with BUZZ_ACP_AGENT_COMMAND=buzz-agent in cluster state; image contents must include goose, and old pods need a redeploy story.

Rollout

To mitigate the complexity of the above items, should there be a period where goose is packaged and default, but buzz-agent continues to exist and support existing configured runtimes?

[salman1993]

Tested unpatched Goose with its native developer extension, through Buzz’s ACP adapter against an isolated live relay. No buzz-dev-mcp server was injected. Compared with buzz-agent + buzz-dev-mcp on macOS, exercising both Goose’s legacy and state-machine loops.

Pinned revisions: Goose e629eea1dd37b611870cce249974da7849096bc1; Buzz ef2aa1ae38fadcc0bc22b8bf6ed96b35933146be plus local trace instrumentation. These findings are not qualification of the latest release or the proposed lean build.

Ordinary coding, shell execution, channel reads/posts, error recovery and multi-turn context worked. Four gaps remain before making Goose the default:

1. Child processes survive timeout/cancellation — Goose

Stopping a command must also stop the work it started. In both loops, a Python child survived shell timeout or Buzz cancellation and wrote a file later; the baseline prevented that write.

• Likely location: native developer shell.rs::run_command kills the immediate child, not its process tree.
• Reproduce/check: run a shell that starts a child which sleeps, then writes a marker, while the shell waits. Time out after 2 seconds or cancel after startup. Keep Goose running and verify the delayed marker never appears; then verify a new turn still works.

2. Shell capture is unbounded — Goose

A short preview does not mean output is cheap to collect. Goose retained a 17.28 MB stdout artifact where the baseline capped it at 10 MiB. Source inspection shows unbounded buffering before truncation; no OOM was induced.

• Likely location: collect_tagged_lines, split_lines, truncate_output.
• Reproduce/check: emit 160,000 ~108-byte lines without redirecting output. Bound memory and saved files while preserving cancellation. Also test one enormous line. Final previews and live progress are already bounded.

3. Misleading final response after successful publication — Goose + Buzz

Buzz agents often deliver their answer by running buzz messages send. A later empty model response can then produce “Please resend,” even though the answer is already in the channel—inviting duplicate work. Across eight eligible Goose trials, all published the result, but three ended with that warning and one with whitespace. Small sample, not a failure-rate estimate.

• Likely locations: legacy crates/goose/src/agents/agent.rs and state-machine crates/goose-agent/src/inference.rs. Legacy counts whitespace as content; state inference already trims it.
• Check: script successful publication followed by empty/whitespace provider replies. Require an honest terminal outcome without replaying completed work. Goose owns generic empty-response handling; Buzz must define the publication/completion contract. One successful shell call is not proof the whole task succeeded. First-tool-call continuation itself passed.

4. Git identity/signing bootstrap depends on the old tool server — Buzz

buzz-dev-mcp also supplies Git identity, signing configuration and a session keyfile lifecycle. Removing it needs a replacement outside Goose’s generic developer extension.

• Likely locations: Buzz crates/buzz-dev-mcp/src/shim.rs and desktop/src-tauri/src/managed_agents/runtime.rs.
• Important distinction: desktop already configures URL-scoped Git credentials. The direct test bypassed that launcher, so this is not a demonstrated desktop authentication failure.
• Check: through the actual launcher with clean HOME/PATH, clone → signed commit/tag → push → independent readback. Verify identity and key cleanup. Git writes were not tested; inherited helper availability does not establish clean packaging.

Private Buzz lifecycle hooks/todo enforcement were deliberately excluded, not counted as Goose failures. No fixes implemented in this investigation.

[salman1993]

i think the major blockers here are (3) & (4).

(3) because buzz messages send is a very common workflow so sending multiple msgs would be bad.

(4) is needed for all git write operations. the shim prepares the shell environment: it puts Buzz utilities and Git helpers on PATH and, when given a key, configures Git identity, authentication and signing automatically.

then, (1) & (2) are both medium priority

[salman1993]

regarding open questions listed in the issue regarding build/packaging and migrating existing configs:

• i think we should try to get in a goose build along with buzz-agent ASAP & ask some of the team to start using it as daily driver
• if goose seems to be on-par, then we can decide on the migration path. i see two options:
  • we can get rid of buzz-agent when we release the new buzz app (aiming for late Oct)
  • we can put up a migration notice for couple weeks to ask users to move to goose

[jamadeo]

Sounds good. aaif-goose/goose#11961 is unblocked now and I think should be mergeable soon, at which point we can point the buzz build at it.

@salman1993 For the blockers above:

3. I'm a bit confused by the bug description - is it saying that a session had an empty content block, and that triggered something in Buzz prompting the agent to continue in some way?
4. how does this work with other ACP agents?

[salman1993]

for (3) this example transcript might be helpful:

1. Earlier shell call completed: wrote tool-only.txt and printed TOOL_ONLY_7F3A.

2. Model → native shell tool for buzz messages send:

printf 'TOOL_ONLY_7F3A is confirmed. I wrote it followed by a newline to `tool-only.txt`, and the shell printed the marker successfully. @Benchmark User' | buzz messages send --channel <test-channel> --reply-to <user-message> --content - --mention <test-user-pubkey>

3. Shell → Goose: success

{
  "status": "completed",
  "exit_code": 0,
  "stdout": {"accepted": true, "event_id": "ffc9e16a…", "message": ""}
}

The CLI stdout was a JSON string, decoded here for readability. Independent relay readback confirms the answer was posted. The CLI’s "message":"" field is not the empty model response at issue.

4. Goose sends that successful tool result back to the model. The model’s next completed response contains:

{
  "type": "message",
  "status": "completed",
  "role": "assistant",
  "phase": "final_answer",
  "content": [{"type": "output_text", "text": ""}]
}

This is genuinely empty final text—not just a transient empty block at the start of streaming.

5. Goose itself emits this ACP assistant message:

The model returned an empty response. Please resend your message to continue.

The distinction: the requested answer is already in the Buzz channel, but Goose’s final ACP output asks for a resend. No new user message or Buzz continuation prompt occurred between steps 3–5. The warning is present in ACP; this trial’s relay readback contains the successful answer, not a second channel post with the warning.

you can see this in goose codebase discouraging empty response:

(goose) > rg "The model returned an empty response."

crates/goose-agent/src/inference.rs
68:    "The model returned an empty response. Please resend your message to continue.";

crates/goose/src/agents/agent.rs
90:    "The model returned an empty response. Please resend your message to continue.";

[salman1993]

for (4) how does the git shim work with other ACP agents?

• Claude Code ACP: no buzz-dev-mcp injected by default, so no shim setup. Desktop separately supplies URL-scoped Git authentication, but not the shim’s full identity/signing/keyfile setup.
• Codex ACP: buzz-dev-mcp is injected by default, so commands executed through that MCP server’s shell receive the shim setup. Codex’s native shell does not automatically receive it.

@tlongwell-block @wpfleger96 can comment on how important the shim is here and if there's sth else we can do

[salman1993]

🤖 Tyler’s recollection matches the code: the shim puts Buzz/Git helpers on PATH and gives buzz-dev-mcp shell commands temporary Git auth, author, and signing settings. It does not need to live in buzz-dev-mcp. Buzz should set this up when launching an agent so Pi, Claude Code, Codex, and Goose can use ordinary Git commands through their native shell tools.

[salman1993]

@jamadeo @tlongwell-block for (4) i think we can refactor the git shim to be in buzz-acp instead of buzz-dev-mcp. here's a PR if you wanna take a look: #7819

[jamadeo]

@salman1993 ok great I think I understand - a typical Buzz agent turn ends with a tool call to buzz mesages send, we send that to the model, and the response is empty because the model has correctly identified that the work is complete. I'll see if I can reproduce this reliably in goose itself.

[salman1993]

@jamadeo i also wrote up this issue in goose for (2) shell capture is unbounded.. i think that'll be a useful addition for all goose users (esp. since shell is so widely used)

[salman1993]

just merged the PR for using bundled goose in the new buzz app - block/buzz-app#497

[salman1993]

@jamadeo for tracking, ran into this error with goose using claude models in databricks: aaif-goose/goose#12168 (comment)

[jamadeo]

Ugh, databricks mistreating JSON again. aaif-goose/goose#12725 should solve it

…

On Tue, Oct 6, 2026 at 12:09 PM Salman Mohammed ***@***.***> wrote: *salman1993* left a comment (block/buzz#7742) <#7742 (comment)> @jamadeo <https://github.com/jamadeo> for tracking, ran into this error with goose using claude models in databricks: aaif-goose/goose#12168 (comment) <aaif-goose/goose#12168 (comment)> — Reply to this email directly, view it on GitHub <#7742?email_source=notifications&email_token=ABIP3VAQB3LVJFAYYNRLAO35SUKLHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBSGAZTQNJVGMY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6020385531>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIP3VDHV7OBBOA2HTNS3X35SUKLHAVCNFSNUABGKJSXA33TNF2G64TZHMYTCNZUG44DSMBYGI5US43TOVSTWNJVGAYTMNRVGQ2DTILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>