Re-key playwright-core Bun ws patch to 1.61.1

The 1.61.0->1.61.1 bump leaves patchedDependencies keyed to
playwright-core@1.61.0, so the bundled-ws->built-in-ws patch silently
stops applying. playwright-core 1.61.1 still ships the unpatched
`var ws = wrapper_default;`, which deadlocks the CDP websocket handshake
under Bun. Re-key the patch (content unchanged, still applies cleanly to
the 1.61.1 bundle), regenerate the lockfile, and update the patch-filename
citations in the browser tooling and the browser-automation-engine ADR.

Author: PotatoParser

bun.lock

@@ -0,0 +1,32 @@
+// Live check: does playwright-core 1.61.1 (patched) complete a CDP websocket
+// handshake under Bun? Without the bundled-ws->built-in-ws patch this deadlocks.
+import { chromium } from "playwright-core";
+
+const port = 9333;
+const server = await chromium.launchServer({
+  headless: true,
+  args: [`--remote-debugging-port=${port}`],
+});
+const wsEndpoint = server.wsEndpoint();
+console.log("launched, wsEndpoint:", wsEndpoint);
+
+// Derive the browser-level CDP http endpoint and fetch the ws url, then attach.
+const res = await fetch(`http://127.0.0.1:${port}/json/version`);
+const info = await res.json();
+const cdpWs = info.webSocketDebuggerUrl as string;
+console.log("cdp ws url:", cdpWs);
+
+const t0 = Bun.nanoseconds();
+const browser = await chromium.connectOverCDP(cdpWs);
+const elapsedMs = (Bun.nanoseconds() - t0) / 1e6;
+console.log("connectOverCDP RESOLVED in", elapsedMs.toFixed(1), "ms");
+
+const ctx = browser.contexts()[0] ?? (await browser.newContext());
+const page = ctx.pages()[0] ?? (await ctx.newPage());
+await page.goto("data:text/html,<title>patchcheck</title><h1>ok</h1>");
+const title = await page.title();
+console.log("page title:", title);
+
+await browser.close();
+await server.close();
+console.log("RESULT: PASS — CDP handshake completed under Bun, no deadlock");

cdp-live-test.ts

@@ -22,7 +22,7 @@ Findings from source inspection (v0.27.1) and external research:
 
 1. **The subprocess boundary is incompatible with our trust model.** Per [Browser Fill Secret](browser-fill-secret.md) and [Browser Stealth Identity](browser-stealth-identity.md), every string that leaves the browser layer passes through per-task + cross-task secret redaction, navigation passes through SSRF/DNS-rebinding pre-flight and post-redirect re-validation, screenshots go only to a vision side-call with pre-blur and post-OCR redaction, and uploads are approval-gated. All of that lives on in-process hooks into the Playwright session. agent-browser offers no interception points — adopting it means rebuilding the trust machinery as wrappers around opaque CLI text output, or weakening it.
 2. **Its core innovation is one we already have.** The `@eN` ref snapshot model — the reason agent-browser wins benchmarks against Playwright MCP — is structurally what `src/tools/browser.ts` already produces, with budgeting agent-browser lacks (32 KB default cap, hidden-element budget, middle-out truncation).
-3. **It is weakest exactly where we need the most reliability.** Headed connect for user sign-in and CDP attach to the user's own Chrome had open bugs at evaluation; the CDP-attach issue under Bun (playwright-core's bundled `ws` deadlocking the websocket handshake) is fixed in-place by `patches/playwright-core@1.61.0.patch` — a far smaller intervention than swapping the engine for one with the same class of bug and no API contract.
+3. **It is weakest exactly where we need the most reliability.** Headed connect for user sign-in and CDP attach to the user's own Chrome had open bugs at evaluation; the CDP-attach issue under Bun (playwright-core's bundled `ws` deadlocking the websocket handshake) is fixed in-place by `patches/playwright-core@1.61.1.patch` — a far smaller intervention than swapping the engine for one with the same class of bug and no API contract.
 4. **Dependency risk.** Pre-1.0, single-maintainer, experimental org, one rewrite already behind it — a poor foundation for a security-sensitive layer whose host has no programmatic contract with it.
 
 agent-browser stays in our *development* workflow (driving the Next.js dev server for QA, per `CLAUDE.md`) — that use is interactive, low-trust, and plays to its strengths. This ADR is only about Gini's runtime browser tools.
@@ -62,7 +62,7 @@ The runtime's DEFAULT transport is a per-instance branded Chrome it **spawns its
 
 `src/tools/chrome-launch.ts` (`launchSpawnedChrome`) launches a branded Chrome via `chromium.launchPersistentContext` over Playwright's pipe transport — `--headless=new` + the shared stealth args + a clean (non-`HeadlessChrome`) UA + the per-instance `--user-data-dir` + a free-picked `--remote-debugging-port`. `launchPersistentContext` drives the spawned page over the pipe inherently; the TCP debug port is an extra local endpoint the sign-in screencast bridge attaches to over raw CDP, **not** the automation transport. On a machine with neither a branded Chrome nor Playwright's bundled Chromium on disk, the launch downloads Playwright's Chromium on demand (`src/tools/chrome-install.ts`) and retries — so "no Chrome installed" is a supported, self-provisioning case rather than a hard failure.
 
