Support LM Studio servers with required API key authentication #28

Problem

LM Studio can be configured to require authentication for its local OpenAI-compatible server. In that mode, /v1/models only works when the request includes an Authorization: Bearer header.

The plugin currently appears to call LM Studio health-check and model-discovery endpoints without forwarding an API key or authorization header. As a result, authenticated LM Studio servers are reported as offline even though the server is reachable and works correctly with an authenticated HTTP request.

Reproduction

1. Enable the LM Studio local server on 127.0.0.1:1234.
2. Enable required authentication in LM Studio.
3. Confirm that http://127.0.0.1:1234/v1/models works when a Bearer authorization header is included.
4. Configure OpenCode with this plugin and a provider base URL of http://127.0.0.1:1234/v1.
5. Start OpenCode and open the model selector.

Actual behavior

The plugin logs messages similar to:

[opencode-lmstudio] LM Studio appears to be offline
baseURL: "http://127.0.0.1:1234"
[opencode-lmstudio] No models discovered - LM Studio might be offline

This is misleading: LM Studio is online, but the plugin-internal fetch calls are unauthenticated.

Expected behavior

The plugin should support authenticated LM Studio servers by forwarding an API key or authorization header when doing:

• health checks
• /v1/models discovery
• loaded-model validation

A possible configuration pattern could be:

"options": {
"baseURL": "http://127.0.0.1:1234/v1",
"apiKey": "{env:LM_API_TOKEN}"
}

or a plugin-specific setting that reads an environment variable, for example:

"lmstudio": {
"apiKeyEnv": "LM_API_TOKEN"
}

The important part is that plugin-internal fetch() calls should include:

Authorization: Bearer

when an API key is configured.

Notes

The README configuration examples currently show only baseURL; there does not appear to be a documented way to provide an LM Studio API key for plugin-driven discovery.

Direct HTTP requests with a Bearer token succeed, but plugin discovery reports the server as offline. This indicates the issue is likely in the plugin’s internal health/model-discovery logic, not in LM Studio itself.