opencode-go: "502 Cannot connect to API: The session has been destroyed" never recovers until the session is restarted

[dgokcin]

What happens

On an OpenCode Go model (clodex:opencode-go:deepseek-v4.1-flash, proxy mode), a turn
sometimes starts failing with:

502 Cannot connect to API: The session ha…  ·  Retrying in 26s  ·  attempt 9/10

(message is truncated in the TUI; it looks like The session has been destroyed)

It looks like the usual Anthropic "API temporarily overloaded" banner, but it behaves
differently: it never recovers. Claude Code burns through all 10 retries, and every
subsequent prompt in that session fails the same way. The only fix is to kill Claude Code
and start a new session — after the restart the exact same prompt works immediately.

So this is not the upstream being down: the connection state clodex is reusing appears to
be permanently poisoned for the lifetime of the process.

Expected

Either the connection is re-established transparently on the next attempt (like the
Anthropic path does), or the failure is at minimum recoverable without killing the session.

Notes

• Happens intermittently, after the session has already been running a while.
• Retries by Claude Code do not help — all 10 attempts produce the identical 502.
• ~/.clodex/logs/inference-requests.jsonl has no 502 entries at all (only 200/400/401/403/404/429),
  so the error seems to be produced locally in clodex rather than being an upstream response
  being passed through.

Environment

• clodex 2.11.6
• Claude Code 2.1.269
• provider: opencode-go, model deepseek-v4.1-flash
• macOS (darwin 24.6.0)

[bman654]

Thanks for the detailed report. We can't reproduce against OpenCode Go ourselves (no Go key), but we traced what we could.

Where the message comes from. The session has been destroyed is Node's own HTTP/2 client error: something tried to send a request on a connection that had already been torn down. clodex's path for this model uses HTTP/1.1, not HTTP/2, and when clodex itself can't reach the provider it reports Upstream unreachable: fetch failed, not this text. Claude Code 2.1.269 doesn't contain the Cannot connect to API wording either. So the most likely source is OpenCode Go, or a service behind it, returning that message to clodex, which passes it through.

Why there's no 502 in your log. One likely explanation: the HTTP request returned 200, and the response stream then ended with an error whose message itself begins with 502. clodex relays that stream as-is and logs the request as 200.

Why restarting helps. Each Claude Code session has its own session id, and Go uses a session id to route requests. A new session gets a new id, which can land somewhere healthy. That fits "only restarting fixes it", though we can't confirm Go's internals.

Could you help us pin it down? With keys and prompt text removed:

1. One full failed response or debug entry: the real HTTP status, content type, and the complete stream error line if there is one. Running with clodex claude --trace (logs go to ~/.clodex/logs/) captures clodex's side.
2. How you launch: clodex claude directly, or Claude Code connected to a separate clodex server? If the latter, did the server's PID stay the same when restarting Claude Code fixed it?
3. Your exact build. deepseek-v4.1-flash isn't in the stock 2.11.6 catalog. It arrived with fix(opencode-go): send the session header Go now requires, add DeepSeek V4.1 Flash #213, which just merged. Are you running that branch, a source build, or a refreshed/custom provider registry?
4. Whether a non-Go model, or a different Go model, still works in a session that has started failing.

For now, starting a new Claude Code session is the known recovery, and switching to a non-OpenCode-Go model should avoid it. Note that OpenCode Go is community-supported in clodex, so wire captures from users are how we debug it.

[dgokcin]

About 3, I was using a local build where I patched clodex to display me deepseek flash. I will be using the latest version for clodex claude --trace instead of my build so it's easier to debug. this is what I did:

• updated clodex to the latest version (2.12.2)
• started a chat with clodex claude --trace set model to deepseek flash and asked a question, got my reply
• asked another question and got 502 Upstream unreachable: fetch failed after trying 10 times
• /model deepseek v4-pro(another opencode model) told that the response got cut-off, had an API error
• /model luna told response got cut-off, it continued from where it left off.

the debug logs are attached below and I hope it could be helpful. also, I am fully aware that the support for opencode-go is community driven and I really love the flexibility on models it adds to the clodex stack so that's why I subscribed to it for a month. pls let me know if I can do anything else to help you investigate and hope we can find the root cause 💪

20260913-141837105Z-claude-debug-pid2494-2.log

[dgokcin]

Update: this turned out to be a Node 26 problem on my side, and moving to Node 24 fixes it.

How I got there:

