Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#140 1 commento 3 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
desktop

Direzione di ricerca

Inizia da src/features/providers/hooks/useCustomProviders.ts e confronta il relativo flusso di configurazione riuscito con useCredentials.ts, che chiama saveDefaultProviderSelection. Leggi src/features/providers/defaultProviderConfig.ts per capire come vengono aggiornati i valori predefiniti e lo stato di disponibilità. Il lavoro è completato quando un provider personalizzato appena salvato seleziona un modello solo quando non esistono valori predefiniti, rende persistenti entrambi i valori predefiniti di Goose e diventa selezionabile dopo il ricaricamento senza sostituire i valori predefiniti esistenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Before filing
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:

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.

Lingua principale
TypeScript
Stelle
928
Fork
121
Merge medio
1g 11h
PR unite (30g)
71

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di block/berd

Tutte le issue di block/berd

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.