Summary
browseros-claw-server.exe accumulates ESTABLISHED loopback TCP connections that are never reaped after the client disappears. The count only ever goes up. Over days this can hold thousands of sockets, and because Windows TCP ephemeral ports are a machine-wide finite pool, the accumulation can push the entire system into socket-exhaustion (WSAENOBUFS / error 10055 on every new bind) — at which point every application's new network connections fail, not just BrowserOS.
Impact (measured)
| Date |
Server-side ESTABLISHED sockets |
Note |
| 2026-09-02 → 09-07 |
13,870 |
one server process, ~5 days uptime |
| 2026-09-08 (after restart) |
7 → 74 → 387 → 2,052 |
re-accumulated within hours |
On 2026-09-07 the machine (Win10, Clash Verge TUN) suffered system-wide network failure: the proxy core's log showed every new outbound dial failing with bind: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full (WSAENOBUFS, 10055) — including DIRECT dials of unrelated apps (Feishu, Nutstore). Established streams kept working; every NEW connection was refused instantly. Restarting browseros-claw-server (releasing ~13.9k sockets) was the primary recovery step.
Root cause evidence: orphaned connections, not live load
The server accepts everything onto a single hub port (changes per launch; 9210/9212 observed). Cross-checking both sides of the pair:
- Server side: sockets owned by
browseros-claw-server.exe with local port 9210, state ESTABLISHED → 2,052
- Client side: sockets of any process with remote port 9210, state ESTABLISHED → 8 (7 chrome.exe + 1 unrelated app)
So ~2,044 of 2,052 server-side sockets have no living peer: their clients (agent MCP clients, browser tabs/panels, tool sessions) vanished without a graceful close, and the server never noticed. Loopback TCP has no inherent timeout, and the server evidently sets neither TCP keepalive nor an application-level heartbeat/reaper, so dead peers are kept ESTABLISHED forever. Growth resumes immediately after every restart (new process: 2 connections at spawn, 11 within minutes).
Environment
|
|
| OS |
Windows 10 Pro 19045, x64 |
| Browser |
BrowserClaw (BrowserOS neo), Chromium 148.0.7988.97 |
| claw-server |
0.0.50 — ...\User Data\.browseros\BrowserClawServer\versions\0.0.50\resources\bin\browseros-claw-server.exe, spawned by chrome.exe with --config=... |
| Clients observed |
BrowserClaw chrome.exe (tabs/panels), external agent processes (MCP clients) |
Steps to reproduce
-
Use BrowserOS/agent tooling normally (tabs opened/closed, agent sessions start/abort) over a day or more — kills/aborts seem to accelerate it.
-
Watch the growth (server PID via Get-Process browseros-claw-server):
netstat -ano -p tcp | findstr /c:"<PID>"
-
Cross-check live peers vs server-side sockets (hub port from Get-NetTCPConnection -State Listen):
# server side (should ≈ total)
(Get-NetTCPConnection -State Established -OwningProcess <PID>).Count
# live clients (the real number)
(Get-NetTCPConnection -State Established -RemotePort 9210).Count
The gap is the orphan count and it only grows.
Expected behavior
Connections whose peer is gone should be detected and closed within minutes, and the steady-state connection count should track actual live clients (single/double digits), not grow without bound.
Suggested fixes
- Enable TCP keepalive on accepted sockets (e.g. idle 60s, interval 10s, 3 probes) — detects a vanished peer in ~90s.
- Or an application-level heartbeat (ping/pong) with per-connection timeout.
- Or a watchdog that reaps connections with no read/write activity for N minutes.
- A connection-count high-water log/metric would also make this diagnosable in the wild.
Workaround (until fixed)
Kill the server; the browser respawns it within seconds (confirmed working; also see #1850 for the manual launch command). Restart daily until a fix lands.
Related
Summary
browseros-claw-server.exeaccumulates ESTABLISHED loopback TCP connections that are never reaped after the client disappears. The count only ever goes up. Over days this can hold thousands of sockets, and because Windows TCP ephemeral ports are a machine-wide finite pool, the accumulation can push the entire system into socket-exhaustion (WSAENOBUFS / error 10055 on every new bind) — at which point every application's new network connections fail, not just BrowserOS.Impact (measured)
On 2026-09-07 the machine (Win10, Clash Verge TUN) suffered system-wide network failure: the proxy core's log showed every new outbound dial failing with
bind: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full(WSAENOBUFS, 10055) — including DIRECT dials of unrelated apps (Feishu, Nutstore). Established streams kept working; every NEW connection was refused instantly. Restarting browseros-claw-server (releasing ~13.9k sockets) was the primary recovery step.Root cause evidence: orphaned connections, not live load
The server accepts everything onto a single hub port (changes per launch; 9210/9212 observed). Cross-checking both sides of the pair:
browseros-claw-server.exewith local port 9210, state ESTABLISHED → 2,052So ~2,044 of 2,052 server-side sockets have no living peer: their clients (agent MCP clients, browser tabs/panels, tool sessions) vanished without a graceful close, and the server never noticed. Loopback TCP has no inherent timeout, and the server evidently sets neither TCP keepalive nor an application-level heartbeat/reaper, so dead peers are kept ESTABLISHED forever. Growth resumes immediately after every restart (new process: 2 connections at spawn, 11 within minutes).
Environment
...\User Data\.browseros\BrowserClawServer\versions\0.0.50\resources\bin\browseros-claw-server.exe, spawned by chrome.exe with--config=...Steps to reproduce
Use BrowserOS/agent tooling normally (tabs opened/closed, agent sessions start/abort) over a day or more — kills/aborts seem to accelerate it.
Watch the growth (server PID via
Get-Process browseros-claw-server):Cross-check live peers vs server-side sockets (hub port from
Get-NetTCPConnection -State Listen):The gap is the orphan count and it only grows.
Expected behavior
Connections whose peer is gone should be detected and closed within minutes, and the steady-state connection count should track actual live clients (single/double digits), not grow without bound.
Suggested fixes
Workaround (until fixed)
Kill the server; the browser respawns it within seconds (confirmed working; also see #1850 for the manual launch command). Restart daily until a fix lands.
Related
cmd.exe(regression vs upstream M113), orphaning host processes — 1,196 leaked processes / 20 GB / 318k handles in 21 hours #2072 — Windows native messaging hosts orphaned via cmd.exe (Windows process-lifecycle leak, different component)