Github Copilot models disappear when a Go/Zen API key is also stored #55082

Activity

1. opencode-agent commented on Oct 13, 2026

   

   opencode-agentBot

   on Oct 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed steps. I tried them on 2.0.28 (Linux, clean profile, no plugins) and couldn't reproduce this:

   • With only a GitHub Copilot credential, opencode models listed the github-copilot models.
   • After importing an opencode-go key exactly as in your step 3 (and then an opencode key as well), the github-copilot models were still listed, also after restarting the background service.
   • opencode run -m github-copilot/kimi-k3 "hi" still found the model. It only failed when the request reached GitHub, because my test token was fake.

   One thing I couldn't test: with a placeholder key, OpenCode can't load your provider configuration from the OpenCode Console (the log shows OpencodeConsole.SignedOut). If the problem comes from what the Console sends back for a real Go/Zen account, my test wouldn't show it.

   Could you help narrow it down?

   • Does it still happen if the Go/Zen credential really is a dummy key like sk-anything, or only with your real key?
   • With both credentials stored, please run opencode service restart and then opencode run -m github-copilot/kimi-k3 "hi". Then share the matching lines from ~/.local/share/opencode/log/opencode.log, especially any containing OpenCode provider config, GitHub Copilot or ModelUnavailable. Please remove any keys or tokens first.
   • Do you have an opencode.json / opencode.jsonc (global or in the project), or any OPENCODE_* environment variables set?
2. TsubasaBE commented on Oct 15, 2026

   

   TsubasaBE

   on Oct 15, 2026

   Author

   More actions

   Thanks for checking this. I’ve now tested the combinations separately on 2.0.29, using fresh profiles with empty configs and no plugins.

   First, a correction: my earlier reproductions used my real Go/Zen key, not sk-anything. The placeholder example in the issue wasn’t tested. Sorry for the misleading repro.

   The new results narrow it down:

   Credentials stored alongside Copilot	Copilot models listed	Copilot request after restart
   None	Yes	Works
   sk-anything under both opencode-go and opencode	Yes	Works
   Real key under opencode-go only	Yes	Works
   Real key under opencode only	No	Model unavailable
   Real key under both	No	Model unavailable

   My Go and Console keys are identical. The difference is which integration holds the key: opencode-go alone works, but adding the real key under opencode makes Copilot disappear. Adding just that opencode credential also brings Go models into the model list.

   For each case, I checked the model list after import, stopped and restarted the isolated server, then ran:

   opencode run --server <test-server> -m github-copilot/kimi-k3 "Reply with hi. Do not use any tools."

   With dummy keys, I get the same warning you saw:

   timestamp=2026-10-15T09:05:13.857Z level=WARN run=98639e9d message="failed to load OpenCode provider config" cause="OpencodeConsole.SignedOut: Reconnect OpenCode Console to continue."
   

   With both real credentials stored, Copilot stays missing after restart. The matching request error is below; I’ve omitted the stack trace and session ID:

   timestamp=2026-10-15T09:06:25.527Z level=ERROR run=ef2f41c4 message="Failed to drain Session" cause="SessionRunnerModel.ModelUnavailableError: Model unavailable: github-copilot/kimi-k3" role=server
   

   Regarding configuration:

   • My normal setup has both a global ~/.config/opencode/opencode.jsonc and a project .opencode/opencode.jsonc.
   • Neither was loaded in these tests. Each profile had an empty global config, and project config loading was disabled.
   • Inherited OPENCODE_* variables and provider-token environment variables were removed. The tests set only OPENCODE_CONFIG_PROJECT_DISABLE=1, OPENCODE_LOG_LEVEL=DEBUG and a test-server OPENCODE_PASSWORD.
   • My normal process has OPENCODE_ENABLE_EXA, OPENCODE_SESSION_ID and OPENCODE_TERMINAL set.

   My Copilot account is an Enterprise Managed User account, and the credential metadata points to https://api.enterprise.githubcopilot.com.

   Your suggestion about the provider configuration returned by Console fits these results. I also need to retract the earlier claim about the sourceConnection filter being the root cause—we found that comparison in the bundle, but didn’t prove it caused this failure.
3. opencode-agent commented on Oct 15, 2026

   

   opencode-agentBot

   on Oct 15, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks, that table helps a lot. It points to the provider configuration OpenCode loads from the OpenCode Console when a real key is stored under opencode. A real key under opencode-go only is used for Go inference and doesn't load that configuration.

   I tried this on 2.0.29 with a mock Console and a mock Copilot endpoint, so both the Console config and the Copilot model sync succeed. Copilot stayed listed and github-copilot/kimi-k3 stayed available with every Console response I tried:

   • only opencode-go
   • opencode-go plus a github-copilot entry
   • an allow policy for opencode-go

   So the trigger is probably something specific in what the Console sends back for your account, and reproducing it needs a real Console account. A maintainer with one will need to look at it.

   If you're comfortable sharing it, the Console's response would likely pin it down. Using a throwaway profile or the same key:

   curl -s -H "Authorization: Bearer <your key>" https://opencode.ai/console/api/v2/config | jq '{providers: (.providers | keys), policies, experimental}'

   This prints only the provider IDs and any policies, not your key. Please check the output before posting it, and remove anything that looks like a secret or an account identifier.
4. TsubasaBE commented on Oct 15, 2026

   

   TsubasaBE

   on Oct 15, 2026

   Author

   More actions

   Thanks — I fetched the response using my real Console key. Here’s the filtered output:

   {
     "providers": [
       "opencode",
       "opencode-go"
     ],
     "policies": null,
     "experimental": {
       "policies": [
         {
           "action": "provider.use",
           "resource": "*",
           "effect": "deny"
         },
         {
           "action": "provider.use",
           "resource": "opencode",
           "effect": "allow"
         },
         {
           "action": "provider.use",
           "resource": "opencode-go",
           "effect": "allow"
         }
       ]
     }
   }

   That looks like the missing piece: experimental.policies denies all providers, then allows only opencode and opencode-go. There’s no allow entry for github-copilot.

   It matches the comparison results: the dummy key never loads this configuration, and a real key under opencode-go alone doesn’t load it either. Storing the real key under opencode loads the configuration and Copilot disappears, including after restarting.

   Is this policy intended for my account? I haven’t deliberately configured a restriction to OpenCode providers. I’d expect connecting Console to add its models without disabling providers I’ve authenticated separately.

   Could you check why the Console returns this deny-all policy, and whether it should apply to my separately connected Copilot provider?