[BUG] v2.1.113+ on linux-x64 behind HTTP CONNECT proxy: Bun runtime fetch race condition + 3 cascading regressions

Follow-up: this looks like part of a wider pattern — settings.json env block (and other env inputs) are not consistently honored after the v2.1.113 native-runtime switch.

A few related reports that, taken together, suggest the env-propagation path was not fully ported when the runtime changed from Node.js to the new native binary:

• #50115 — Network and env-var docs still describe Claude Code as running on a Node.js runtime after v2.1.113. Documentation hasn't caught up with the runtime change, which is consistent with env semantics having shifted under the hood.
• #50037 — ANTHROPIC_DEFAULT_*_MODEL from settings.json silently stripped under Desktop's PROVIDER_MANAGED_BY_HOST. Same shape: env field set in settings.json, runtime ignores it.
• #50200 — model setting in settings.json not respected at session start. Another settings.json field not being honored on 2.1.113.

On our side (the original report), we tried adding the following to ~/.claude/settings.json env to rule out telemetry/non-essential traffic as the proxy hang trigger:

"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
"DISABLE_TELEMETRY": "1",
"DISABLE_ERROR_REPORTING": "1",
"DISABLE_BUG_COMMAND": "1",
"DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1"

None of them changed observable behavior on 2.1.113 — startup hangs and WebFetch/WebSearch truncations continued at the same rate. On 2.1.112 (the last bundled-JS build) the same env block works as documented.

This makes us suspect the native binary's env-loading path from settings.json.env is incomplete — at minimum these DISABLE_* switches and HTTPS_PROXY/HTTP_PROXY aren't reaching whichever HTTP client the binary uses for the affected code paths.

Concrete ask: please verify the settings.json → env → runtime path end-to-end on the new native binary, with particular attention to:

1. Proxy env vars (HTTPS_PROXY, HTTP_PROXY, ALL_PROXY, NO_PROXY and lowercase variants)
2. The DISABLE_* / CLAUDE_CODE_DISABLE_* family
3. Any helper / telemetry / startup-probe HTTP clients that may not share the main SDK's proxy configuration

Thanks!

Thanks for reporting. one note. for future issues please do not include multiple issues in the same report even if you believe they are originating from the same source. it makes state tracking much harder.

I have a fix landing for Bug #2.

