Hermes yesterday, November 2, 2026: v0.22.6 ships and local ports lose the dashboard token
What landed on Hermes Agent main on November 2, 2026: other local ports can no longer take the dashboard token, Nous logins survive a brief 401, the gateway stops freezing every minute, and v0.22.6 shipped with most of it.

Table of contents
- 1. Pages on other local ports can no longer take your dashboard’s token
- 2. A brief Nous 401 no longer ends your turn (already in v0.22.6)
- 3. The gateway stops freezing every minute (already in v0.22.6)
- 4. Background results stop getting lost (already in v0.22.6)
- 5. Closed conversations finally leave the gateway’s memory (already in v0.22.6)
- 6. A killed hermes update no longer blocks the next one (already in v0.22.6)
- 7. MCP servers stay in their own profile and come back on their own
- 8. Desktop terminal tabs remember which machine they run on (already in v0.22.6)
- 9. Grok Bot and OpenBot users can move to Hermes (already in v0.22.6)
- 10. 64 new plugins in the catalog
- Meanwhile, in the engine room
- Watch the recap
604 commits landed on main, 64 new plugins joined the catalog, and v0.22.6 shipped mid-day with 225 of those commits, among them fixes for Nous logins that died on a brief 401 and a gateway that froze every minute. Still only on main: the fix that stops a page on another local port from reading your dashboard’s session token. Here are the 10 that matter.
1. Pages on other local ports can no longer take your dashboard’s token
Before: on a loopback bind, the Webapp listener, hermes dashboard and the Desktop backend hermes serve trusted every local port, so a page served from any other port on the same machine (a dev server, a previewed site, Live Server) could read the session token the dashboard page carries, then open its chat and terminal sockets (/api/ws and /api/pty) with it. Plugin sockets, such as the Kanban events stream, had no Host or Origin check at all. After: a loopback origin is trusted only on the port the backend actually bound, when it equals the Host it dials (so ssh -L and docker port forwards keep working), when it is exactly the configured webapp.public_url or dashboard.public_url, or when it is the Desktop dev renderer named in HERMES_DESKTOP_DEV_SERVER. No fixed port is trusted any more, and every plugin socket goes through the same gate. The packaged Desktop app is unaffected. Heads-up: a reverse proxy on another local port that rewrites Host is now refused unless you set its address as public_url, and a backend you start yourself and reach from a Desktop dev build needs HERMES_DESKTOP_DEV_SERVER. Limits: any local process that can reach the port can still read the token, which is the loopback trust model; this stops other browser origins.
Pull request: Local origins for CORS and WebSockets.
2. A brief Nous 401 no longer ends your turn (already in v0.22.6)
Before: when the Nous Portal briefly answered authentication required for a key that was still valid, Hermes handed the same failing key back, retried three times in about 1.5 seconds and declared the login dead. In the November 1 incident that killed hour-long delegate_task subagents and Desktop sessions. Separately, a profile could swap its current Nous login for an older shared copy, so its next refresh reused a spent token and the Portal’s reuse detection forced a fresh sign-in. After: a 401 gets one real refresh, then Hermes waits 5, 15 and 30 seconds on the fresh key before giving up (about 55 seconds at most), and /stop during the wait sends nothing more. Dead logins and missing-subscription 403s still fail at once. A profile now adopts the shared login only when it was issued later for the same account, and pushes its own newer login to the shared copy instead.
Pull requests: Transient 401 backoff, Newer login wins.
3. The gateway stops freezing every minute (already in v0.22.6)
Before: every routine memory clean-up in the gateway first forced a full sweep of every object in the process, and that sweep stopped every other thread, chats, streams and the Desktop app included. On a live gateway the once-a-minute housekeeping trim took 272 ms at the median and up to 3.3 seconds, and closing an agent cost about as much under delegation. After: those trims only hand already-free memory back to the system, which takes under a millisecond. The one full sweep left runs once the gateway has had no conversation for 5 minutes, and a finished turn no longer leaves a loop of objects behind that kept the whole closed agent alive until a sweep. In the PR’s test, the worst freeze another thread saw fell from 383 ms to 46 ms under load. Forced sweeps stay where memory is an emergency (agent cache pressure, cron’s file descriptor reclaim).
Pull request: Gateway memory trims.
4. Background results stop getting lost (already in v0.22.6)
Before: several paths left a finished subagent’s answer at pending forever. A /bg task whose agent delegated in the background posted its reply and ended, so the child’s answer had nowhere to go. A TUI, Desktop or dashboard chat closed while its job ran had the result thrown away by whichever other open chat looked first. A chat reached through another profile’s bot, or a Telegram forum topic whose saved route lost its origin, never got the result (the latter crashed the delivery watcher every 2 seconds). And a notice that never reached a delivery loop waited for a gateway restart. After: /bg waits for its subagents and puts their answer in its one reply, a closed chat’s results wait for that chat to be resumed (up to 10 minutes, a few per chat), routed and origin-less chats get theirs, also after a restart, and the ledger re-offers a lost notice, still delivered at most once. Heads-up: inside /bg, background terminal commands now drop completion notifications and the agent is told to poll instead, which /bg never delivered anyway.
Pull requests: /bg joins its subagents, Closed chats park results, Live owner re-offer, Routed bots, Routes without origin.
5. Closed conversations finally leave the gateway’s memory (already in v0.22.6)
Before: a long-running gateway kept things nobody could use again: the last turn of every Desktop, TUI, CLI and API conversation (its agent and history) until a restart, a live record for every closed local or idle API conversation, each ended session’s replay buffer, the parent agent of up to 50 finished background helpers, and a per-message token memo with no size limit. Glibc also gave almost every thread its own memory pool and never handed it back: a 10-hour production gateway had 157 of 160 possible pools mapped. After: each of those is freed when its conversation closes or goes idle, the token memo aims to stay under 64 MiB while never dropping anything a running conversation used in the last minute, and the gateway and hermes serve cap malloc pools at 4 (runtime.malloc_arena_max; your own MALLOC_ARENA_MAX wins). Bonus: /goal verdicts such as Goal achieved now show up in Desktop, the TUI and hermes chat, where they never appeared. Honest numbers from the PRs: memory in short test runs moved only a few MB; the win grows with uptime.
Pull requests: Post-delivery and /goal, Closed and idle sessions, Replay rings, Finished helpers, Token memo, Malloc arenas, Long-lived caches.
6. A killed hermes update no longer blocks the next one (already in v0.22.6)
Before: if hermes update was killed while its git fetch held a lock, git left refs/remotes/origin/main.lock or .git/shallow.lock behind, and later updates failed with reference already exists or were refused for ten minutes. It broke the Windows update tests and held up v0.22.6. Separately, a one-time cron reminder that came due while an update waited for an in-flight Kanban turn was thrown away as missed once the wait outlasted its 2-minute grace. After: the next update deletes a leftover lock only after proving the killed update and its git are gone, never while git or Hermes still holds it, and a one-shot that came due during the restart wait fires once afterwards. Recurring jobs and catch-up are unchanged.
Pull requests: Ref locks, shallow.lock, Cron one-shot during the wait.
7. MCP servers stay in their own profile and come back on their own
Before: when one Hermes process served several profiles (a multiplexed gateway, or Desktop and the dashboard with --open-profile), the local stdio MCP servers it started for a profile got no HERMES_HOME, so they wrote state and caches into the default profile, and a second profile with the same server command reused the first profile’s process. And an MCP server that dropped and reconnected without re-registering stayed missing from tool_search, tool_describe, new sessions and /new until /reload-mcp or a restart. After: each stdio server runs in the home of the profile that started it (a HERMES_HOME in the server’s own env still wins), so two profiles with the same command now start two processes, and a recovered server reaches Tool Search, new sessions and /new within the 30-second availability check. Limits: a live session’s tool list stays frozen by design, so a session without Tool Search still needs /reload-mcp or /new, and a fix for cron jobs that snapshot their tools before a server recovers is still in review.
Pull requests: Per-profile HERMES_HOME, Recovered servers, In review, cron waits for MCP recovery.
8. Desktop terminal tabs remember which machine they run on (already in v0.22.6)
Before: an in-app terminal tab followed whatever gateway the window showed, and quitting the app killed every shell before the layout was saved, so a relaunch could bring back only some tabs (2 tabs came back as 1 in the PR). After: each tab owns the gateway it was opened on and its shell runs there, the tab shows where it runs, and New terminal on… under the + button opens a shell on This device or on any SSH gateway, side by side. Quitting keeps every tab. A tab whose gateway was removed says so instead of falling back to a local shell, and a torn-down SSH connection leaves the tab disconnected with press Enter to retry. URL, token and cloud gateways have no shell, so their tabs run on This device. Not live-tested on Windows remotes or macOS.
Pull request: Terminal tabs per gateway.
9. Grok Bot and OpenBot users can move to Hermes (already in v0.22.6)
Before: setup and hermes migrate knew only OpenClaw, Claude Code, Codex and Cursor, and a bare hermes migrate printed a usage error. After: first-run hermes setup also offers a Grok Bot import (found from its desktop app folders or a downloaded grok-bot-export file, since its data lives in the cloud) and an OpenBot import (from its data folder), and hermes migrate, bare or as hermes migrate <agent>, installs or updates the agent-importers plugin when needed and runs it. Scheduled routines arrive as paused cron jobs (--activate-routines starts them), along with skills, memories and the bot’s instructions as SOUL.md. hermes migrate <agent> exits non-zero when the import fails, and hermes migrate openclaw brings API keys and bot tokens over only with --migrate-secrets.
Pull request: hermes migrate Grok Bot and OpenBot.
10. 64 new plugins in the catalog
64 new community entries, and memory is the theme of the day: five new memory and recall layers, plus repository maps and a local search over documents and media. Heads-up: many of them send prompts, files or keys to their own hosted services, and some move money (x402 payments, a credit line, selling an inference allowance), so read each entry’s disclosure before installing. Catalog entries do not wait for a release: they go live once the published catalog refreshes, which can take up to six hours.
- Memory and context: agentmemory, nyx, statejar, ram-first-context, neuralmind, cartograph, mediarag, chmod-ref
- Models and usage: fortytwo-provider, hashference-provider, model-presets, model-usage, limits-monitor, cadence, handydandy, tokenjuice, nexus-recovery-peer
- Desktop and dashboard: hermes-plexus, hermes-tabs, hermes-ios, olympus, search-sources, revamp, nous-girl-theme, squad-hub, word-peek
- Guard rails: scar, withhuman, ethics-filter, writing-guard
- Coding workflows: disciplined-vibe-coding, lithermes, shipframe, mariadb-dev, mariadb-guard, muse-harness, upstash-box
- Web and data: pulldown, switch402, webmint, proxy, decisions, tallybuy
- Payments and crypto: priors, toll, stablelens, surplus-intelligence-seller
- Messaging and channels: artil, iris-chat-channel, mqtt, postroom, lfg-alarm
- Voice, music and media: breeze-tts, idealphase-elevenlabs-audio-tags, hermes-band, gameforge, aircraft-doppler-geolocation
- Everyday life and work: courier-by-autolane, filmease, recued, iwork-studio, hermes-windows-devices, soul-finder, kanban-empowered
Meanwhile, in the engine room
Dozens of fixes landed yesterday that most users never see, and the Desktop app took most of them.
- A package install cut off by a machine stop could leave a corrupt copy in the package manager’s
uvcache that made every later plugin install fail, andhermes pm doctornever looked there; the install now removes the broken copy and retries, andhermes pm doctor --repairclears it ahead of time (pull request) - Desktop draws mermaid diagrams with Pele instead of mermaid.js, a 2.97 MB chunk that took 1.3 seconds to draw 15 diagrams and redrew all of them on every light or dark switch; in the PR’s harness the first diagram shows up in under half the time (pull request)
- A named profile on a shared
hermes servethat lacked its provider key sent the request with no key and got a misleading 401; it now stops before sending and says which variable to add to which profile’s.env(pull request) - Old phone-app chats saved under the app’s own label opened read-only in Desktop; they now continue like any Desktop chat, while WebUI, messaging and automation rows stay read-only (pull request)
If you noticed none of this, it worked.
Items 2 to 6, 8 and 9 already shipped yesterday in v0.22.6, along with three of the four engine room fixes; item 1, item 7 and the Desktop diagram switch are on main and ship in the next release (Desktop app changes reach the Microsoft Store app with a release and the .exe and .dmg app with its next bundled release). Latest stable: v0.22.6.
Watch the recap
The 56-second motion recap, made with Remotion, is on X.
Was this configuration guide helpful?
If you have questions, encountered issues during setup, or want to discuss networking and security, connect or reach out on LinkedIn.
Connect on LinkedIn