Possible to support authentication from `auth.json`?

[chawyehsu]

Thanks for making the plugin, but it seems only the apiKey set in provider config in opencode.json can be used to authenticate, the one set by using /connect and stored in auth.json is ignored.

[yuhp]

Thanks for the report.
I took a closer look at this. The current behavior is indeed that this plugin only uses the API key configured on the provider itself, for example:

{
  "provider": {
    "custom": {
      "options": {
        "apiKey": "..."
      }
    }
  }
}

However, for providers connected through OpenCode's /connect flow, OpenCode normally already resolves the provider authentication and provides the model list in /models by itself. In those cases this plugin should not need to read auth.json or perform a second model discovery request.

The main intended use case for this plugin is custom OpenAI-compatible providers whose model list is not already managed by OpenCode, such as local servers, LiteLLM, LM Studio, Ollama-compatible endpoints, vLLM, custom gateways, etc. For those providers, the plugin currently expects the discovery request credentials to be provided explicitly through the provider config, for example via options.apiKey, {env:...}, or {file:...}.

I am hesitant to directly read auth.json from the plugin because that file is an internal OpenCode auth store, and depending on its path/format would be fragile and could create security/compatibility issues.
Could you share the exact provider config you are using and which provider you connected with /connect? I want to understand whether this is:

1. A built-in OpenCode provider, where OpenCode should already expose the models without this plugin.
2. A custom OpenAI-compatible provider that needs to reuse credentials from an existing /connect provider.
3. A provider where OpenCode itself is not showing the expected models after /connect.

Depending on the case, this may be better handled as documentation, an explicit credential configuration example, or possibly a future integration with an official OpenCode plugin auth API rather than reading auth.json directly.

[Hxyspace]

Hi @yuhp , thanks for the detailed explanation!

My use case falls under a custom OpenAI-compatible provider that needs to reuse credentials from an existing /connect provider.

I am using a local LiteLLM proxy and connecting to it via OpenCode's /connect command by selecting "other custom provider". OpenCode successfully saves the credentials to auth.json, but OpenCode itself doesn't automatically expose the model list after /connect (it only stores the credentials). The opencode-models-discovery plugin also doesn't pick them up for model discovery.

Here are my exact configurations:

~/.config/opencode/opencode.jsonc

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": [
    ["opencode-models-discovery", {
      "providers": { "include": ["breeze"] },
      "smartModelName": true
    }]
  ],
  "provider": {
    "breeze": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Breeze",
      "options": {
        "baseURL": "http://localhost:4000/v1"
      }
    }
  }
}

~/.local/share/opencode/auth.json

{
  "breeze": {
    "type": "api",
    "key": "sk-aN15Jnl4f2UmOPOVTocg8g"
  }
}

I completely understand your hesitation regarding directly reading auth.json due to it being an internal store and potential fragility/security concerns.

However, since OpenCode already resolves authentication for custom providers connected via /connect, would it be possible for the plugin to hook into OpenCode's internal auth resolution mechanism rather than parsing the file directly? Alternatively, if there is a way to explicitly reference the /connect stored credentials in the opencode.json provider options (e.g., via a special syntax like {auth:breeze}), that would also be a great workaround.

Thanks for maintaining this plugin!