Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When proxy.enabled: true is configured (e.g. forward proxy to a host on the LAN such as Clash on Windows from WSL), openclaw browser snapshot fails with Playwright browserType.connectOverCDP: WebSocket error: socket hang up on loopback CDP (ws://127.0.0.1:<cdpPort>/devtools/browser/...).
Other browser operations on the same profile often still work: start, tabs, open, screenshot.
Disabling proxy.enabled and restarting the Gateway makes snapshot succeed immediately, without changing browser.* or CDP ports.
This looks like a gap between managed-proxy CDP bypass (already used for HTTP CDP fetch / WebSocket helpers) and the Playwright connectOverCDP path used by snapshot.

Steps to reproduce

Environment

• OpenClaw version: 2026.6.11 (build e085fa1)
• OS: WSL2 Ubuntu on Windows (classic NAT, not mirrored networking)
• Gateway: systemd user service, gateway.port: 18789, loopback bind
• Browser profile: openclaw, managed Chrome google-chrome-stable, headless, attachOnly: false
• Proxy: proxy.enabled: true, proxy.proxyUrl: http://<WIN_HOST>:7078 (HTTP forward proxy on Windows)
• CDP: default derived port 18800, cdpUrl: http://127.0.0.1:18800 (unchanged)

Steps to reproduce

1. Configure global proxy and browser (minimal):

   {
     proxy: { enabled: true, proxyUrl: "http://<LAN_HOST>:7078" },
     browser: {
       enabled: true,
       defaultProfile: "openclaw",
       executablePath: "/usr/bin/google-chrome-stable",
       headless: true,
       noSandbox: true,
       attachOnly: false,
       extraArgs: ["--disable-dev-shm-usage", "--disable-gpu"],
     },
     plugins: { entries: { browser: { enabled: true } } },
     tools: { alsoAllow: ["browser"] },
   }

Expected behavior

snapshot should work with proxy.enabled: true, because loopback browser CDP (127.0.0.1:) should not be routed through the external forward proxy (same intent as existing CDP SSRF / loopback handling in browser docs).

Actual behavior

snapshot fails, for example:

GatewayClientRequestError: Error: browserType.connectOverCDP: WebSocket error: socket hang up
Call log:

• ws://127.0.0.1:18800/devtools/browser/
• ... error socket hang up
  Gateway logs may show browser.request timing out (~20–23s) or failing with the same error.

With the same Chrome/CDP setup:

curl -s http://127.0.0.1:18800/json/version → OK
openclaw browser --browser-profile openclaw tabs → OK
openclaw browser --browser-profile openclaw screenshot → OK

OpenClaw version

2026.6.11

Operating system

win11->wsl2->ubuntu24.04

Install method

No response

Model

anthropic/claude-sonnet-4.6

Provider / routing chain

openclaw->clash->openrouter->auto

Additional provider/model setup details

No response

Logs

GatewayClientRequestError: Error: browserType.connectOverCDP: WebSocket error: socket hang up
Call log:
  - <ws connecting> ws://127.0.0.1:18800/devtools/browser/5a6883f0-c26e-4b4b-9f6e-61b35ec35891
  - <ws error> ws://127.0.0.1:18800/devtools/browser/5a6883f0-c26e-4b4b-9f6e-61b35ec35891 error socket hang up
  - <ws connect error> ws://127.0.0.1:18800/devtools/browser/5a6883f0-c26e-4b4b-9f6e-61b35ec35891 socket hang up
  - <ws disconnected> ws://127.0.0.1:18800/devtools/browser/5a6883f0-c26e-4b4b-9f6e-61b35ec35891 code=1006 reason=

Screenshots, recordings, and evidence

No response

Impact and severity

No response

Additional information

##Control experiment
Set proxy.enabled: false, openclaw gateway restart, repeat steps 3–5 → snapshot succeeds (AI/ARIA tree with refs).

No change to cdpPort / cdpUrl / WIN_HOST in browser config is required for the fix.

##Analysis (suspected root cause)
1.startProxy() enables Proxyline process-wide routing when proxy.enabled is true (proxy-lifecycle, applyProxyEnv clears NO_PROXY, etc.).
2.HTTP CDP paths use fetchCdpChecked / openCdpWebSocket, which wrap calls with withManagedProxyForCdpUrl + withNoProxyForCdpUrl (cdp.helpers).
3.Playwright connection in connectBrowser() (pw-ai-*.js) uses only withNoProxyForCdpUrl around chromium.connectOverCDP, without withManagedProxyForCdpUrl / registerManagedProxyBrowserCdpBypass for the loopback CDP URL.
So loopback CDP WebSocket used by snapshot may still be affected by managed proxy routing, while lighter paths (e.g. screenshot) may not hit the same failure mode.

Related comment in tree: CDP proxy bypass issue reference in cdp-proxy-bypass.ts (e.g. #31219).

##Suggested fix
In connectBrowser → connectEndpoint, mirror fetchCdpChecked:

const release = registerManagedProxyBrowserCdpBypass(target);
try {
return await withNoProxyForCdpUrl(target, () =>
chromium.connectOverCDP(target, { timeout, headers })
);
} finally {
release?.();
}
Ensure proxy.loopbackMode: "gateway-only" (default) continues to register bypass for loopback CDP during Playwright attach.

##Workaround (local)
Until fixed upstream: temporarily proxy.enabled: false when using browser snapshot (breaks LLM proxy), or apply a one-line local patch to dist/pw-ai-*.js as above (must be reapplied after npm update).

##Additional notes
Not caused by using WSL gateway IP for proxy.proxyUrl vs mirrored networking; browser CDP correctly stays on WSL 127.0.0.1.
Do not point browser.profiles.openclaw.cdpUrl at WIN_HOST for this scenario (that is a different remote-CDP setup).