• I run Node 26 (Homebrew's node, v26.5.0).
• clodex was installed globally under that Homebrew Node — left over from when I was working on feat(auth): add browser sign-in for workspaces that disable device codes #141
  and had the repo npm linked. So clodex's #!/usr/bin/env node shebang kept resolving to 26 even
  though my volta default is 24.
• Removed that copy and reinstalled pinned to Node 24 (volta install @bman654/clodex).

Verification on Node 24.13.0, forcing the failure conditions on purpose:

• 15-second Wi-Fi cutoff mid-session, then sent another prompt → 200 in 3680 ms, no retries.
• Session total: 8/8 requests 200, zero 502s, across 9 ECONNRESET events including a burst of 6.

Same conditions on Node 26 previously gave me 11 straight 502s that never recovered.

---

Findings from Claude Code

Everything below is Claude Code's analysis of my trace, not mine — posting it in case it's useful.

Root cause. Node 26 ships undici 8, which enables HTTP/2 in fetch() by default. Earlier lines don't:

Node	undici	fetch() negotiates h2?
22.22.0	6.23.0	no
24.13.0	7.18.2	no ← CI runs this
26.5.0	8.7.0	yes

opencode.ai serves HTTP/2, so on Node 26 all clodex → OpenCode Go traffic shares one long-lived
per-origin h2 session. When that session is destroyed, undici keeps the corpse pooled and every later
request to that origin rejects instantly with Node's
ERR_HTTP2_INVALID_SESSION: The session has been destroyed.

One cause, both reported messages:

• raw passthrough — .message is fetch failed → Upstream unreachable: fetch failed
• AI SDK path — @ai-sdk/provider-utils wraps cause.message → Cannot connect to API: The session has been destroyed

What destroys the session. OpenCode Go resets the TCP connection at end-of-stream rather than closing
cleanly. My proxy-debug log shows Uncaught Exception: Error: read ECONNRESET bursts landing in the same
millisecond a deepseek stream completes. On Node 26 each one is a chance to kill the pooled h2 session,
which is why this hit OpenCode Go and not the Anthropic passthrough, and why it felt random.

Evidence in the failing trace — the durations are the tell:

14:24:44  deepseek-v4.1-flash  200  2883ms
14:29:43  deepseek-v4.1-flash  502   424ms   <- a real connect attempt
14:29:44  deepseek-v4.1-flash  502     9ms
14:29:45  deepseek-v4.1-flash  502     7ms
          ... 11 total, all 6-14ms, over ~3 minutes

6–14 ms is far too fast for DNS + TCP + TLS: those retries never touched the network, which is exactly
why Claude Code's 11 retries were useless. Meanwhile at 14:29:43.880, mid-outage,
claude-haiku-4-5 returned 200 over the Anthropic passthrough — the network was fine, only the
opencode.ai origin was poisoned.

Standalone repro, no clodex and no API key:

import http2 from 'node:http2';
const sessions = [];
const orig = http2.connect;
http2.connect = (...a) => { const s = orig(...a); sessions.push(s); return s; };

const timed = async (label) => {
  const t = Date.now();
  try { const r = await fetch('https://opencode.ai/'); await r.arrayBuffer();
        console.log(`${label}: status ${r.status} in ${Date.now() - t}ms`); }
  catch (e) { console.log(`${label}: FAILED in ${Date.now() - t}ms -> "${e.message}" | cause: "${e.cause?.message}"`); }
};

await timed('request 1');
console.log(`destroying ${sessions.length} pooled h2 session(s)`);
for (const s of sessions) { s.on('error', () => {}); s.destroy(); }
await timed('request 2');
await timed('request 3');

Node 26: destroying 1 pooled h2 session(s)
         request 2: FAILED in 3ms -> cause: "The session has been destroyed"
         request 3: FAILED in 0ms -> cause: "The session has been destroyed"

Node 24: destroying 0 pooled h2 session(s)
         request 2: status 200 in 375ms
         request 3: status 200 in 440ms

On Node 24 there is nothing to poison, because fetch() never negotiates h2.

Suggestions:

1. Pin allowH2: false on the dispatcher used for outbound provider calls, so behaviour doesn't
   silently change with the user's Node version. engines.node is >=22 while CI runs 24, so this
   failure mode is invisible to CI today.
2. Treat ERR_HTTP2_INVALID_SESSION as a retryable connect error rather than surfacing it as a 502.
3. Preserve error.cause in UpstreamUnreachableError (src/upstream-forward.ts:48 uses only
   cause.message). A bare fetch failed is undiagnosable; the cause chain is what made this findable.
4. Separately: those read ECONNRESET errors reach the process-level uncaughtException handler
   (src/proxy.ts:345), so some socket in the relay path has no error listener.

Correction to the original report: the "no 502s in the logs" claim was wrong — that checked the
aggregate ~/.clodex/logs/inference-requests.jsonl, which hadn't been written since Sep 11. The
per-session jsonl contains 30 of them.