Calling the browser device's open action with just url/viewport and no app block does not spawn an isolated headless Chromium. In this environment it silently attaches to the omp browser relay (http://127.0.0.1:9224), which drives the user's actual, already-running Chrome window — their real profile, real cookies, real logged-in sessions.
Symptoms that reveal this after the fact:
- Navigating to a route that redirects when authenticated (e.g.
/->/home) lands you on the authenticated route immediately, because the user's real session cookies are already present. viewport: {width, height}passed toopenis silently ignored — a real window can't be resized to an arbitrary CDP viewport the way a headless page can.tab.screenshot()renders at the actual window size (e.g. 1024x874 desktop) no matter what viewport you requested.- Anything that mutates browser state —
page.deleteCookie(...(await page.cookies())), clearing localStorage, togglingdocument.documentElement.classList— mutates the user's live session. Clearing cookies to test as 'anonymous' logs the user out of their real account.
Fix: to get an isolated, disposable browser for testing (mobile emulation, unauthenticated views, destructive DOM/cookie experiments), do NOT rely on open defaulting to a sandbox. Verify the environment's actual isolated-browser mechanism before mutating any state (check for app.path pointing at a fresh Chromium binary, or a --headless/dedicated profile flag). If the tool only exposes the relay, treat every open/run call as touching the user's real browser and never call cookie-clearing or state-mutating code against it. For responsive/viewport testing against a relay-attached real window, use page.setViewport({width, height, isMobile: true, deviceScaleFactor}) via CDP Emulation.setDeviceMetricsOverride (this DOES apply even though the window itself doesn't resize) — confirmed working: the page's own <html>/media queries respond correctly, verified across 320/360/375/390/414/640/1440px in one session.
Also: page.emulateMediaFeatures([{name:'prefers-color-scheme', value:'light'}]) plus writing the app's dark-mode toggle library's localStorage key (e.g. mode-watcher-mode) survives a tab.goto() reload, useful for reliably forcing light/dark screenshots regardless of the host OS's actual color-scheme preference.