Two capital letters do more work here than they should. Chrome emits cookie objects whose `sameSite` field is lowercase, and Lightpanda's CDP handler answers a lowercase `lax` with `-31998 InvalidEnumTag`, so the relay rewrites it to `Lax` on the way through [9]. Know that before you plan on swapping the runtime. Speaking CDP is not a compatibility guarantee at the level of field values, and the relay's normalization table, which also covers the `__Host-` and `__Secure-` prefixes per RFC 6265bis, is where that gap gets paid for [10].
The mechanism I would copy is the destination blocklist. A replicated session cookie is still a bearer token, and the target application is not the worst place it can be sent: the identity provider behind it is usually where a session can be traded for fresh credentials across the rest of the federation. The relay refuses identity-provider hosts and private IPs and holds a DNS cache as part of that check, which is the standard way to stop a hostname resolving to one address when it is validated and another when it is used [8].
Modern targets sit behind Google OAuth, SSO federations, hardware passkeys and biometric 2FA [3], and the alternatives the write-up lists are a password in a `.env` that leaks into LLM context logs and traces, a hand-pasted cookie with no scoping, or raw CDP against your primary browser with other tabs in reach [4]. Against that, the author's case for cookies rests on three properties: they expire, they are scoped to one origin, and logging out of your main browser revokes them [13]. The first two belong to the cookie. The third belongs to the target application's session store, and the bridge cannot supply it; an app that treats logout as a client-side event leaves the copy inside the headless runtime working until expiry. The post does not test that on any named dashboard. In the same way, "the relay never logs a cookie value" [14] is a claim about `relay/server.py` as written, checkable by reading it and by nothing in the architecture.
Adoption cost is small and specific. The extension asks for `activeTab`, `cookies` and `storage` [5], three permissions [17], which is about the narrowest set that can read a session cookie the page's own script cannot. Pairing is automatic: the extension calls `/v1/bootstrap` on first launch and stores a shared token in isolated extension storage [7]. That removes a copy-paste step, and it is the part I would want documented further, because the write-up does not say what happens if something else on the machine calls `/v1/bootstrap` first. Loopback binding is a boundary against the network, not against local processes [6].
Between browser and runtime the cookie crosses two ports and two transports, an HTTP POST to 8765 and a CDP WebSocket to 9222 [16]. The engine at the far end, Lightpanda, is open source and written in Zig with V8 [12], running under WSL2 in the described deployment, with the agent reading through a small Python client [11][15].
This transfers if the dashboards you target scope sessions per origin and a human is around when a session needs refreshing. It also assumes DOM and JS evaluation over CDP is all your agent needs from the browser. Agents expected to run overnight against short-lived federated sessions get nothing from this design; the win is bounded by the window in which someone can click Sync.
