Sandbox network proxy truncates the tail of streaming responses (kubectl exec/cp lose up to ~50 KB with "unexpected EOF")

Summary

When a Bash command runs inside the sandbox, long-lived streaming connections tunneled through the sandbox's HTTP proxy lose data at the end of the stream. kubectl exec output and kubectl cp from a pod come back short, and the client reports error reading from error stream: … unexpected EOF. The same commands with the sandbox disabled are byte-complete.

Reproduce

Any Kubernetes cluster; the API host is added via allowed_domains.

kubectl run trunc --image=busybox:stable --restart=Never -- sleep 900
kubectl wait --for=condition=Ready pod/trunc
for n in 524288 1048576 2097152; do
  for t in 1 2 3; do kubectl exec trunc -- head -c $n /dev/urandom | wc -c; done
done

Results

kubectl v1.33.9, server v1.35.3, macOS, Claude Code 2.1.280.

| Bytes requested | Inside sandbox (3 runs) | Sandbox disabled (3 runs) |
|---|---|---|
| 524,288 | 479,232 / 507,904 / 520,187 | complete ×3 |
| 1,048,576 | 974,848 / 946,176 / 1,048,576 | complete ×3 |
| 2,097,152 | 2,076,672 / 2,064,384 / 2,084,864 | complete ×3 |
| 8,388,608 | (not run) | complete ×3 |

kubectl cp pod:/file . of 4 MiB is complete 3 of 3 times outside the sandbox and short 3 of 3 times inside. Switching kubectl from WebSockets to SPDY (KUBECTL_REMOTE_COMMAND_WEBSOCKETS=false) still truncates. Data sent into the pod is unaffected, and so is plain kubectl logs of 1 MB.

Likely cause

The proxy appears to close the tunnel as soon as the upstream half-closes, without first forwarding the bytes still buffered for the client. The loss is always at the end of the stream and varies from run to run.

Impact

Agents that use kubectl exec/cp inside the sandbox silently receive truncated files. This hits Inspect's Kubernetes sandbox (read_file goes through exec) and any similar workflow. It's easy to misread as a cluster bug: we first blamed the cluster.

🤖 Generated with Claude Code