Browser Agent / CDP Behavior Is Inconsistent Across Windows, WSL, and Multi-SSH Clients

Google Antigravity
1

Summary

I am experiencing inconsistent and confusing behavior when using Antigravity’s browser agent (Chrome via CDP) across the following environments:

  • Windows (local)

  • WSL2 running on Windows

  • macOS connecting via SSH to the same WSL instance

The issue appears to involve Chrome DevTools Protocol (CDP, port 9222), process ownership, and which machine actually launches the Chrome UI when multiple SSH clients or mixed local/remote environments are involved.

Environment

  • Host OS: Windows

  • Subsystem: WSL2

  • Remote client: macOS (SSH into WSL)

  • Browser: Google Chrome

  • Browser control: Chrome DevTools Protocol (CDP, port 9222)

  • Tool: Antigravity Browser Agent (Playwright-based)

Expected Behavior

When starting the browser agent:

  • Chrome should be launched on the same physical machine where the agent is running.

  • Chrome should be launched with CDP enabled (--remote-debugging-port=9222).

  • The agent should successfully connect to http://127.0.0.1:9222.

  • A browser context should be created and a URL should be opened automatically.

Observed Behavior

Case 1: Windows & WSL (after Windows reboot)

Windows local Antigravity browser

  • Works as expected.

  • Chrome launches on Windows.

  • The browser agent successfully opens the target URL.

  • CDP connection appears to be functional.

WSL Antigravity browser (running on the same Windows machine)

  • Chrome does launch on Windows.

  • However:

    • No URL is opened in the Chrome window.

    • The browser agent logs show CDP connection failures:

2026-01-24 21:12:30.111 [info] W0124 21:12:30.110964   847 browser_liveness_utils.go:122] Connecting to browser via CDP: http://127.0.0.1:92222026-01-24 21:12:35.125 [info] E0124 21:12:35.125349   847 log.go:354] failed to connect to browser via CDP: http://127.0.0.1:9222. CDP port not responsive in 5s: playwright: connect ECONNREFUSED 127.0.0.1:92222026-01-24 21:12:35.125 [info] E0124 21:12:35.125660   847 interceptor.go:74] /exa.language_server_pb.LanguageServerService/SmartOpenBrowser (unknown): Failed to smart open browser: failed to create browser context: failed to create browser instance: failed to connect to browser via CDP: http://127.0.0.1:9222. CDP port not responsive in 5s: playwright: connect ECONNREFUSED 127.0.0.1:92222026-01-24 21:12:54.504 [info] E0124 21:12:54.503869   847 log.go:354] Post "https://antigravity-unleash.goog/api/client/metrics": dial tcp: lookup antigravity-unleash.goog on 10.255.255.254:53: read udp 10.255.255.254:60917->10.255.255.254:53: i/o timeout: Post "https://antigravity-unleash.goog/api/client/metrics": dial tcp: lookup antigravity-unleash.goog on 10.255.255.254:53: read udp 10.255.255.254:60917->10.255.255.254:53: i/o timeout

  • This indicates:

    • Chrome UI is started from a WSL-triggered browser launch,
    • but the Chrome instance is not reachable via CDP from WSL,
    • therefore the browser context cannot be created and no URL is injected.

Case 2: macOS SSH → WSL, then Windows-side WSL agent run

This is the most confusing scenario.

Steps

  1. macOS SSHs into the Windows WSL instance.

    • Clicking “Open Browser” from macOS works correctly.

  2. Then, clicking “Open Browser” from Antigravity on Windows connected to the same WSL instance.

Observations

  • Chrome does NOT appear on Windows.

  • Chrome appears on macOS, even though:

    • Antigravity

    • WSL

    • the browser agent
      are all logically associated with the Windows machine.

  • The Chrome window on macOS shows a localhost:<port> URL.

  • That URL:

    • :cross_mark: Cannot be opened from macOS

    • :white_check_mark: Can be opened successfully if copied into Windows Chrome

Strong Implication

This strongly suggests that:

  • The browser UI is being launched on the SSH client machine (macOS),

  • while the actual HTTP/CDP service is bound to Windows localhost.

This results in a split-brain situation where:

  • UI and backend are on different machines,

  • and localhost refers to different physical hosts.

Current Understanding / Hypothesis

Based on the above tests:

  • Chrome UI launch and CDP availability are not consistently coupled.

  • WSL-triggered browser launches can start Chrome UI on Windows, but:

    • the Chrome instance is not reachable via CDP from WSL.

  • In multi-SSH scenarios, browser UI may be launched on the SSH client machine rather than the actual host where the agent is running.

  • Existing desktop Chrome instances (not launched with CDP flags) may interfere with browser agent attachment.