Hermes agent browser on a server: can it use your Chrome logins?

Hermes' real-profile browsing copies the Chrome profile on the machine Hermes runs on, so a Hermes on a VPS has no logins of yours to borrow and runs headless besides. What the feature does, why it is same-machine by design, and the options for a hosted Hermes.

The short answer

Not if the server is where Hermes runs. Real-profile browsing, the feature Nous shipped on August 27, 2026 (“your agent acts with your logins, from a managed copy of your existing Chrome profile”), copies the Chrome profile on the machine Hermes is running on into a snapshot the agent’s browser uses. The docs are explicit that it is “entirely local” and that “no profile data syncs to remote servers.” A Hermes on a VPS has no Chrome profile of yours to copy, and on a host with no display its browser “always runs headless” besides, unless you give it one with Bot Screen. On a server, the agent’s logins are the ones it makes itself, in its own browser.

What the feature actually does

Turn it on with one key in ~/.hermes/config.yaml:

browser:
  use_real_profile: true

Copied

Hermes then copies “your default browser’s active profile, the one you actually browse,” found through Chrome’s Local State → profile.last_used, “with its cookies, saved logins, and preferences, into a managed snapshot” under ~/.hermes/browser-profile/<browser>/. The snapshot is a separate directory, so “your live browser profile is never opened directly” and the agent does not fight your running Chrome for the profile lock. The agent’s browser launches with that snapshot, signed in wherever you were. The feature is off by default, and the docs frame it carefully: “a consent-gated convenience, not an isolation boundary. A page the agent visits runs with your real logins, so only enable it when you want the agent acting as you.”

Why it is same-machine by design

Three reasons, all in the docs. The source is a directory on the local disk, so there has to be a Chrome profile on the machine to copy. The cookies in that profile are encrypted by the operating system, so decrypting them needs “your actual browser binary installed locally,” a point the docs stress for macOS, where “Chrome cookies are encrypted through the Keychain.” And nothing ships the snapshot anywhere: “the browser binary launches on the host machine using the snapshot directory, and no profile data syncs to remote servers.” That last one is the safety property. A feature that copied your logins to a remote host would be a different and far riskier feature. Real-profile browsing is a convenience for the case where Hermes and your Chrome share a computer: a laptop, a desktop, a Mac mini.

What a hosted Hermes gets instead

On a server, Hermes launches what the docs call “a clean, throwaway profile” with the packaged Chromium, in which “the agent is logged into nothing,” or routes to a cloud browser provider such as Browserbase if you configure one. The docs also state that on headless hosts (servers, CI, Docker) the browser “always runs headless regardless” of the headed setting. Two consequences for a Hermes on a VPS:

Logins are the agent’s own. Sign the agent in, in its own browser, to the accounts you want it to use. That is a deliberate act rather than an inherited one, which for a server is the right default: the agent has exactly the sessions you gave it, in a profile that persists as long as its home directory does. Prefer dedicated accounts or scoped tokens over your personal logins for the same reason the docs give.
The browser announces itself as headless. A headless Chromium carries HeadlessChrome in its user-agent, and on a cloud server, as of September 2026, that string alone closes a dozen mainstream sites that open for the same browser with a display. The site-by-site list is the same for any harness’s Chromium. Since late September 2026, Hermes’s Bot Screen gives each bot on a headless Linux server a desktop of its own, where its browser opens with a display and you can take over to sign in (off by default; it needs TigerVNC and Xfce on the server, as Hermes Desktop explains). Whether that browser gets past the sites that turned the headless one away is not something the docs address, so treat it as a thing to test rather than assume.

The hybrid, if you want both

Nothing stops you running Hermes in two places. A Hermes on your laptop or Mac mini with real-profile browsing handles the tasks that genuinely need to be you: the account with no API and a login you will not hand out. A Hermes on an always-on server does the rest: schedules, monitoring, research, and anything on the open web. With Bot Mode each instance is a named bot with its own memory and skills, so the split reads as a roster rather than a workaround. The cost is that the same-machine rule cuts the other way too: the laptop bot is awake only when the laptop is.

What this is not

It is not a limitation Hermes could patch away, and it is not specific to Hermes. A browser profile lives on the machine that holds it, so an agent on a server reaches your logins only by driving a browser on your computer or by being signed in on its own: OpenClaw’s browser offers both (a Chrome extension or node on your computer, or its dashboard’s live view of the agent’s browser), and Grok Bot’s per-account computer hands you the screen to type credentials into the agent’s own browser, which is the server-side answer in a different coat. The docs’ own framing is the right one: real-profile browsing is a convenience for a shared computer. On a computer of the agent’s own, its logins are its own, and that is the point of giving it one. What Hermes is covers the rest of the agent.