Are Your Commands Running on the Wrong Server? Hermes Fixes Cross-Profile SSH Environment Leakage

If your Hermes runs two profiles at once — one for your company server, one for your home NAS — read this first: #92156, merged to main on August 22, fixes a leak that could make you run commands on the wrong host. It sounds deeply technical, but the consequence is direct: after switching profiles, your terminal commands could silently keep using the previous profile’s cached SSH environment — meaning a command you think ran on server A actually executed on server B.
How the Leak Happened
Hermes’s terminal tool caches each session’s remote environment (like SSHEnvironment) so it doesn’t re-establish connections on every command. That cache lives in a dict called _active_environments, indexed by a key produced by _resolve_container_task_id().
The problem was that key: every WebUI / gateway session collapsed onto the shared "default" key. So in the same process, Profile A (ssh_host=10.0.0.1) and Profile B (ssh_host=10.0.0.2) shared one cache slot — after switching profiles, B’s terminal could pick up A’s cached SSH environment, and commands would silently run on 10.0.0.1 instead of the 10.0.0.2 you meant.
Over SSH this is especially dangerous: rm, git push, config edits — running on the wrong host means destructive actions on the wrong target, with zero warning, because the output looks completely normal.
The Fix: Cache Scoped Per Session
The fix in #92156 is straightforward: the cache key changed from "default" to session:<key>.
- The WebUI streaming layer sets a dedicated session key per session;
- The gateway injects a per-message session key via
contextvars; - After a profile (session) switch, the new session gets a different cache key and can no longer reuse the previous profile’s
SSHEnvironment— so commands can’t be sent to the wrong host.
Note what the fix does not break: subagents still share the parent’s long-lived container, and RL / benchmark environments (TerminalBench2, etc.) keep their per-task isolation — those paths have their own key rules, and delegate_task children still share the parent session’s connection.
What You Should Do
- Multi-profile + SSH users: update to a build containing the fix (
hermes update --branch main, or wait for the next release — the latest stable is still v0.20.5); - Verify it: configure two profiles with different remote hosts, run
hostnameorecho $SSH_CONNECTIONin each, and confirm the output matches each profile’s config; - General tip: multi-profile setups are covered in Hermes Profiles: Multiple Independent Instances; terminal/env config keys also get a mention in 4 Hidden Hermes Tricks.
Release Status
The fix (#92156) is merged to main (Aug 22) and not yet in a release. To try it early: hermes update --branch main. It belongs to the same late-August batch of gateway/terminal hardening as the loop-watchdog tuning guide.
Wrap-up
Cross-profile SSH environment leakage is an invisible trap: not an error, but silently running on the wrong host. The good news is the fix is already in main — with per-session cache scoping, switching profiles can no longer pick up the previous profile’s remote environment. If you’re a heavy multi-profile user, it’s worth updating and verifying right away.