[Windows] @ai-sdk/openai-compatible cannot connect to localhost:9877 — Bun fetch fails for 127.0.0.1 while Node fetch works (Unable to connect. Is the computer able to access the url?)

[Zhuchen00123]

Summary

On Windows, opencode's embedded Bun runtime cannot connect to a localhost @ai-sdk/openai-compatible provider at http://127.0.0.1:9877/v1. Every request fails with AI_APICallError: Cannot connect to API: Unable to connect. Is the computer able to access the url?. The same URL is reachable from Node.js fetch(), PowerShell Invoke-WebRequest, and curl on the same machine — so this is an opencode/Bun runtime issue, not a network or proxy issue.

This appears related to #28418 (@ai-sdk/openai-compatible fails to connect to LAN addresses) and #37043 (opencode ignores NO_PROXY), but this reproduces on plain 127.0.0.1 with no HTTP_PROXY/HTTPS_PROXY env vars set.

Environment

• opencode: v1.18.4 (installed via npm i -g opencode-ai, binary at D:\node_global\opencode.ps1)
• OS: Windows 11, PowerShell 5.1
• Node: v22.19.0
• Bun: installed at D:\node_global\bun.ps1 (bundled runtime used by opencode)
• Provider: @ai-sdk/openai-compatible pointing at a local reverse proxy (commandcode-api-proxy v0.3.0) on http://127.0.0.1:9877/v1

Reproduction

Config (~/.config/opencode/opencode.jsonc)

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "commandcode": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Command Code",
      "options": {
        "baseURL": "http://127.0.0.1:9877/v1",
        "apiKey": "proxy-managed"
      },
      "models": {
        "deepseek-v4-pro": { "name": "DeepSeek V4 Pro" }
      }
    }
  }
}

Steps

1. Start a local OpenAI-compatible server on 127.0.0.1:9877 (any will do — I used commandcode-api-proxy).
2. Launch opencode, select the commandcode provider / deepseek-v4-pro model.
3. Send any message.

Actual

opencode retries 3× then fails:

AI_APICallError: Cannot connect to API: Unable to connect. Is the computer able to access the url?
(cause: Error: Unable to connect. Is the computer able to access the url?)

Full log (~/.local/share/opencode/log/opencode.log):

timestamp=2026-07-21T15:34:23.959Z level=ERROR message="stream error" providerID=commandcode modelID=deepseek-v4-pro error.error="AI_APICallError: Cannot connect to API: Unable to connect. Is the computer able to access the url? (cause: Error: Unable to connect. Is the computer able to access the url?)"
timestamp=2026-07-21T15:34:29.384Z level=ERROR message="stream error" providerID=commandcode modelID=deepseek-v4-pro error.error="AI_RetryError: Failed after 3 attempts. Last error: Cannot connect to API: Unable to connect. Is the computer able to access the url?"

Notably, https://models.dev/api.json also fails with the exact same error — so the Bun runtime cannot reach any URL, not just localhost:

timestamp=2026-07-21T15:34:05.945Z level=ERROR message="Failed to fetch models.dev" cause="Cause([Fail(HttpClientError: Transport error (GET https://models.dev/api.json) (cause: Error: Unable to connect. Is the computer able to access the url?))])"

Expected

opencode connects to http://127.0.0.1:9877/v1/chat/completions and returns a response.

Proof the endpoint is reachable (same machine, same moment)

Node.js fetch() — works

const r = await fetch("http://127.0.0.1:9877/health");
console.log(r.status, await r.text());
// → 200 {"status":"ok","version":"0.1.0"}

PowerShell Invoke-WebRequest — works

Invoke-WebRequest "http://127.0.0.1:9877/health" -UseBasicParsing
# → 200 {"status":"ok","version":"0.1.0"}

$body = '{"model":"deepseek/deepseek-v4-flash","messages":[{"role":"user","content":"hi"}],"stream":false,"max_tokens":20}'
Invoke-WebRequest "http://127.0.0.1:9877/v1/chat/completions" -Method POST -Headers @{Authorization="Bearer proxy-managed";"Content-Type"="application/json"} -Body $body
# → 200, valid chat completion returned

Port is listening

Get-NetTCPConnection -LocalPort 9877
# → 127.0.0.1:9877  Listen  (OwningProcess confirmed)

What I've already tried

• No proxy env vars set: HTTP_PROXY, HTTPS_PROXY, NO_PROXY are all unset (verified via Get-ChildItem env:).
• Plugin that sets init.proxy for non-local URLs only: I have a proxy.ts plugin that routes non-local fetches through a local HTTP proxy at 127.0.0.1:60230, but it explicitly skips localhost/127.0.0.1/::1. Removing the plugin entirely does not fix the issue.
• Both opencode.json and opencode.jsonc: consolidated to a single opencode.jsonc — no change.
• Different localhost ports: tried 8787 (got EACCES — Windows reserved range), 9877, 9876 — all fail the same way in opencode.
• 127.0.0.1 vs localhost: not yet tested swapping, but @ai-sdk/openai-compatible provider fails to connect to LAN addresses — FailedToOpenSocket errno:0 #28418 reports hostname also fails.

