Repository navigation
Description
Description
Confirmed on OpenCode v2.0.26, Linux x86_64, installed from @opencode/cli@2.0.26. Reopening per the V2 triage comment: the provider-selection coupling still reproduces with both native V2 configuration and the original V1 configuration syntax.
Each run used a separate, initially empty HOME and project directory, env -i, only OPENAI_API_KEY=probe-openai, and run --standalone so no existing background service or credentials could affect selection. The key is deliberately invalid; no real provider credentials were used. No explicit model was selected.
Observed results
| Configuration | Selected provider/model | Result |
|---|---|---|
Empty {} |
opencode/exo-free |
HTTP 410: model deprecated |
Only native V2 Anthropic settings.baseURL |
anthropic/claude-haiku-5-5 |
Connection refused at the configured loopback URL |
Baseline with the built-in opencode provider excluded |
openai/gpt-6.1-sol |
HTTP 401: invalid probe OpenAI key |
Same exclusion + only Anthropic settings.baseURL |
anthropic/claude-haiku-5-5 |
Connection refused at the configured loopback URL |
Original V1 provider.anthropic.options.baseURL syntax, without the exclusion |
anthropic/claude-haiku-5-5 |
Connection refused at the configured loopback URL |
The built-in free model now wins the empty-config baseline, so I also ran the controlled pair excluding that provider identically in both configs. This restores the original OpenAI → uncredentialed Anthropic comparison without choosing a model explicitly. Model IDs were checked in the persisted assistant messages, not inferred from errors.
Controlled V2 reproduction
Install @opencode/cli@2.0.26 and confirm opencode --version prints opencode v2.0.26. Create a.json:
{
"experimental": {
"policies": [
{ "action": "provider.use", "resource": "opencode", "effect": "deny" }
]
}
}Create b.json, differing only by the base-URL overlay:
{
"experimental": {
"policies": [
{ "action": "provider.use", "resource": "opencode", "effect": "deny" }
]
},
"providers": {
"anthropic": {
"settings": { "baseURL": "http://127.0.0.1:8899/anthropic/v1" }
}
}
}Run each with an isolated profile (nothing needs to listen on port 8899):
bin="$(command -v opencode)" # absolute path to the 2.0.26 CLI
configs="$PWD"
scratch="$(mktemp -d)"
for case in a b; do
mkdir -p "$scratch/$case/home" "$scratch/$case/project"
(
cd "$scratch/$case/project"
env -i PATH="$PATH" HOME="$scratch/$case/home" \
OPENAI_API_KEY=probe-openai \
OPENCODE_CONFIG="$configs/$case.json" \
"$bin" run --standalone 'say hi'
)
doneA reaches OpenAI and reports Incorrect API key provided: probe-openai. B prints build · claude-haiku-5-5, retries, and reports ConnectionRefused.
On Linux, selection can also be checked independently in the local session database:
SELECT json_extract(data, '$.model.providerID') AS provider,
json_extract(data, '$.model.id') AS model
FROM session_message
WHERE type = 'assistant';Run this against each $scratch/<case>/home/.local/share/opencode/opencode.db: A records openai|gpt-6.1-sol; B records anthropic|claude-haiku-5-5.
V2 implementation path
The current V2 source still couples an overlay to activation:
- Config provider transform unconditionally sets
provider.activation = "enabled"for configured providers, including settings-only entries. - Provider availability accepts enabled providers without requiring a connection.
- Model sorting and fallback default selection let these models compete for the implicit default.
The exact model names and terminal error have changed since V1: V2 attempts the configured URL rather than raising the original missing-Anthropic-key error first. The reproduced issue is still that an endpoint-only overlay changes provider/model selection without any credential or model declaration. The expectation remains: configuring where a provider would send requests should not, by itself, elect that provider as the default.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
opencode-agent commentedon Oct 12, 2026
Thanks for the very precise report. I reproduced this with your two configs and the same isolated setup (
env -i, fresh HOME and project dir, onlyOPENAI_API_KEY=probe-openai, no model selected).openai|gpt-6.1-soland fails with the invalid-key 401. Config B, which only addsproviders.anthropic.settings.baseURL, selectsanthropic|claude-haiku-5-5and fails withConnectionRefused. Both results come from the persisted assistant messages.dev(4d9678a): same result.The script below runs both cases and prints the persisted provider/model for each.
As you point out, the config provider transform marks every configured provider as enabled, even a settings-only one, and enabled providers count as available without a credential. Related: #47815 (the same report against v1) and #42790 (credential-less configured providers).
Reproduction script (repro.sh)
Run it:
bash repro.sh