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 headless host its browser “always runs headless” besides. 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

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 in our measurements on a cloud server that string alone closed a dozen mainstream sites that opened for the same browser with a display. The site-by-site list is the same for any harness’s Chromium. Whether giving the server a virtual display makes Hermes run headed 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. Any agent’s browser can only use the profiles on the machine it runs on; OpenClaw’s browser tool has the same property, and Grok Bot’s per-account computer solves the login problem by handing 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.