Hypothesis

opencode's embedded Bun runtime fetch() is broken for outbound HTTP on this Windows environment — it fails for both 127.0.0.1 (local proxy) and https://models.dev (public HTTPS). Node.js fetch() on the same machine works for both. This smells like a Bun-on-Windows socket/transport bug rather than a provider config issue, possibly the same class as #28418 but broader (affects public URLs too, not just LAN).

Questions / Workarounds sought

1. Is there a way to force opencode to use Node's fetch instead of Bun's for provider calls?
2. Any known Windows-specific Bun fetch workaround (env var, config flag)?
3. Could this be related to the bundled Bun version? If so, is there a way to override it?

Happy to run any additional diagnostics the maintainers need.

[github-actions]

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

• macOS: Bun runtime gets ECONNREFUSED to LAN gateway IPs (custom provider baseURL) while Node/curl work; HTTP_PROXY works around it #37432: macOS: Bun runtime gets ECONNREFUSED to LAN gateway IPs (custom provider baseURL) while Node/curl work — same symptom class (Bun fetch broken for custom provider URLs while Node.js fetch succeeds), different OS
• @ai-sdk/openai-compatible provider fails to connect to LAN addresses — FailedToOpenSocket errno:0 #28418: @ai-sdk/openai-compatible provider fails to connect to LAN addresses (already referenced in your report)

If your issue is distinct (e.g., it reproduces even for public HTTPS URLs like models.dev, suggesting a broader Bun transport failure rather than a LAN-specific one), that distinction is worth calling out clearly to help maintainers triage.

[Zhuchen00123]

Update: Root cause found — HTTP_PROXY pointing at a dead proxy + Bun ignoring NO_PROXY

After further investigation, the root cause is not Bun being unable to connect to localhost per se. It's a combination of two issues:

1. HTTP_PROXY env var pointing at a dead proxy

The HTTP_PROXY / HTTPS_PROXY environment variables were set to http://127.0.0.1:7555 — a proxy port that was not running. This meant every outbound HTTP request from opencode was being sent to a dead proxy.

2. Bun runtime ignores NO_PROXY (confirmed: #37043)

Even though NO_PROXY=127.0.0.1,localhost,::1 was set, opencode's embedded Bun runtime ignored it and routed the http://127.0.0.1:9877/v1 request through the HTTP_PROXY at 127.0.0.1:7555 — which was dead. This is exactly the bug described in #37043.

This explains why both local (127.0.0.1:9877) and public (https://models.dev/api.json) URLs failed with the same "Unable to connect" error — they were all being sent to the dead 7555 proxy.

Why it was intermittent

The 7555 proxy was sometimes running (e.g., briefly after a reboot when a proxy app started then crashed, or when switching proxy configurations). When 7555 happened to be up, opencode worked. When it was down, everything failed. This matched the observed pattern where some providers (openai, ollama, deepseek) had high but not 100% success rates — they succeeded when 7555 was briefly alive.

Fix

Changed HTTP_PROXY / HTTPS_PROXY to point at the actually-running proxy (http://127.0.0.1:60230 in this case). After restarting opencode from a terminal with the corrected env vars, the commandcode provider at http://127.0.0.1:9877/v1 connects successfully and reliably.

Key takeaway for maintainers

The user-facing error "Cannot connect to API: Unable to connect. Is the computer able to access the url?" is misleading when the real cause is HTTP_PROXY pointing at a dead proxy + NO_PROXY being ignored. Two improvements would help:

1. Respect NO_PROXY for loopback addresses (fix opencode attach ignores NO_PROXY — loopback requests sent through HTTP(S)_PROXY #37043) — this would have made the local proxy work regardless of HTTP_PROXY state.
2. Better error messaging — when FailedToOpenSocket occurs on a proxy URL (not the destination URL), the error should indicate the proxy is unreachable, not the destination. Something like "Unable to connect to proxy at http://127.0.0.1:7555 — is the proxy running?" would have made this trivial to diagnose.

This issue can likely be closed as a duplicate of #37043 (NO_PROXY ignored), with the added context that the impact is broader than just loopback — any dead HTTP_PROXY causes all providers to fail silently.

[MauriRojas]

Hello, I don't have any proxy configured and I'm still having the connection issue, maybe I'm missing something? My opencode.jsonc is the following:

{
  "$schema": "https://opencode.ai/config.json"
}

EDIT: solved. The issue was that the DNS server had a loopback. Changing to a different server solved it.