Bug Browser CDP Mode Broken on Windows with Chrome 145

[Haulz_WU]

# [Bug] Browser CDP mode broken on Windows with Chrome 145 — language_server Playwright incompatibility

## Environment

- **OS**: Windows 10 (x64)

- **Antigravity Version**: Latest (Feb 2026)

- **Chrome Version**: 145.0.7632.110

- **language_server**: `language_server_windows_x64.exe`

## Description

The browser subagent (CDP mode) completely fails on Windows. Every `open_browser_url` call fails with:

```

failed to connect to browser via CDP even though the CDP port is responsive:

http://127.0.0.1:9222: playwright: Unexpected status 400 when connecting to

http://127.0.0.1:9222/json/version/.

This does not look like a DevTools server, try connecting via ws://.

```

**The same setup works fine on macOS.**

## Root Cause Analysis

After extensive debugging, I confirmed the issue is **inside the `language_server` binary’s bundled Playwright**, not Chrome or any external configuration.

### Evidence: External Playwright works perfectly

```bash

$ npm install playwright-core

$ node -e "

const { chromium } = require(‘playwright-core’);

(async () => {

const browser = await chromium.connectOverCDP(‘http://127.0.0.1:9222’);

console.log(‘Connected:’, browser.version());

const page = await browser.contexts()[0].newPage();

await page.goto(‘https://www.example.com’);

console.log(‘Title:’, await page.title());

await browser.close();

})();"

```

**Output:**

```

Connected: 145.0.7632.110

Title: Example Domain

```

### Evidence: All other HTTP clients work

| Client | Request to `/json/version/` | Status |

|--------|---------------------------|--------|

| `curl.exe` | 200 OK | Works |

| PowerShell `Invoke-WebRequest` | 200 OK | Works |

| Node.js `http.request` | 200 OK | Works |

| External `playwright-core` (latest) | Connected + page loaded | Works |

| **Antigravity `language_server` internal Playwright** | **HTTP 400** | **Broken** |

### Hypotheses Ruled Out

- Chrome version incompatibility — external Playwright connects fine

- Missing `HOME` environment variable — set it, no effect

- Corrupted browser profile — deleted and recreated, no effect

- HTTP proxy interference — removed all proxy settings, no effect; system proxy is disabled

- Port conflict — port 9222 is exclusively used by Antigravity’s managed Chrome

- Multiple Chrome instances conflicting — external Playwright works even with multiple Chrome instances running

## Conclusion

The `language_server_windows_x64.exe` bundles an older or modified version of Playwright whose `connectOverCDP` implementation is incompatible with Chrome 145 on Windows. The latest Playwright-core (npm) works perfectly with the exact same Chrome instance on the exact same machine.

## Expected Behavior

Browser subagent should successfully connect to Chrome via CDP on Windows, just as it does on macOS.

## Steps to Reproduce

1. Install Antigravity on Windows with Chrome 145+

2. Attempt any browser subagent task (e.g., navigate to a URL)

3. Observe the `Unexpected status 400` error

## Suggested Fix

Update the Playwright version bundled inside `language_server_windows_x64.exe` to match the latest `playwright-core` which handles Chrome 145 CDP correctly.

[buyuan_xu]

Hey everyone! I was stuck in the exact same nightmare with the Unexpected status 400 error in Antigravity. Like many of you, I went down the rabbit hole of downgrading Chrome to v144, clearing out profile caches, and killing background processes… but nothing worked.

After hours of debugging, I discovered a massive plot twist: Chrome is completely innocent.

If you are using a local proxy or VPN (like Clash) and have an "http.proxy" configured in your settings, it forces all traffic through it.

When Antigravity’s Playwright tries to connect to the local Chrome instance at 127.0.0.1:9222, that request gets hijacked by your proxy software. The proxy doesn’t know how to handle this local loopback request, panics, and immediately throws back a 400 Bad Request error. Playwright never even reached Chrome!

Why the OP’s standalone Playwright test worked

This also perfectly explains why the original author mentioned that using the raw playwright package directly worked fine!

When you run a standalone Playwright script from your terminal, it doesn’t read the "http.proxy" configured inside your settings.json. Since no proxy was intercepting the raw script, it connected to local Chrome directly without any issues. But the moment it runs inside the extension environment with the proxy setting, it gets trapped and throws the 400 error.

The 30-Second Fix

You just need to add a proxy bypass list to tell your environment to ignore the proxy for local connections.

1. Open your settings.json (where you configure Antigravity/VS Code).

2. Find your existing "http.proxy" setting.

3. Add the "http.noProxy" array right below it, exactly like this:

JSON

{
    "http.proxy": "http://127.0.0.1:7890", // (Your proxy port might be different)
    "http.noProxy": [
        "127.0.0.1",
        "localhost",
        "::1"
    ]
}

4. Save the file and completely restart your editor/environment.

Once I added this bypass list, the proxy stopped intercepting the local connection, Antigravity instantly connected to Chrome, and the 400 error was gone forever. You can probably even go back to the latest Chrome version now!