Repository navigation
ECONNRESET / "Failed to drain Session" on every model request (Desktop 2.2.3, Windows 10, behind NaiveProxy) #60700
Description
Description
markdown
Environment
- OpenCode Desktop
2.2.3 - Windows 10
- Provider
opencode-go, modeldeepseek-v4.1-flash - Network: Karing proxy client, single available node, NaiveProxy
- Reproduces on all models including free ones; survives full reboot
Description
Every request to the model fails immediately with:
ECONNRESET: The socket connection was closed unexpectedly.
Server log (C:\Users\user\.local\share\opencode\log\opencode.log):
timestamp=2026-10-30T12:28:49.320Z level=ERROR message="Failed to drain Session"
cause="AI.Error: ECONNRESET: The socket connection was closed unexpectedly..."
sessionID=ses_e733bb8a8ffequlklXBRyMYalS
timestamp=2026-10-30T12:43:00.347Z level=ERROR message="Failed to drain Session"
cause="AI.Error: ECONNRESET: The socket connection was closed unexpectedly..."
sessionID=ses_e73633bc7ffdV6sW0EQRfRIszA
Stack trace contains Bun fetch and the server request loop:
AI.Error.Transport: ECONNRESET
TypeError: ECONNRESET: The socket connection was closed unexpectedly
at POST
at SessionStep.attempt
at SessionRunner.runStep
at SessionRunner.drain
at ServerProcess.start
Expected: model response (streaming SSE).
Actual: connection reset during the POST, no response.
Already verified — please don't ask me to re-check these
- Same API key, same endpoint, same model work from Python
urllib.requeston the same machine through the same proxy:POST https://opencode.ai/zen/go/v1/chat/completions,stream=false→HTTP 200,OK- same with
stream=true,Accept: text/event-stream→HTTP 200, SSE text received, stream finished
curl https://opencode.ai/inference/go/v1/models→HTTP 200(server: cloudflare)curl https://api.deepseek.com/modelswithout auth →HTTP 401(expected, HTTPS reachable)- TCP 443 to
api.deepseek.com→TcpTestSucceeded: True - TLS handshake (OpenSSL 3.1.4) to
opencode.aiandapi.deepseek.com→ TLSv1.3, verification OK,X25519 - Karing's connection list shows
OpenCode.exe → opencode.ai:443routed through the proxy — the app is not bypassing it - Tried Rule / Global / TUN modes — no change
- Full Windows reboot — no change
opencodeCLI 1.19.3 from PowerShell — hangs, no TUI appears
Account, key, credits, model availability, DNS/TCP/TLS reachability and SSE streaming all work. The failure is specific to Desktop's request path.
Not tested / open hypotheses
- TLS ClientHello difference between Bun fetch and Python
urllib— e.g. post-quantum key shareX25519MLKEM768producing a larger ClientHello dropped by the proxy or upstream network. Could not verify: local OpenSSL 3.1.4 rejects-groups X25519MLKEM768(group cannot be set), and I have only one proxy node, so no comparative node test. - Connection reuse / keep-alive behaviour of Desktop's HTTP client.
- Headers or request body differences Desktop adds.
What would let me narrow it down
- A way to enable verbose network logging in Bun/Desktop's fetch (env var, debug flag, or a build with request dump).
- TLS keylog support (
SSLKEYLOGFILE/ BoringSSL keylog) in Desktop, so the handshake can be captured and compared against a working one. - Whether Desktop's HTTP client uses HTTP/1.1 or HTTP/2 over TLS here.
Workaround currently in use: a small standalone Python GUI chat hitting the same endpoint — works fine.
Перед отправкой проверь: путь к логу я поставил реальный из `FUCK.md`, а версию `2.2.3` — если Desktop с тех пор обновился, поправь, иначе первым комментом будет «update to latest».
Остальное — если форма просит отдельно «Steps to reproduce» или «OpenCode version», просто раскидай куски из этого текста по полям.
### Plugins
_No response_
### OpenCode version
_No response_
### Steps to reproduce
_No response_
### Screenshot
_No response_
### Operating System
_No response_
### Terminal
_No response_
Activity
opencodejr commentedon Oct 30, 2026
Thanks for the detailed report. The Python/OpenSSL comparison and the TLS hypotheses made this easy to place.
I think this is a duplicate of #60399. That issue has been reproduced, and it matches your first hypothesis. OpenCode 2.x's bundled runtime (Bun) adds an
X25519MLKEM768post-quantum key share to the TLS ClientHello. That makes the ClientHello about 1.5 KB, so it is split across TCP segments, and filtering somewhere on the path toopencode.ai(Cloudflare) drops it. Every request then fails withECONNRESET. Clients that send a smaller ClientHello still get through. Your OpenSSL 3.1.4 is one of them: as you found, it rejects that group. A proxy doesn't rule this out, because the inner TLS handshake still travels from the proxy's exit node to Cloudflare. A comment on #60399 also notes that v2 ignoresHTTPS_PROXYfor inference requests.#60399 has the measurements, the discussion of a client-side fix (limiting the TLS groups, e.g.
X25519:P-256) and several temporary workarounds that other users posted.Possible duplicates and related issues, ordered from most to least likely:
ECONNRESETor hangs, while curl, Python and VPNs work.ECONNRESETwithout a VPN, works with a VPN, curl succeeds.ECONNRESETafter upgrading from 1.9.5 to 2.2.0. Fixed by zapret or a VPN.ECONNRESETon Windows with a VPN or proxy (cause not yet confirmed).The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different. For example, reply if you can show that the TLS handshake through your NaiveProxy exit completes and the reset happens later.
magusy commentedon Oct 30, 2026
I am experiencing the same ECONNRESET error on the desktop app. It happens during model requests and prevents me from getting responses. I've confirmed that this is the same behavior described in this issue.
opencodejr commentedon Oct 31, 2026
We haven't heard back, so I'm closing this as a duplicate of #60399. That issue is the same
ECONNRESETon every request: Bun's larger post-quantum TLS ClientHello gets dropped on the network path toopencode.ai, even though Python/OpenSSL and curl get through. Please follow #60399 for updates and the workarounds posted there, and add your NaiveProxy/Karing details there if they help.If you find your case is different, for example the TLS handshake through the proxy completes and the reset happens later, reply here and we can reopen it.