Choose a Hermes Browser Automation Backend
Hermes exposes one browser toolset, but the browser behind it can be managed in the cloud, self-hosted for anti-detection work, attached to a browser you already use, or launched locally through agent-browser. The right choice depends less on the tool names than on where the page is reachable, whether an existing login matters, how much stealth you need, and whether you want to operate browser infrastructure.
First decide whether you need a browser
Use browser automation when the task must click, type, scroll, inspect dynamic content, capture screenshots, or read a page after JavaScript runs. For simple public information retrieval, the official docs recommend web_search or web_extract; they are faster and cheaper than opening an interactive browser session.
If interaction is required, choose the narrowest backend that fits the job.
Backend decision guide
Browserbase, Browser Use, or Firecrawl cloud
Choose a cloud backend when Hermes runs on a server without a usable desktop, when you want the provider to manage browser lifecycle, or when public sites need cloud-scale browser features.
- Browserbase is the strongest fit when managed anti-bot features are important. Hermes documents random fingerprints, CAPTCHA solving, residential proxies, advanced stealth on eligible plans, and session reconnection. Cloud sessions consume provider credits.
- Browser Use is an alternative managed browser reached through its REST API. If both Browserbase and Browser Use credentials are present, Browserbase takes priority.
- Firecrawl provides cloud browsers with built-in scraping. Select it explicitly through the Browser Automation setup flow; its browser session TTL is configurable.
- Nous Tool Gateway is another managed path for paid Nous Portal subscribers and does not require separate browser-provider keys.
Cloud mode is normally for public URLs. When a configured cloud browser encounters localhost, loopback, LAN, or other private-address targets, Hermes automatically uses a local Chromium sidecar by default. Public URLs remain on the cloud backend, and the cloud provider does not receive the private URL.
Camofox local mode
Choose Camofox when you want local anti-detection browsing and are prepared to run a self-hosted Node.js service around Camoufox, a Firefox-based browser with fingerprint spoofing. Point Hermes at the service with CAMOFOX_URL, or choose Camofox under Browser Automation in hermes tools.
Camofox is especially useful when cloud dependency is undesirable but ordinary local Chromium is too easy for a site to fingerprint. It has more operational overhead than the default local path. Login persistence is also not automatic: enable browser.camofox.managed_persistence, restart Hermes, and make sure the Camofox server actually honors stable userId profiles. Hermes can request persistence, but it cannot make an ephemeral server implementation retain a browser profile.
Your own Chrome, Brave, Chromium, or Edge via CDP
Choose a live Chromium-family browser over CDP when you need your own cookies, want to watch the work, want to intervene manually, or want a no-cloud-cost browsing path. In an interactive Hermes CLI session, use:
/browser connect
/browser status
/browser disconnect/browser connect can auto-launch a supported browser on the default local debugger endpoint or accept a specific WebSocket endpoint. It is an interactive-CLI slash command, not a gateway command. Sending it in Telegram, Discord, a WebUI, or another gateway chat only sends plain text to the agent.
Use a dedicated browser profile for remote debugging rather than your everyday browser profile. That keeps the automation surface and stored logins intentionally scoped.
Default local Chromium through agent-browser
Choose the default local path when the machine has Chromium available, cloud stealth is unnecessary, and you do not need an existing live-browser session. With no cloud credentials and no CDP connection, Hermes drives local Chromium through agent-browser.
Run hermes setup tools or hermes tools to install or select Browser Automation. Local mode is headless by default. Set browser.headed: true when you want a visible window that remains open between turns; idle sessions are still closed after browser.inactivity_timeout.
Configure and verify the selection
Use the interactive setup rather than hand-editing provider state whenever possible:
hermes tools
# or
hermes setup toolsStore credentials only in ~/.hermes/.env. The documented provider variables are BROWSERBASE_API_KEY plus BROWSERBASE_PROJECT_ID, BROWSER_USE_API_KEY, FIRECRAWL_API_KEY, and CAMOFOX_URL. The selected cloud provider is represented by browser.cloud_provider in config.yaml; behavior such as inactivity_timeout, headed, recording, dialog policy, and Camofox persistence lives under browser:.
After configuration, start a fresh session if the toolset was newly enabled. Ask Hermes to open a harmless public page, take a snapshot, and report the page title. For a private development URL, verify that the cloud configuration still reaches the local service through the automatic local sidecar. For CDP, check /browser status before asking the agent to interact with the page.
Pitfalls
- Setting several cloud credentials and assuming Hermes will guess your preferred provider can produce surprising precedence. Select the backend in
hermes tools; remember that Browserbase wins over Browser Use when both are configured. /browser connectaffects the interactive CLI session only. It is not a messaging-gateway control command.- Putting
managed_persistenceat the top level does nothing. The supported path isbrowser.camofox.managed_persistence. - Disabling
browser.auto_local_for_private_urlscan make private targets fail. Settingbrowser.allow_private_urls: trueinstead asks the cloud provider to attempt a private address, which usually cannot reach your LAN and weakens the safer default routing model. - Focused snapshots are text accessibility trees, not pixel automation. Use browser vision when layout or visual state matters.
- A logged-in CDP profile gives the agent access to that browser state. Use a deliberately scoped profile and do not treat a browser attachment as a security sandbox.
Verification checklist
- Verify the Browser Automation toolset is enabled through
hermes toolsand a new session can access browser tools. - Verify only the selected provider's credentials are present and the intended
browser.cloud_provideris shown in configuration. - Verify a public navigation returns a snapshot with interactive element references.
- Verify private or localhost navigation stays local when hybrid routing is expected.
- Verify
/browser statusreports the intended endpoint when using CDP. - Verify Camofox login state survives a new browser task only if managed persistence is required and supported by the server.
