Skip to content

fix(launcher): add --remote-allow-origins=* for Chromium 142+ ws origin check#1789

Merged
jackwener merged 2 commits into
jackwener:mainfrom
LeoLin990405:fix/chromium-142-ws-origin-check
May 31, 2026
Merged

fix(launcher): add --remote-allow-origins=* for Chromium 142+ ws origin check#1789
jackwener merged 2 commits into
jackwener:mainfrom
LeoLin990405:fix/chromium-142-ws-origin-check

Conversation

@LeoLin990405
Copy link
Copy Markdown
Contributor

What

When opencli auto-launches an Electron app (codex, doubao, antigravity, chatgpt), pass --remote-allow-origins=* alongside --remote-debugging-port=<port>.

Why

Chrome / Electron 142+ enforces an Origin allow-list on the CDP WebSocket upgrade at ws://127.0.0.1:<port>/devtools/page/<id>. Without the flag, any external ws client gets HTTP 403:

Rejected an incoming WebSocket connection from the
http://127.0.0.1:<port> origin. Use the command line flag
--remote-allow-origins=http://127.0.0.1:<port> to allow connections
from this origin or --remote-allow-origins=* to allow all origins.

This bites the moment someone pairs opencli with an external CDP ws debugger — Python websocket-client, raw curl, headless Puppeteer attached after launch, custom MCP servers, etc. opencli's own internal CDP client happens to work because chrome-devtools-protocol uses a chrome:// origin, but anything else fails.

How does Puppeteer / Playwright / chrome-devtools-mcp handle this?

Same way — they all set --remote-allow-origins=* by default:

Side effects

None for opencli's own usage. The flag controls which origins can establish a CDP ws upgrade, not which network interfaces the CDP server binds to. CDP is still localhost-only — Chromium's --remote-debugging-port binds 127.0.0.1.

Tested

  • tsc --build clean
  • vitest run launcher.test.ts → 9 passed / 1 skipped (pre-existing skipped)
  • Verified on macOS 15.4 with Electron 142.0.6953.13 (Antigravity build) — ws upgrade now succeeds from python -m websocket without the 403.

Diff

@@ -253,7 +253,18 @@ export async function ensureCdpEndpoint(...) {

   // Step 4: Launch
-  const args = [`--remote-debugging-port=${port}`, ...(app.extraArgs ?? [])];
+  //
+  // Chrome / Electron 142+ enforces an Origin allow-list on the CDP
+  // WebSocket upgrade ... [see commit message]
+  const args = [
+    `--remote-debugging-port=${port}`,
+    '--remote-allow-origins=*',
+    ...(app.extraArgs ?? []),
+  ];
   await launchElectronApp(appPath, app, args, label);

…in check

Chrome / Electron 142+ enforces an Origin allow-list on the CDP WebSocket
upgrade at ws://127.0.0.1:<port>/devtools/page/<id>. Without this flag,
any external ws client (Python's websocket-client, raw curl, headless
Puppeteer attached after the fact, etc.) gets HTTP 403:

    Rejected an incoming WebSocket connection from the
    http://127.0.0.1:<port> origin. Use the command line flag
    --remote-allow-origins=http://127.0.0.1:<port> to allow
    connections from this origin or --remote-allow-origins=* to
    allow all origins.

This affects every Electron app opencli auto-launches (codex, doubao,
antigravity, chatgpt) because they all bundle recent Chromium. opencli's
own internal CDP client happens to work because chrome-devtools-protocol
sets a chrome:// origin, but anything else fails — which surfaces
immediately the moment a user pairs opencli with an external ws debugger.

Same mitigation Puppeteer (commit f1b8617), Playwright (commit 24f2ce5),
and chrome-devtools-mcp use: pass --remote-allow-origins=* on launch.

Side effects: None for opencli's own usage. The flag only affects which
origins can establish a CDP ws upgrade — it doesn't open any new
network surface (CDP is still localhost-only because Chromium's
--remote-debugging-port binds to 127.0.0.1 by default).

Verified:
  · tsc --build passes
  · vitest launcher.test.ts: 9 passed | 1 skipped
@jackwener jackwener merged commit a73301f into jackwener:main May 31, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants