window new always creates a fresh BrowserContext, so there is no way to open a second window in the current profile #1624

Summary

window new is the only way to get a second OS-level window, and it always creates a fresh CDP BrowserContext to hold that window. The resulting window starts with an empty cookie jar, so it cannot be used for work that depends on the profile's existing logins. There is no way to ask for a window inside the context the session is already using.

Why a window rather than a tab

Two separate problems are both mitigated by giving an automation its own window instead of its own tab.

First, Chromium throttles background tabs. A tab that is not the active tab in its window reports document.visibilityState === "hidden", and the heavy SPAs we drive routinely never finish hydrating in that state, so snapshots come back against a half-rendered page. A tab that has its own window keeps reporting visible even when that window is fully occluded, as long as Chrome is running with --disable-backgrounding-occluded-windows.

Second, when more than one automation shares a browser, the active tab is contended (#1530). A separate window reduces how often two drivers end up pointed at the same target.

Both mitigations only help if the new window carries the profile's existing session state, because the pages being automated are sites the user is already signed into.

Current behaviour

handle_window_new in cli/src/native/actions.rs calls Target.createBrowserContext and then creates the target inside the returned browserContextId. That does produce a separate window, but it is a storage-isolated one, so none of the default context's logins are present. tab new stays in the current context but produces a tab, which brings back the throttling problem above.

The two properties cannot currently be combined. tab new keeps the session state, window new provides the window, and neither provides both.

Repro sketch

Against a headed Chrome with an existing login (any site where you are already signed in):

agent-browser --cdp 9222 --session s1 window new
agent-browser --cdp 9222 --session s1 open https://<site-you-are-logged-into>
agent-browser --cdp 9222 --session s1 snapshot

Expected by the caller: the page renders signed in, as it would in a normal new window of the same profile.
Actual: the page renders signed out, because the window lives in a new BrowserContext.

Expected

Some way to open a window that stays in the session's current browser context.

Possible directions

Any one of these would cover the case:

• A --window flag on tab new, passing newWindow: true to Target.createTarget without a browserContextId. CDP supports this directly and it keeps the target in the current context.
• A flag on window new selecting the context behaviour, in whichever polarity you prefer as the default (--same-context, or --isolated if the current isolation should remain default).
• Accepting a URL argument on window new, which it does not currently take, so the window can be opened straight onto the target page rather than about:blank.

This is worth considering alongside #1068, which requests BrowserContext isolation as an opt-in flag. window new already performs exactly that isolation, but unconditionally and as a side effect of windowing rather than as a selectable behaviour. Splitting the two concerns apart (windowing on one axis, storage isolation on the other) would serve both requests.

Environment

• Observed need on agent-browser 0.27.2, macOS, Chrome 150, attached over --cdp 9222 with a second automation on the same endpoint.
• One caveat on evidence: I have not executed window new myself, because it does not exist in 0.27.2 (we are pinned there by a Node 22 constraint). The description of its behaviour above is read from main at 0.33.1, so please correct me if the context isolation is not what it appears to be in that code path.