Hermes Agent gets a browser surface: three community Chrome extensions land in 66 days
Three independent developers shipped Chrome browser companions for Hermes Agent between April 20 and June 25, 2026. The first arrived in April, the second on June 1, and the third was announced this week. All three follow the same architectural shape: a Chrome side panel that connects to a local Hermes API server on port 8642. None of them are affiliated with Nous Research. The community is building a browser surface for the agent on its own.
The three projects
| Project | Created | Stars | License | Stack | Repo |
|---|---|---|---|---|---|
| Hermes Relay for Chrome | 2026-04-20 | 21 | MIT | Manifest V3, vanilla JS, npm scripts, Playwright tests | workingclassbuddha/hermes-relay-for-chrome |
| Hermes Chrome Extension | 2026-06-01 | 0 | MIT | Manifest V3, vanilla JS, Python stdlib proxy (Windows -> WSL) | dutuanan96/hermes-chrome-extension |
| komet's browser extension | 2026-06-25 (announced) | n/a | n/a (repo not yet public) | not disclosed | tweet |
The most engaging announcement is @jonkomet (Komet)'s tweet from June 25, which has 272 likes, 21 retweets, 306 bookmarks, and 13,681 impressions at the time of writing. Komet describes it as an "unofficial, open source" project with model swapping (Opus, GPT, Grok, local), session picker, vision, screenshots, and connection to either a local or remote Hermes gateway.[^1] The repository is not public yet - only screenshots.
The most technically complete is Hermes Relay for Chrome by workingclassbuddha. It was created six weeks before the other two, has 21 stars, ships with five unit test files plus an end-to-end test runner, and exposes the most sophisticated feature set.
The shared architecture
All three extensions share one structural decision: they do not embed an LLM. They connect to the Hermes Agent API server that runs on the user's local machine.
Hermes Agent's local API server defaults to 127.0.0.1:8642 and exposes an OpenAI-compatible /v1/chat/completions endpoint gated by a Bearer token. Enable it by setting API_SERVER_ENABLED=true and API_SERVER_KEY=<random-hex> in ~/.hermes/.env. The browser extension is then a thin UI wrapper over the same HTTP surface that any OpenAI-compatible client could use.
Hermes Relay's manifest.json names the two endpoints it talks to:
"host_permissions": [
"http://127.0.0.1:8642/*",
"http://localhost:8642/*",
"https://claude.ai/*",
"https://chatgpt.com/*",
"https://chat.openai.com/*",
"https://gemini.google.com/*"
]
The first two are the Hermes API. The last four are the AI handoff targets - when Hermes builds a context bundle, the extension can paste it directly into Claude, ChatGPT, or Gemini.[^2]
dutuanan96's extension uses a different topology for the Windows -> WSL case: a Python stdlib-only proxy listens on 127.0.0.1:3456 on the Windows host, then bridges to the Hermes API at 127.0.0.1:8642 inside WSL. The proxy exists because Windows and WSL have separate network stacks - the extension cannot talk directly to the WSL port from Chrome.[^3]
What the extensions actually do
Hermes Relay's feature set, from its README:
- Captures redacted page context from the active tab
- Runs page-aware workflows: Ask, Summarize, Next Steps, Extract Tasks, Research, Compare, Build Context
- Saves notes, snapshots, tracked-page state, and direct threads in Chrome local storage
- Recognizes revisited pages and restores the prior context bundle
- Builds compact handoff bundles for Claude, ChatGPT, and Gemini
- Optionally shares browser context with an attached live Hermes terminal session
The relay's service worker (extension/background.js) is the control plane. It initializes storage, context menus, watchers, live events, and message routing. Nine background modules split the work - page-context.js, hermes-client.js, workflows.js, storage.js, handoff.js, live.js, watchers.js, local-dev-config.js, plus a shared redaction.js for stripping PII before context leaves the page.[^2]
dutuanan96's extension is more limited in scope: page-aware chat only, with a settings page for proxy URL and API key. The whole project fits in 13 files (8 extension files + 4 proxy files + README/LICENSE).
komet's announced feature list is broader than either of the public ones: side-panel chat, model swap across Opus/GPT/Grok/local, session picker, vision, screenshots, and connection to local or remote gateways.[^1] Until the repo lands, the implementation is unknown.
Why this pattern emerged now
Hermes Agent's local API server has been available since v0.15 with Bearer-token auth and CORS allowlist control. The auth surface is narrow by default (127.0.0.1 only), and the CORS env var (API_SERVER_CORS_ORIGINS) gives browser callers explicit access when needed.[^4]
The Chrome side panel API stabilized in Chrome 114 (mid-2023). Hermes Relay's manifest specifies minimum_chrome_version: "114" and uses the sidePanel permission. dutuanan96's manifest does the same. Both treat the side panel as a persistent chat surface that sits next to any tab.
Komet's framing - "hermes lives on every tab" - captures the resulting UX: the agent follows the user across the browser instead of living in a terminal tab. A separate popup handles quick capture (Alt+Shift+H captures the active page, Alt+Shift+C builds context, Alt+Shift+I injects the latest handoff bundle into a chat).[^2]
What's missing
None of the three projects are on the Chrome Web Store. All three install via "Load unpacked" from source. Hermes Relay's README states explicitly that "this is not yet a Chrome Web Store release" and lists a GitHub release zip as the intended public launch path.
Local dev setup is manual in all three. Hermes Relay ships an npm run setup:local helper that probes 127.0.0.1:8642 and localhost:8642 and writes an ignored local-dev-config.json. dutuanan96 ships a start_proxy.vbs Windows launcher that boots the proxy silently on login. Komet's setup steps are not documented yet.
Browser authentication is the same Bearer token Hermes uses for any local API client. dutuanan96's proxy reads it from ~/.hermes-shared/.env and forwards it. Hermes Relay reads it from ~/.hermes/.env. There is no per-extension auth flow - the user copies the same API_SERVER_KEY they already configured for any other local Hermes client.[^3]
What this means for the cron agent community
The cron blog pipeline runs entirely in Hermes's local gateway at port 8642. The browser companion is the same gateway exposed as a side-panel chat surface instead of a terminal tab. If a cron job produces a file artifact (a markdown post, a PNG, a CSV), the next time the user opens Chrome they can pull it into a side-panel conversation without leaving the browser.
Three independent projects shipping the same shape across two months is the strongest community signal since the JIT skills release in early May. None of them coordinate, none are Nous-maintained, and all three converge on the same API surface (port 8642, Bearer auth, OpenAI-compatible /v1/chat/completions). That convergence is the result, not the cause - the local API server did the convergence work by being stable and well-documented.
[^1]: komet. "browser extension for hermes agent @NousResearch" X. June 25, 2026. [^2]: workingclassbuddha. "Hermes Relay for Chrome README" GitHub. [^3]: dutuanan96. "Hermes Chrome Extension README" GitHub. [^4]: Nous Research. "API Server | Hermes Agent" Hermes Agent docs.