You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Connecting OpenCode Console to the CLI doesn't display other providers' models after that #63296
I had connected some providers like DeepSeek, OpenRouter, etc to OpenCode by their API. I didn't connect OpenCode Console yet, but I connected Go using an API key.
It worked until today, when I tried to connect OpenCode Console, using my main account (which I guess works using OAuth). After connecting, I couldn't see the other providers' models in both opencode models as well as /models in the TUI.
I noticed it happened in OpenCode V1 too when I was using that version back then, and it was the same procedure to reproduce the issue.
Plugins
No response
OpenCode version
2.2.7
Steps to reproduce
Connect a provider like DeepSeek or OpenRouter, and list the models using opencode models. Their models will be present
Connect OpenCode Console via opencode auth login. Use the Console Account for login.
Run opencode models again. The other providers apart from OpenCode Console (and OpenCode Go) do not show.
Same providers can't be selected as models in the TUI too.
Screenshot
For the timebeing I am using DeepSeek API through the Console BYOK providers.
Thanks for the report and the clear steps. I think this is a duplicate of #52363. That issue covers the same problem: once OpenCode Console (or Go) is connected, providers you added with your own API key or OAuth stop showing up in opencode models and /models, and only opencode/opencode-go models are left. You already mentioned on #52363 that you saw it on v1.
Possible duplicates and related issues, ordered by likelihood:
third-party integrations stored but never selectable after 2.2.5 upgrade #60997: the same thing on 2.2.5 with DeepSeek and others. The reporter found a Console-supplied provider.use policy in opencode debug config that denies every provider except opencode/opencode-go, and logging out of Console brought their models back.
It would help to add a note on #52363 that this still happens on 2.2.7, because one commenter there thought it was fixed in 2.2.4. If you can, also include whether opencode debug config shows a provider.use policy with "resource": "*", "effect": "deny" while Console is connected.
The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
Thanks for confirming, and for adding the 2.2.7 details and opencode debug config output to #52363. That's the most useful place for them.
Thanks also for the two workarounds: setting up the other providers through Console BYOK, or adding a local provider.useallow policy in opencode.jsonc. Others who run into this should find them helpful.
This issue will be closed as a duplicate of #52363 as planned. Please follow that issue for updates.
@AlexJoaquimPereira thanks for posting the opencode debug config output on #52363. Signing in to Console made the CLI apply your workspace’s provider policy. It didn’t delete your API keys.
The policy denies all providers except opencode, opencode-go, and console-deepseek. That last one is DeepSeek through Console. Your local DeepSeek key uses the provider ID deepseek, which is why it disappears from both opencode models and /models. The same goes for openrouter.
To get those two providers back:
Open the same workspace in OpenCode Console and go to Controls. If you’re not an owner or admin, ask one to make the change.
Check All members for a Providers rule that says “limited to this workspace’s providers.” If it isn’t there, check the other policies that apply to your member.
Open Choose providers → Add another provider, add deepseek and openrouter by those exact IDs, and save. This keeps the restriction for other providers. If you want to lift it for everyone covered by that policy instead, remove just the Providers rule and save. If it’s the only rule, use ⋯ → Delete policy instead.
Give it about a minute, then run opencode models again. You should see deepseek/… and openrouter/… without reconnecting either account.
If you don’t remember creating the rule: workspaces that had Managed providers only enabled had that setting moved into All members. Your config shows the restriction, but not how it got there. I’d change it in Console rather than adding a local allow: workspace policy takes precedence.
If no matching rule shows up in Controls, let us know on #52363. That would help us narrow down why the CLI received a restriction you can’t see in Console.
Closing this as a duplicate of #52363, as you confirmed. In both issues, providers connected with your own API key or OAuth (DeepSeek, OpenRouter and others) disappear from opencode models and /models once OpenCode Console is connected. Thanks again for posting your 2.2.7 findings and the workarounds (Console BYOK, or a local provider.useallow policy) on #52363. Please follow that issue for updates.
If this turns out to be a different problem, reply here and the issue will be reopened.
Glad that worked, and thanks for confirming. As @neriousy explained above, signing in to Console applied your workspace's provider policy. It only allowed opencode, opencode-go and console-deepseek, so your own deepseek and openrouter keys were hidden. Changing that policy in the workspace's Controls in OpenCode Console fixes it.
This issue will be closed as a duplicate of #52363, so please follow that issue for anything further.
Closing this as a duplicate of #52363. You confirmed that @neriousy's fix worked: allowing deepseek and openrouter in your Console workspace's provider policy under Controls brought them back. Please follow #52363 for updates on the underlying problem.
If something is still not working, please open a new issue with the details.
Activity
opencodejr commentedon Nov 11, 2026
Thanks for the report and the clear steps. I think this is a duplicate of #52363. That issue covers the same problem: once OpenCode Console (or Go) is connected, providers you added with your own API key or OAuth stop showing up in
opencode modelsand/models, and onlyopencode/opencode-gomodels are left. You already mentioned on #52363 that you saw it on v1.Possible duplicates and related issues, ordered by likelihood:
provider.usepolicy inopencode debug configthat denies every provider exceptopencode/opencode-go, and logging out of Console brought their models back.provider.usepolicy.It would help to add a note on #52363 that this still happens on 2.2.7, because one commenter there thought it was fixed in 2.2.4. If you can, also include whether
opencode debug configshows aprovider.usepolicy with"resource": "*", "effect": "deny"while Console is connected.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
AlexJoaquimPereira commentedon Nov 11, 2026
Acknowledging that it's a duplicate of #52363
Replied about the version bump there, along with the findings of
opencode debug config. Short-term solutions are:opencodejr commentedon Nov 11, 2026
Thanks for confirming, and for adding the 2.2.7 details and
opencode debug configoutput to #52363. That's the most useful place for them.Thanks also for the two workarounds: setting up the other providers through Console BYOK, or adding a local
provider.useallowpolicy inopencode.jsonc. Others who run into this should find them helpful.This issue will be closed as a duplicate of #52363 as planned. Please follow that issue for updates.
neriousy commentedon Nov 12, 2026
@AlexJoaquimPereira thanks for posting the
opencode debug configoutput on #52363. Signing in to Console made the CLI apply your workspace’s provider policy. It didn’t delete your API keys.The policy denies all providers except
opencode,opencode-go, andconsole-deepseek. That last one is DeepSeek through Console. Your local DeepSeek key uses the provider IDdeepseek, which is why it disappears from bothopencode modelsand/models. The same goes foropenrouter.To get those two providers back:
deepseekandopenrouterby those exact IDs, and save. This keeps the restriction for other providers. If you want to lift it for everyone covered by that policy instead, remove just the Providers rule and save. If it’s the only rule, use ⋯ → Delete policy instead.opencode modelsagain. You should seedeepseek/…andopenrouter/…without reconnecting either account.If you don’t remember creating the rule: workspaces that had Managed providers only enabled had that setting moved into All members. Your config shows the restriction, but not how it got there. I’d change it in Console rather than adding a local
allow: workspace policy takes precedence.If no matching rule shows up in Controls, let us know on #52363. That would help us narrow down why the CLI received a restriction you can’t see in Console.
opencodejr commentedon Nov 12, 2026
Closing this as a duplicate of #52363, as you confirmed. In both issues, providers connected with your own API key or OAuth (DeepSeek, OpenRouter and others) disappear from
opencode modelsand/modelsonce OpenCode Console is connected. Thanks again for posting your 2.2.7 findings and the workarounds (Console BYOK, or a localprovider.useallowpolicy) on #52363. Please follow that issue for updates.If this turns out to be a different problem, reply here and the issue will be reopened.
AlexJoaquimPereira commentedon Nov 12, 2026
Thank you, it worked! @neriousy
opencodejr commentedon Nov 12, 2026
Glad that worked, and thanks for confirming. As @neriousy explained above, signing in to Console applied your workspace's provider policy. It only allowed
opencode,opencode-goandconsole-deepseek, so your owndeepseekandopenrouterkeys were hidden. Changing that policy in the workspace's Controls in OpenCode Console fixes it.This issue will be closed as a duplicate of #52363, so please follow that issue for anything further.
opencodejr commentedon Nov 12, 2026
Closing this as a duplicate of #52363. You confirmed that @neriousy's fix worked: allowing
deepseekandopenrouterin your Console workspace's provider policy under Controls brought them back. Please follow #52363 for updates on the underlying problem.If something is still not working, please open a new issue with the details.