[CMGS]

proxy_port runs two threads per connection: one pumps the guest side into the local socket, the other pumps the local socket into the guest. When the guest side reached EOF the first thread closed the local socket.

On Linux that close cannot wake the second thread, which is already blocked in recv on that same socket, and the socket outlives the close until that read ends — so the FIN never reaches the client. A connection to a guest port whose upstream refuses hangs instead of ending.

Measured against a guest bridge with nothing behind it:

in the guest,  curl 127.0.0.1:9222  ->  000 in 13 ms      (the bridge closes correctly)
through proxy_port,  connect + read ->  still blocked at 30 s
dial_port on the same port          ->  EOF in 0.01 s     (silkd and the SDK's own stream are fine)

A caller that retries on a refused connection pays the full socket timeout instead: OSWorld's browser setup retries every five seconds for fifteen attempts, and the first attempt alone cost 180 seconds on every task that launches a browser.

Half-closing is the fix, and it is the shape sdk/go's proxyConn already uses — closeWrite(local) once io.Copy(local, guest) returns. The local read loop then ends on its own when the client closes, and the socket is closed in the finally once both directions are done. The read loop also stops raising OSError into a thread that has no handler for it.

Verification

The regression test drives proxy_port with a guest conn that reports EOF while the local client is idle, which is the state the race needs:

Linux, released code : FAILED … TimeoutError: timed out
Linux, with the fix  : 2 passed

macOS delivers the FIN either way, so the test only reproduces on Linux — which is where CI runs it.

Gates from sdk/python: ruff format --check clean, ruff check clean, pytest 156 passed.