Saving a custom provider does not set Goose's default provider/model, leaving Goose unavailable

[chronakazi]

Before filing

• I searched open and closed issues for duplicates.
• I reproduced this on the latest release.
• This is one bug, not several bundled together.

Closest existing issue

none found

What's broken

Saving a valid custom OpenAI-compatible provider writes the provider JSON and stores its credential, but it does not persist Goose's active provider and model. Goose remains not_ready and cannot be selected in a chat, even after restarting Berd. In this case it was Opencode Zen.

Steps to reproduce

1. Start with a Goose profile that has no saved default provider or model, then launch Berd.
2. Open Settings and use the provider connection dialog to create a custom OpenAI-compatible provider.
3. Configure the provider with:
   • Name: OpenCode Zen
   • API URL: https://opencode.ai
   • Base path: /zen/v1/responses
   • Authentication: enabled, with a valid OpenCode Zen API key
   • Model list including gpt-5.6-luna
4. Save the provider. The resulting custom-provider file is valid and contains the expected base URL, base path, and model list.
5. Return to either a new chat or an existing chat with prior history and open the agent/model picker.
6. Observe that Goose is unavailable and reports not_ready.
7. Quit and relaunch Berd.
8. Observe that Goose is still unavailable.

What you expected to happen

After Berd successfully saves and verifies the custom provider, it should save that provider and one of its models as Goose's active defaults when Goose has no defaults yet. Goose should become selectable without editing Goose configuration files manually.

What actually happened

Berd created this provider configuration successfully:

{
  "name": "custom_opencode_zen",
  "engine": "openai",
  "base_url": "https://opencode.ai",
  "base_path": "/zen/v1/responses",
  "requires_auth": true
}

However, ~/.config/goose/config.yaml still had no GOOSE_PROVIDER or GOOSE_MODEL entry. The bundled Goose diagnostic reported that no provider was configured, so Berd continued to classify the Goose harness as not_ready. Restarting Berd did not change that state.

The workaround was to add these entries manually:

GOOSE_PROVIDER: custom_opencode_zen
GOOSE_MODEL: gpt-5.6-luna

After reloading Berd's Goose process, the same provider passed its authentication and connection checks and Goose became selectable.

How often does it happen?

Every time — reliably reproducible

Berd version

0.6.2, the latest release at the time of reporting

Operating system

macOS (Apple Silicon)

Model and provider

Opencode Zen, all models

Relevant log output

The app log repeatedly classified the harness as not ready before the workaround:


[2026-08-20][01:17:41][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=harness_not_ready duration_ms=580
[2026-08-20][01:26:06][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=harness_not_ready duration_ms=1
[2026-08-20][01:27:17][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=harness_not_ready duration_ms=1


Before the workaround, the bundled Goose diagnostic returned:


Provider Check:
  Provider: not configured: Configuration value not found: GOOSE_PROVIDER


After adding the two missing default entries and reloading Goose, the diagnostic returned:


Provider Check:
  Provider:   custom_opencode_zen
  Model:      gpt-5.6-luna
  Auth:       ok
  Connection: ok

Screenshots, recordings, or other context

I did not patch the Berd application or its bundled Goose binary. The only persistent manual change was adding GOOSE_PROVIDER and GOOSE_MODEL to ~/.config/goose/config.yaml; I then reloaded the Goose process.

A read-only inspection of current main suggests that custom-provider creation and update refresh the provider catalog and model cache, but do not call the existing default-selection helper:

• useCustomProviders.ts saves the custom provider and refreshes its models.
• useCredentials.ts calls saveDefaultProviderSelection(providerId) for configured built-in providers when readiness is needs_setup.
• defaultProviderConfig.ts already persists both defaults and refreshes the readiness store.

The likely fix is to give successful custom-provider setup the same conditional default-selection behavior, without replacing an existing default provider.

This report is only about the missing Goose defaults and readiness state. Endpoint path composition is a separate concern and is not included here.

Bug identified and fixed by GPT 5.6 Sol from a Berd chat, this report was generated by 5.6 Sol in Berd as well.

[matthewdonsemail-lab]

This aswell what I did was I used opencodex to the proxy via codex to then make it so that it would then work https://github.com/lidge-jun/opencodex you cant actually make goose work like that so just get a proxy through codex and then set your models accordingly

Even if configured with a custom provider it doesnt recoginize it if it isnt from any of the upstream providers and doesnt allow for it to work and then fallsback to and incorrect model.

Just use opencodex to proxy through thats the best means that I've found