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

[jimparkins]

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

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.

[jimparkins]

Still present on Buzz Desktop 0.5.4 (released 2026-08-03).

I checked whether #3580 ("fix(config-bridge): add harness-definition env tier and fix equal-value model override", shipped in 0.5.4) addressed this. It does not — that change concerns config-resolution precedence and origin reporting, not identifier translation.

At f865c00 there is still no mapping from Buzz's internal provider id to the harness's own vocabulary. The internal value is carried verbatim, e.g. desktop/src-tauri/src/managed_agents/readiness.rs:483:

Some("openai") | Some("openai-compat") => Some("OPENAI_COMPAT_MODEL"),

and nothing rewrites openai-compat → openai_compatible before it is exported as GOOSE_PROVIDER.

Worth adding, because it suggests the fix is small: the codebase already documents that this variable is Goose's own selection mechanism — desktop/src-tauri/src/commands/agent_models_env.rs:47:

"a GOOSE_PROVIDER=anthropic export (goose's documented way to pick a provider, with the key in goose's own keyring rather than Buzz's env)"

So the semantics are understood; the exported value simply isn't in Goose's vocabulary. Because the env var takes precedence over ~/.config/goose/config.yaml, the effect is that Buzz overrides a working Goose configuration with an invalid one, and the failure surfaces as advice about Codex.

Either translating the id, or omitting GOOSE_PROVIDER entirely and letting Goose resolve its own active_provider, would fix it.