#4569·buzz

Goose harness: Buzz injects GOOSE_PROVIDER=openai-compat (invalid), overriding a working Goose config; surfaces as a Codex error

Author: jimparkinsCreated Aug 3, 2026Updated Sep 17, 2026

Summary

When the harness is Goose and the provider is OpenAI-compatible, Buzz passes its own internal provider identifier straight through as GOOSE_PROVIDER:

GOOSE_PROVIDER=openai-compat

Goose has no such provider. Its engine identifiers are openai, openai_compatible, anthropic, anthropic_compatible, ollama, ollama_compatible — underscored and unabbreviated. Critically, the env var also overrides whatever is configured in ~/.config/goose/config.yaml, so a working Goose install stops working the moment Buzz drives it.

Symptom

Every turn fails with a message about a completely different tool:

Turn error · error: The agent's harness reported an internal error. For Codex agents this can mean the configured model isn't supported by your installed codex-acp — check the model in ~/.codex/config.toml or upgrade the adapter (brew upgrade codex-acp).

codex-acp was not installed on this machine and the harness was Goose. In the agent log it appears only as:

WARN buzz_acp: agent_returned (application error — pipe intact) agent=0 outcome="error"
     configured_model=glm-5.2 error=Agent reported error (code -32603): Internal error

Reproduce

bash
GOOSE_PROVIDER=openai-compat GOOSE_MODEL=<model> goose run -t "say hi"
#   error: Error Unknown provider: openai-compat.

GOOSE_PROVIDER=zai GOOSE_MODEL=<model> goose run -t "say hi"
#   Hi there!  How can I help you today?

Goose itself works standalone with its own config; it fails only under Buzz, because of the injected variable.

Diagnosis

Not visible from the UI or logs. I had to replace the Goose binary with a shim that tee'd the spawned process's environment, which showed GOOSE_PROVIDER=openai-compat being injected.

Note BUZZ_ACP_AGENT_COMMAND is forwarded to the child but not acted on — Buzz manages its own Goose binary — so it cannot be used to interpose a wrapper.

Suggested fix

Translate Buzz's internal provider id to the target harness's vocabulary before injecting it, or omit GOOSE_PROVIDER entirely and let Goose use its own configured active_provider. The current behaviour silently overrides a valid local configuration with an invalid value.

Impact

Anyone selecting OpenAI-compatible with the Goose harness — i.e. any third-party or self-hosted model endpoint. The error text actively misdirects toward Codex.

Environment

  • Buzz Desktop 0.5.x, macOS arm64
  • Goose 1.45.0
  • Relay: self-hosted, built from source

Related

Same family as #3636, #4278 and #3824 — internally-known information that never reaches the operator.