FAQ
Questions teams ask first.
Common answers for teams wiring Remote Browser into agent workflows, browser-use compatible automations, and direct CDP scripts.
Is Remote Browser compatible with browser-use?
Yes. Remote Browser exposes a real Chromium session over CDP, so browser-use style agents can connect to the session URL instead of launching a local browser. The workflow creates a remote browser, receives a WebSocket endpoint, and lets the agent drive navigation, extraction, clicks, forms, and screenshots through the same browser-control layer it already uses.
Do sessions stay logged in?
Yes. Use a browser profile when you want cookies, tabs, local storage, and other browser state to persist across runs. Profiles are useful for owned-account workflows, repeated QA checks, and long-running agent tasks where logging in every time would make automation brittle.
Can I use Playwright directly?
Yes. Create a Remote Browser session, read the CDP WebSocket URL, and pass it to playwright.chromium.connectOverCDP. The same pattern also works for other CDP-capable tooling, including Puppeteer and Selenium-based setups that connect to an existing remote browser.
How do proxies and stealth work?
Proxy egress and stealth fingerprinting are configured when the session starts. The browser runs remotely with a consistent browser, network, and fingerprint surface, which helps automation teams reduce environment drift compared with local headless browsers.
When should an AI agent use a remote browser?
An AI agent should use a remote browser when the task requires a real Chromium runtime, persistent login state, live debugging, recordings, regional egress, or compatibility with complex JavaScript sites. Remote browsers are especially useful when local headless automation fails because of environment differences, missing browser state, or hard-to-reproduce failures.