Built-in MiniMax providers (minimax.io / minimaxi.com) persist after opencode auth logout and cannot be removed #31832

Activity

1. github-actions

   assigned

   kitlangton

   on Jun 11, 2026
2. github-actions commented on Jun 11, 2026

   

   github-actionsBot

   on Jun 11, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • System model overrides popup selection in Plan Mode, built-in Google provider cannot be removed #26353: Built-in provider (Google) cannot be removed even after clearing credentials/config — similar symptom of a built-in provider persisting after the user removes all related configuration
   • A previously removed provider "Model Studio Coding Plan" keeps reappearing in new sessions. #18535: A previously removed provider keeps reappearing in new sessions — similar symptom of a provider persisting despite not being present in auth.json or config files

   If your issue is distinct from these, please clarify what differentiates it.
3. sharyuke commented on Jun 11, 2026

   

   sharyuke

   on Jun 11, 2026

   Author

   More actions

   Root cause found — closing as not-a-bug, but documenting for future reference

   After further investigation, the real cause of my confusion was an environment variable in my shell, not a config-file issue.

   Two things are at play

   1. MINIMAX_API_KEY was set in my ~/.bashrc (line 192, export MINIMAX_API_KEY=...). opencode sees this env var and auto-enables the four built-in MiniMax providers (minimax, minimax-cn, minimax-cn-coding-plan, minimax-coding-plan) on every startup, regardless of what's in auth.json / opencode.json. auth logout only removes the credential, it does not clear the env var, so the providers get re-enabled on the next launch.

   2. disabled_providers in opencode.json does work for the CLI, but is not honored by the TUI model selector. I verified this against the source:

      • packages/opencode/src/provider/provider.ts:1328,1331-1335,1549-1552 — the runtime provider loader builds disabled = new Set(cfg.disabled_providers ?? []) and removes matching providers.
      • packages/opencode/test/provider/provider.test.ts — there is even a test "disabled_providers excludes provider" confirming this works.
      • However, the TUI calls the server's provider.list endpoint (packages/server/src/handlers/provider.ts), which returns catalog.provider.available() from packages/core/src/catalog.ts:224-229. That method filters by provider.enabled only and does not consult disabled_providers at all. So even with "disabled_providers": ["minimax", "minimax-cn"] correctly loaded in the resolved config (verified with opencode debug config), the model selector still shows them.

      This second point is a real bug — disabled_providers is documented behavior and should be honored end-to-end. It is silently ignored in the TUI.

   Reproduction (local, v1.17.3)

   $ opencode debug v2
   Total providers: 9
     ...
     minimax: MiniMax (minimax.io) enabled={'via': 'env', 'name': 'MINIMAX_API_KEY'}
     minimax-cn: MiniMax (minimaxi.com) enabled={'via': 'env', 'name': 'MINIMAX_API_KEY'}
     minimax-cn-coding-plan: MiniMax Token Plan (minimaxi.com) enabled={'via': 'env', 'name': 'MINIMAX_API_KEY'}
     minimax-coding-plan: MiniMax Token Plan (minimax.io) enabled={'via': 'env', 'name': 'MINIMAX_API_KEY'}
     ...

   opencode config (and opencode debug config) shows "disabled_providers": ["minimax", "minimax-cn"] in the resolved config, yet provider.list still includes the four MiniMax entries.

   Workaround that works for me

   Unset the env var (or remove the export line from ~/.bashrc) and restart opencode. With the env var gone, the providers are no longer auto-enabled, and the model selector stops listing them:

   unset MINIMAX_API_KEY MINIMAX_API_BASE

   Keeping disabled_providers in opencode.json is still a good idea as a belt-and-suspenders measure for when the env var is set.

   Recommendation

   Two follow-ups worth opening as separate issues:

   1. auth logout should not leave providers in a zombie state. When the user explicitly removes a credential, the env-var auto-loading should also be disabled, or at minimum the user should be warned that the provider will be re-enabled on next launch. Currently the only way to be sure a provider is gone is to track down every place the env var is set.
   2. disabled_providers is not honored by the TUI. CatalogV2.provider.available() should apply the same isProviderAllowed check that the runtime loader uses, so user intent expressed in the config file is respected everywhere.

   Closing this as not-a-bug on the original report, but the env-var behavior is surprising enough to deserve a UX improvement. Sorry for the noise.
4. sharyuke commented on Jun 11, 2026

   

   sharyuke

   on Jun 11, 2026

   Author

   More actions

   Closing as not-a-bug — root cause was a stale env var in (see comment below). does work for the CLI but is not honored by the TUI catalog layer; recommend opening that as a separate bug.
5. sharyuke

   closed this as completedon Jun 11, 2026