Expose external or detachable browser support for Browser Use

What variant of Codex are you using?

App (Desktop)

What feature would you like to see?

Browser Use in Codex Desktop currently operates through the in-app browser panel. That makes the automated browser viewport depend on the side-panel layout rather than on a normal, user-controlled browser window.

I would like Codex Desktop to expose a first-class external or detachable Browser Use mode, so Browser Use can target a real, resizable browser viewport while preserving its DOM-aware automation, screenshots, inspection, and interaction APIs.

Possible acceptable designs:

• allow the in-app browser to detach/pop out into a standalone resizable window
• allow Browser Use to attach to an external Chrome window
• expose a supported CDP/Chrome backend setup from the Desktop app
• provide another first-class “recordable browser” mode with normal desktop dimensions

The important behavior is that Browser Use should be able to automate and inspect the same viewport a user would record, review, or validate in a real browser window.

Why this matters

The current in-app browser viewport can be much narrower than a normal desktop browser. That means Browser Use may inspect, screenshot, and interact with a page at tablet/mobile breakpoints even when the user needs to validate a desktop-width experience.

This affects several workflows:

• responsive testing at real breakpoints
• customer-facing screenshots
• accessibility audits where rendered state needs to match the real browser surface
• walkthroughs, training content, and product demo recordings
• debugging flows where the visible UI in standalone Chrome differs from the in-app browser panel

A concrete example: for demo recording, Computer Use can drive standalone Chrome and produce real visible clicks, typing, scrolling, and chat interactions. But that requires giving up Browser Use's more reliable DOM-aware automation. Browser Use has the better browser automation model; Computer Use has the better recordable surface. A first-class external/detachable Browser Use mode would avoid that tradeoff.

Current behavior

The bundled Browser Use skill currently initializes the runtime with:

js
const backend = "iab";
await setupAtlasRuntime({ globals: globalThis, backend });

That works for the in-app browser, but it keeps Browser Use tied to the Codex side panel.

I tested the available backend names through the Browser Use client entrypoint on macOS Codex Desktop 26.429.20946:

iab: connects successfully
chrome: fails with Failed to connect to browser-use backend "chrome". Make sure the Chrome extension native host is installed and running.
cdp: fails with Failed to connect to browser-use backend "cdp". Make sure cdp-browser-backend is running and connected to a Chrome CDP endpoint.
Those messages suggest there may already be intended external-browser backend paths, but they are not exposed as a supported user workflow in the Desktop app today.

Additional information

I searched existing public issues and did not find this exact request.

Related but not duplicate issues:

#18537: device emulation/responsive mode in the in-app browser
#19429: Browser Use screenshots capture the wrong region
#20236: in-app browser panel width shared across projects
#19276: in-app browser auth/sign-in flows
#19305: Computer Use support on Windows

I also noticed code-level signs that this direction may already be under consideration:

BrowserUseExternal exists as a feature flag.
The Browser Use client has backend handling for iab, chrome, and cdp.
The installed app includes browser-use-peer-authorization.node.