Search for the Hermes browser extension and you will find two different layers mixed together: Hermes Agent, the runtime that chooses browser tools, and a community Chrome/Edge/Chromium extension that puts a side panel beside your active tab. They can work together, but installing an extension is not the same thing as giving Hermes a browser session.
The practical answer is a choice of connection model. Use the extension when you want page context and an explicit tab-level UI. Use Hermes's local CDP or CLI route when you want the runtime to drive a browser backend directly. Use a gateway only when you are prepared to run and secure one. Use ego (lite) when the requirement is an independent local browser Space that inherits your signed-in state without putting the agent in your daily window.
What exactly connects Hermes to a browser?
Hermes is the agent runtime; a browser connection is one of its tool backends. The official Hermes browser documentation lists Browser Use Cloud, Browserbase, Firecrawl, Camofox, Lightpanda, local Chromium-family CDP, and a local agent-browser CLI. The backend determines where the page runs, which profile owns cookies, and whether the agent receives a page snapshot or a live tab.
That makes three questions more useful than “does the extension work?”
| Question | Why it matters |
|---|---|
| Whose browser? | A cloud profile, a local CDP process, your active tab, or a separate local Space have different cookies, IPs, extensions, and recovery paths. |
| Whose process? | The side panel, Hermes gateway, CLI daemon, or ego-browser process may each be running locally or on another machine. |
| Whose tab? | A tab-following extension can interrupt the page you are using; an isolated Space can run beside it and hand control back only when needed. |
How does the Hermes browser extension work?
The project most people mean by “Hermes browser extension” is abundantbeing/hermes-browser-extension, a community Chrome/Edge/Chromium MV3 side panel. Its README labels it public alpha v0.3.0 and says it is not yet on the Chrome Web Store. It can connect to a Local gateway, a signed-in Hermes Cloud agent tab, or a self-hosted Remote gateway. Treat that provenance and release status as part of the setup decision.
For a local connection, the documented path is: clone the repository, run npm install and npm run build, load the generated dist folder as an unpacked extension, run Hermes's gateway, and enter a scoped browser token. The extension README uses http://127.0.0.1:8642 as its default API server and recommends a narrow chrome-extension:// CORS allowlist. This is a local service architecture, not a zero-process install.
The extension's browser context is deliberately bounded. It can send active-tab text, selected text, headings, forms, links, and metadata when the chosen context mode allows it, and it wraps page content as untrusted context. The v0.3.0 README describes opt-in live control with leased tabs and explicit approval gates, but it also says the extension does not request cookies, history, bookmarks, native messaging, or password-manager permissions. Read the current README before granting access because alpha behavior can change.
What do the gateway and CDP routes require?
Hermes's gateway route is useful when the agent is reached from Telegram, Discord, Slack, WhatsApp, Signal, or another client. The gateway runs the runtime and can expose browser tools through the selected backend. It is also another long-lived process to monitor, another token to protect, and another network boundary if you bind it beyond localhost.
The official docs describe local Chromium-family CDP as a way to connect Chrome, Brave, Chromium, or Edge. CDP attaches to the browser process you configure; it does not magically merge a cloud profile with your personal profile. In practice, you must decide which profile launches with debugging enabled, keep the endpoint private, and expect the agent and human to share whatever tabs that process owns.
Cloud backends change the ownership model again. Hermes documents Browser Use and Browserbase credentials, persistent cloud profiles, and other provider settings. Those can be right for isolated server jobs, but a persistent cloud profile is still a profile held by that provider. It is not the same as an existing local browser session, and it adds provider account, billing, data-retention, and login-recovery questions.
When is Hermes CLI the better browser route?
Hermes's Browser Use mode uses the Browser Use CLI 3.0 as a driver. The official docs say the agent writes and executes Python for navigation, clicking, typing, dragging, and extraction, and that named sessions can isolate concurrent work. This is attractive when you want a scriptable workflow, reproducible session names, or a cloud backend without building a browser extension UI.
The CLI still inherits the selected browser source. A local Chrome connection can carry the profile you deliberately attach; a cloud provider carries the profile configured there; a new local or cloud session starts with its own state. The command surface is not the credential boundary. Ask where cookies, localStorage, downloads, and screenshots live before you call a route “logged in.”
For any route, use an explicit session name and a bounded task. Ask the agent to return the final URL, checked-at time, access status, and only the fields you requested. A login prompt, 2FA, CAPTCHA, rate-limit page, or unexpected profile is a stop condition—not an invitation to rotate proxies or copy cookies into a prompt.
Which connection route should you choose?
Choose by ownership and interruption cost, not by the word “extension.” The table is a decision aid: verify current provider behavior and platform terms before connecting a valuable account.
| Route | Setup | Login state | Tab ownership |
|---|---|---|---|
| Community extension + local gateway | Build/load extension; run gateway; token and CORS | Active-tab context; depends on the connected runtime | Followed or leased tabs; shared unless scoped |
| Local CDP | Launch/secure a compatible browser endpoint | The configured local profile only | Same process and tabs as the attached browser |
| Hermes CLI / Browser Use | Install CLI and select a backend/session | New or configured local/cloud session | Backend-dependent; named sessions isolate work |
| ego (lite) | Install once; import authorized browser context | Inherited in local isolated Spaces | Agent Space is separate from daily window |
Where does ego (lite) fit?
ego (lite) is not Hermes Agent and does not provide Hermes's messaging, model, or memory runtime. It is the browser layer for the case where an existing agent should drive a local Chromium browser with an authorized profile. Import Chrome once, open an isolated Space, and let a shell-capable agent use the ego-browser skill. The agent gets the browser work; your normal window remains yours.
That is the cleanest answer when a Hermes workflow needs your existing login but the task should not fight your current tabs. It is not a bypass: the account still sees the actions, platform terms still apply, and a challenge still requires a human handoff. For public, logged-out pages or server-only jobs, Hermes's own managed backends may be simpler.
A minimal handoff looks like this:
ego-browser nodejs <<'EOF'
const task = await egoBrowser.newTaskSpace('hermes-read-only')
await task.page.goto('https://example.com/', { waitUntil: 'domcontentloaded' })
console.log({
source_url: task.page.url(),
checked_at: new Date().toISOString(),
access_status: 'visible',
fields: ['title'],
})
EOFReplace example.com and title with a page and field you are authorized to read. Keep the output small, redact account identifiers, and never include cookies or bearer tokens. The point of the example is the boundary: Hermes can remain the agent while ego (lite) owns the local browser Space.
FAQ
Is the Hermes browser extension official?
The commonly linked Hermes Browser Extension repository is a community project by abundantbeing. Its README labels it a public alpha and says it is not yet on the Chrome Web Store. Hermes Agent itself is the Nous Research runtime. Check the repository and release notes you are installing rather than treating the extension as an official browser product.
Does the extension automatically use my Chrome logins?
No. It can provide page or tab context and, in its documented opt-in control mode, operate a leased tab after approval. Whether Hermes can use a logged-in view depends on the exact tab, connection mode, backend, and permissions. A cloud backend does not inherit your local cookies merely because the side panel is open.
Do I need a local gateway?
For the extension's Local gateway mode, yes: the documented setup runs Hermes's API server locally, typically at 127.0.0.1:8642, and uses a scoped token. Hermes can also connect through a remote gateway or Cloud mode, each with different network and data boundaries.
Can Hermes control a tab without an extension?
Yes, depending on the backend. Hermes documents local Chromium-family CDP and a Browser Use CLI mode, as well as cloud providers. Those routes still need their own browser, endpoint, profile, or credentials. If you need an independent local Space with inherited sessions, use a browser layer designed for that boundary, such as ego (lite), and keep Hermes as the agent runtime if you want.
How do I keep a browser agent from changing my tabs?
Use a separate profile, named session, or isolated Space and define a handoff for 2FA and consequential actions. A tab-following extension and local CDP process can share the browser you are using, so supervise them and scope the exact tabs. ego (lite) keeps agent work in its own Space while preserving the imported login state.
