browser-controllisted

# Browser Control - DevHome CDP Routing All browser automation on this machine goes through the **Opera Developer** instances managed by `devbrowser` (DevHome.Profile). The harness-bundled browser stacks are deliberately disabled and must not be re-enabled or worked around - they pop windows into the user's real session. **Banned:** the bundled `browser` and `chrome` plugins, `chrome:control-chrome`, browser-harness, playwright, and launching your own Chrome/Chromium instance by hand. **Allowed:** the CDP endpoints below, driven by chrome-devtools-mcp or direct CDP calls (helper script included). ## Endpoints | Port | Instance | Profile | |------|----------|---------| | 9000 | visible | isolated `opera-visible` state dir | | 9001 | headless | isolated `opera-headless` state dir | Loopback-only. Both use isolated profiles, so nothing here touches the user's real browsing session. More instances on other ports are fine when a task needs a clean profile - each `-Port` gets its own state dir. ## Launch / status: devbrowser `devbrowser` is a PowerShell function from the DevHome profile (available in any profile-loaded pwsh session; from bash run it via `pwsh -Command`). ```powershell devbrowser # status of port 9000 (default) devbrowser -Mode Headless -Port 9001 # launch/ensure headless instance devbrowser -Mode Visible # launch/ensure visible instance devbrowser -Mode Open -Port 9000 -Url 'https://example.com/'