for the others, i will need more info. Please use /feedback and share the link, this would give me the full debug-log timeline (Bug #3), the exact Bash tool input/output (Bug #1), and the API request timing (Bug #4).

@mhegazy Thanks for the triage.

Feedback ID: 5c1290c0-5456-4a59-aaf9-9b3df06a6c21

• cc_version: 2.1.118.a9d
• OS: Ubuntu 24.04.3, kernel 6.14.0-1018-oem, x86_64, glibc 2.39
• Network: behind HTTP CONNECT proxy to api.anthropic.com:443

This single session captures three symptoms of what we believe is the same Bun fetch/socket race:

1. Startup blocks 400s inside showSetupScreens()

From the --debug log, contiguous lines 48–67 (nothing in between):

L48  22:45:03.498Z [STARTUP] Running showSetupScreens()...
L49-66  22:45:03.504-542Z  CA certs load, keybindings init, terminal caps probe
<<< 400.5 seconds of complete log silence — zero DEBUG lines >>>
L67  22:51:44.074Z [STARTUP] showSetupScreens() completed in 400576ms

Post-startup, OTEL diag fires at a consistent native frame:

22:52:24.209Z [ERROR] [3P telemetry] OTEL diag error: Operation timed out.
               stack: /$bunfs/root/src/entrypoints/cli.js:421:108938
22:54:10.341Z [ERROR] (same frame 421:108938)

OTEL_SDK_DISABLED=true is set; [3P telemetry] isTelemetryEnabled=false confirms the flag parses — yet something on that path still opens a socket and blocks for ~400s.

2. WebFetch: one of N parallel calls stalls while siblings succeed

User fired 4 parallel WebFetch calls. 3 returned in 2–3s. One hung for 44.7s until Esc:

L406  22:53:40.861Z [Stall] tool_dispatch_start tool=WebFetch toolUseId=toolu_01UpGD...
  (siblings complete in 2446ms / 2725ms / 3161ms)
L501  22:54:25.556Z [DEBUG] [onCancel] focusedInputDialog=undefined streamMode=tool-use
L502  22:54:25.559Z [WARN]  [Stall] tool_dispatch_end WebFetch toolu_01UpGD...
                    outcome=error durationMs=44698

[onCancel] arrives 3ms before tool_dispatch_end error — the cancel path released the socket, not a natural fetch completion/timeout.

3. /feedback submission itself hit the same race

Right after #2, while uploading this report:

23:01:46.602Z [DEBUG] [API REQUEST] /v1/messages source=feedback
23:02:16.604Z [WARN]  Slow first byte: no stream chunk 30.0s after request sent (attempt 1)

It eventually recovered and produced the Feedback ID above — but a 30s+ stall on a third, unrelated code path (feedback upload vs tool-use vs OTEL exporter) reinforces the common factor: Bun's fetch/socket layer on linux-x64 behind HTTP CONNECT, not any specific feature.

See the follow-up comment for a stricter reproduction of symptom #2 (cancel truly not honored) from a second machine.

Follow-up on a stricter form of WebFetch cancel-not-honored, from a second machine:

Feedback ID: bd8b02c5-8222-428c-a26e-20ff9995f4ea

• cc_version: 2.1.118.c75 (different 2.1.118 build hash — same symptom)
• OS: Ubuntu 24.04.3, kernel 6.8.0-107-generic, x86_64, glibc 2.39
• Network: same HTTP CONNECT proxy

User pressed Esc three times across three different streamMode values. The underlying Bun fetch was never torn down — log ends without a dispatch_end for that toolUseId:

L1866  22:23:37.983Z [Stall] tool_dispatch_start tool=WebFetch toolUseId=toolu_01QPz68K...
L1890  22:25:07.188Z [DEBUG] [onCancel] streamMode=tool-use       ← 1st Esc, 89s in
L1952  22:25:25.837Z [DEBUG] [onCancel] streamMode=thinking       ← 2nd Esc, 108s in
L1986  22:26:32.237Z [WARN]  Slow first byte: no stream chunk 30.0s after request sent
L1987  22:28:03.538Z [DEBUG] [onCancel] streamMode=requesting     ← 3rd Esc, 266s in
  ... (log continues 11 more minutes, no tool_dispatch_end for toolu_01QPz68K ever)
L2156  22:34:52.792Z [API REQUEST] /v1/messages source=feedback   ← /feedback filed while WebFetch still in-flight

Three different [onCancel] streamMode= values confirm the UI cancel reached the orchestrator in all three UI states (tool-use → thinking → requesting), but the underlying fetch/socket never unblocked. This session had to file /feedback with the dead WebFetch still hanging in the background.

Together with the primary comment: two different 2.1.118 build hashes (a9d and c75), two different kernels (6.14.0-oem and 6.8.0-generic), identical symptoms — rules out build-specific or kernel-specific causes, leaves the Bun runtime + linux-x64 + HTTP CONNECT intersection.

Already ruled out (per OP): network (curl/tcpdump OK via same proxy), packaging (identical BuildID across distribution channels), ARM64 (10/10 OK same settings), CPU count (8-core reporter identical), strace (5/5 OK under strace, classic async I/O race cure), 7 Bun tuning env flags (no effect).

Happy to run targeted traces if an instrumented build is cut.

Update — minimal repro isolated to a TCP-level pattern in CONNECT 200 response handling.

We narrowed this down to a single behavior: Bun-x64 fetch hangs when the upstream HTTP CONNECT proxy delivers HTTP/1.1 200 OK\r\n\r\n across two TCP segments instead of one.

No exotic transport involved — reproduced with a Mac on the same LAN running a 50-line Python socket proxy. Two run modes, only difference is one sendall vs two consecutive sendalls for the CONNECT 200 line.

Repro setup

• Linux x86_64 (Ubuntu 24.04.3, kernel 6.8.0-107-generic, glibc 2.39) running claude 2.1.119 (Bun-x64 native build, cc_version: 2.1.118.c75 series)
• LAN-local Mac running Python 3 with the proxy script below, listening on a Tailscale IP, port 49996
• ubr → CONNECT → Mac:49996 → upstream api.anthropic.com:443
• Test command: claude -p --dangerously-skip-permissions --verbose --output-format stream-json --model claude-haiku-4-5-20251001 'Respond with only the word ok', with a 45s timeout wrapper, repeated 5×.

Python CONNECT proxy (drop in and run)

#!/usr/bin/env python3
"""Minimal CONNECT proxy. --mode normal sends the 200 line in one sendall;
   --mode split sends "HTTP/1.1 200 OK\\r\\n" then "\\r\\n" as two sendalls."""
import argparse, socket, threading

def relay(src, dst):
    try:
        while True:
            data = src.recv(65536)
            if not data: break
            dst.sendall(data)
    except Exception: pass
    finally:
        try: src.shutdown(socket.SHUT_RD)
        except Exception: pass
        try: dst.shutdown(socket.SHUT_WR)
        except Exception: pass

def handle(client, mode):
    try:
        buf = b""
        while b"\r\n\r\n" not in buf:
            chunk = client.recv(4096)
            if not chunk: return
            buf += chunk
        first = buf.split(b"\r\n", 1)[0].decode("ascii", errors="replace")
        if not first.upper().startswith("CONNECT "):
            client.sendall(b"HTTP/1.1 405 Method Not Allowed\r\n\r\n"); return
        host, _, port = first.split(" ")[1].partition(":")
        upstream = socket.create_connection((host, int(port or 443)), timeout=10)
        if mode == "split":
            client.sendall(b"HTTP/1.1 200 OK\r\n")
            client.sendall(b"\r\n")
        else:
            client.sendall(b"HTTP/1.1 200 OK\r\n\r\n")
        t1 = threading.Thread(target=relay, args=(client, upstream), daemon=True)
        t2 = threading.Thread(target=relay, args=(upstream, client), daemon=True)
        t1.start(); t2.start(); t1.join(); t2.join()
    finally:
        try: client.close()
        except Exception: pass

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--listen", default="0.0.0.0:49996")
    ap.add_argument("--mode", choices=["normal", "split"], default="normal")
    a = ap.parse_args()
    h, _, p = a.listen.partition(":")
    s = socket.socket(); s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind((h, int(p))); s.listen(64)
    print(f"[*] listening {h}:{p} mode={a.mode}", flush=True)
    while True:
        c, _ = s.accept()
        threading.Thread(target=handle, args=(c, a.mode), daemon=True).start()

if __name__ == "__main__": main()

Results (5 trials each, exact same network, exact same destination, exact same Bun binary)

| Proxy mode | CONNECT 200 wire format | Outcome |
|---|---|---|
| --mode normal | one TCP segment: HTTP/1.1 200 OK\r\n\r\n (19 bytes) | 5/5 OK, 10-15s each |
| --mode split | two TCP segments: HTTP/1.1 200 OK\r\n (17 bytes) + \r\n (2 bytes) | 1/5 OK, 4/5 TIMEOUT at 45s; the one OK trial took 31s |

Hypothesis

Bun-x64's HTTP CONNECT response parser appears to commit to "tunnel established → switch to TLS passthrough" as soon as it sees the status line + first CRLF, without waiting for the empty-line terminator (the second \r\n). When the second \r\n arrives in a separate TCP read, those 2 bytes are consumed as if they were the start of the TLS ServerHello, the TLS record framing is then permanently misaligned by 2 bytes, and the HTTPS/2 stream can never reach END_STREAM / GOAWAY. The fetch hangs until external timeout/cancel.

This explains all of the previously-reported symptoms in this issue, including the WebFetch "cancel not honored" cases — once the TLS framing is corrupted, even an AbortSignal / socket.destroy() on Bun's side can't reach a coherent "done" state, because the application layer is still waiting for bytes that will never parse.

Why it appears intermittent on real proxies

Most production HTTP CONNECT proxies (squid, tinyproxy, Tailscale's built-in CONNECT proxy, etc.) write the entire response with a single write(2) and the kernel sends one TCP segment, so they never trigger this. Some proxy implementations — particularly transport-converting proxies that bridge TCP↔QUIC or TCP↔WebSocket — naturally split the response across packet boundaries, so they trigger it ~100% of the time. ARM64 Bun on the same network does not appear to hit this, suggesting the parser bug is specific to the x86_64 native build (or its IO read sizing).

Note

If a follow-up trace under an instrumented Bun build would help, happy to run it on the same setup. The repro takes < 1 minute end-to-end.

Cross-architecture control: aarch64 is unaffected.

Ran the same --mode split Python CONNECT proxy from the previous comment, against an aarch64 host on the same LAN, talking to the same destination over the same Tailscale link. The only variable changed is the architecture of the claude binary on the client side.

| Host | Arch | claude version | Same --mode split proxy | Result |
|---|---|---|---|---|
| Linux x86_64, kernel 6.8.0-107-generic | x86_64 | 2.1.119 | (same Python script, same Tailscale link, same upstream) | 1/5 OK, 4/5 TIMEOUT at 45s |
| Linux aarch64, kernel 6.14.0-1015-nvidia | aarch64 | 2.1.118 | same | 5/5 OK, 5-7s each |

Same 5-trial loop, same prompt, same model (claude-haiku-4-5-20251001), same --output-format stream-json --verbose. Only the architecture of the local claude binary differs.

This narrows it further: the buggy CONNECT-200 read path is in the x86_64 native build specifically, not in shared cross-platform code. Likely candidates would be x86_64-only fast paths in Bun's HTTP/socket reader (e.g. SIMD scan over the response head, or x86_64-tuned recv buffer sizing that takes a different branch when the first read returns ≤ a threshold of bytes).

Hopefully helpful for narrowing the search; happy to run any further targeted comparisons on either build.

Confirmed root cause + working sender-side workaround.

Filed an upstream issue and PR on the proxy side that triggered this in our environment:

• Issue: apernet/hysteria#1553 — client/http: CONNECT 200 reply is split across 2 TCP segments, breaking framing-sensitive clients (e.g. Bun x86_64 / Claude Code)
• PR: apernet/hysteria#1554 — 12-line patch buffering the CONNECT 200 reply into a single conn.Write so the kernel emits a single TCP segment

The hysteria-side trigger turns out to be Go stdlib net/http.Response.Write — for a ContentLength=-1 headerless response it issues two separate underlying writes (status line, then trailing CRLF), and Go defaults *net.TCPConn to TCP_NODELAY=true, so the bytes leave as two TCP segments. This matches the wire pattern the Python --mode split reproducer in comment 4319520748 was simulating.

End-to-end verification on the same machine (Ubuntu 24.04.3 x86_64, kernel 6.8.0-107, Claude Code 2.1.119):

| hysteria build | claude -p 5-trial result |
|---|---|
| v2.8.1 stock | 1/5 OK, 4/5 timeout at 45s |
| v2.8.1 + apernet/hysteria#1554 | 5/5 OK, 9–15s each |

tcpdump -i lo on the local proxy port confirms the 200 response is now a single 19-byte TCP segment (was 17 + 2 before).

This is a sender-side workaround that unblocks anyone hitting this through hysteria2; it does not address the underlying Bun-x86_64 CONNECT/TLS framing fragility, which still affects any other CONNECT proxy that happens to split the response (transport-converting proxies, some QUIC/WebSocket bridges, etc.). Posting in case it helps narrow the search on the Bun side: the fragile path is "first segment ends exactly at status-line \r\n, second segment is just the empty-line \r\n" — Bun-aarch64 handles this fine, only Bun-x86_64 misframes.

Happy to run any further targeted comparisons against either build.

I'm not sure if this is related but I'm not seeing my HTTP_PROXY and HTTPS_PROXY env vars reliably passed through claude into Bash subprocesses like I used to on windows. I tried setting 'settings.enableWeakerNetworkIsolation' but that only let HTTP_PROXY pass through, not HTTPS_PROXY. I can't use settings.json since my port changes per claude instance.

Workaround confirmed on aarch64 / claude-code 2.1.131 — rebuild hysteria with apernet/hysteria#1554

Adding a data point that the architecture profile has shifted on recent claude-code releases:

| host | claude-code | local proxy | result with stock hysteria |
|---|---|---|---|
| Raspberry Pi 4 Model B Rev 1.5, aarch64, Ubuntu 24.04.4 LTS, kernel 6.8.0-1053-raspi | 2.1.131 (Bun native) | hysteria2 client v2.9.1, HTTP listener | TLS handshake hang / fetch timeout — same symptom previously reported only on x86_64 |

So the earlier "Bun-aarch64 is not affected" cross-arch result from the 2.1.118/2.1.119 era no longer holds on 2.1.131. Whether the cause is a Bun upgrade or something else in the native build, I haven't dug in — but anyone on ARM seeing the same hangs should know the workaround tree is now the same as for x86_64.

Sender-side fix that I just verified works end-to-end (system has Go, native build on the Pi):

git clone https://github.com/apernet/hysteria.git
cd hysteria
git checkout app/v2.9.1
curl -sSL https://github.com/apernet/hysteria/pull/1554.diff | git apply --3way
python3 -m pip install -r requirements.txt
python3 hyperbole.py build
# replace the system binary with ./build/hysteria-linux-arm64

After swap-in, claude operations through the same proxy went from intermittent hangs to clean. Until either the Bun-side parser fix lands here or apernet/hysteria#1554 merges upstream, this is the cleanest workaround for ARM users behind hysteria2.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.