-The cdp attach (`cdpSessionProvider` in `src/tools/browser.ts`) calls `chromium.connectOverCDP(record.cdpUrl)` to the user's external Chrome and reuses its first context. We never spawn or signal that process: disconnect calls `Browser.disconnect()` when present and NEVER `close()` (which on some Playwright builds would kill the user's Chrome). `connectOverCDP` works under Bun via `patches/playwright-core@1.61.0.patch`, which routes playwright-core's bundled `ws` to Bun's built-in `ws` — without it the websocket handshake deadlocks. The cdp attach is an opt-in transport (the user must point the runtime at their own Chrome) rather than the default.
+The cdp attach (`cdpSessionProvider` in `src/tools/browser.ts`) calls `chromium.connectOverCDP(record.cdpUrl)` to the user's external Chrome and reuses its first context. We never spawn or signal that process: disconnect calls `Browser.disconnect()` when present and NEVER `close()` (which on some Playwright builds would kill the user's Chrome). `connectOverCDP` works under Bun via `patches/playwright-core@1.61.1.patch`, which routes playwright-core's bundled `ws` to Bun's built-in `ws` — without it the websocket handshake deadlocks. The cdp attach is an opt-in transport (the user must point the runtime at their own Chrome) rather than the default.
 
 The active handle (spawned or cdp) installs into the single per-instance `shared` slot — one shared browser per instance (cookies bleed across tasks within the instance, per the explicit product decision). For the spawned handle, teardown closes the persistent context and, only if that wedges, reaps the Chrome bound to the instance's own profile dir (never `killall`, never the user's own `:9222`). See [Browser Stealth Identity](browser-stealth-identity.md).
 

docs/adr/browser-automation-engine.md

@@ -41,6 +41,6 @@
     "protobufjs"
   ],
   "patchedDependencies": {
-    "playwright-core@1.61.0": "patches/playwright-core@1.61.0.patch"
+    "playwright-core@1.61.1": "patches/playwright-core@1.61.1.patch"
   }
 }

package.json

@@ -19,7 +19,7 @@
 //     URL. We probe the endpoint, persist the URL (credentials stripped) as the
 //     `state.browser` record, and attach over CDP — never spawning or signalling
 //     that process. connectOverCDP works under Bun via the bundled-ws→built-in
-//     patch (patches/playwright-core@1.61.0.patch); it's an opt-in transport for
+//     patch (patches/playwright-core@1.61.1.patch); it's an opt-in transport for
 //     users who run their own Chrome.
 //
 // (The old "managed" visible-window mode was removed — issue #420.)

patches/playwright-core@1.61.0.patch patches/playwright-core@1.61.1.patchpatches/playwright-core@1.61.0.patch renamed to patches/playwright-core@1.61.1.patch

@@ -11,7 +11,7 @@
 // purpose-built channel, not a Playwright session. The raw WebSocket uses Bun's
 // native WebSocket, which is why this path always worked under Bun even when
 // playwright's connectOverCDP did not (that hang — playwright-core's bundled
-// `ws` — is fixed separately by patches/playwright-core@1.61.0.patch). The
+// `ws` — is fixed separately by patches/playwright-core@1.61.1.patch). The
 // agent's automation keeps driving the SAME Chrome over its pipe transport;
 // this screencast is a SEPARATE read/drive channel on the same process, so the
 // two never conflict.

src/capabilities/browser-connect.ts

@@ -461,7 +461,7 @@ const spawnedSessionProvider: BrowserSessionProvider = {
 // Attach to the user's OWN external Chrome over a CDP websocket URL they
 // supplied via /api/browser/connect. We NEVER spawn or kill this process — the
 // user owns it. connectOverCDP works under Bun via the bundled-ws→built-in-ws
-// patch (patches/playwright-core@1.61.0.patch); without it the CDP websocket
+// patch (patches/playwright-core@1.61.1.patch); without it the CDP websocket
 // handshake deadlocks. This is an opt-in transport for users who point us at
 // their own Chrome.
 const cdpSessionProvider: BrowserSessionProvider = {

src/execution/browser-screencast.ts

@@ -8,7 +8,7 @@
 // natural transport for a browser we spawn ourselves, no TCP debug socket
 // needed for automation. (For attaching to a user's ALREADY-running Chrome the
 // cdp provider uses connectOverCDP over a TCP WebSocket, which works under Bun
-// via patches/playwright-core@1.61.0.patch.) We still inject a free
+// via patches/playwright-core@1.61.1.patch.) We still inject a free
 // `--remote-debugging-port` into the launch args so the spawned Chrome ALSO
 // exposes a debug endpoint — the sign-in screencast bridge attaches to it over
 // raw CDP — without routing the agent's automation through that endpoint.