Hermes Agent
Hermes scopes MCP transports after a wrong-workspace report
A multi-session Hermes gateway could expand MCP workspace variables from the backend default and reuse that process across projects. The proposed fix keys transports, retry state and circuit breakers by canonical session workspace; a related desktop report finds profile credentials leaking through process-global environment state.
NousResearch/hermes-agent issue #82121 is the inspected primary source: “[Bug]: MCP context variables can route tools to the wrong session workspace.” The related records below were inspected as supporting context rather than independent confirmation.
The facts
- NousResearch/hermes-agent issue #82121 was created 2026-08-09T00:49:52Z and was open at inspection; its title is “[Bug]: MCP context variables can route tools to the wrong session workspace.” - NousResearch/hermes-agent PR #82122 was created 2026-08-09T00:50:29Z and was open at inspection; its title is “fix(mcp): stop context-variable servers from accessing the wrong session workspace.” - NousResearch/hermes-agent issue #82117 was created 2026-08-09T00:41:19Z and was open at inspection; its title is “Desktop serve process leaks root.env credentials to all profile sessions (OpenViking cross-profile credential leakage).” - The repository reported 227532 stars, 29728 open issues, default branch main, and last push 2026-08-09T00:42:37Z. - The latest tagged-release baseline checked was v2026.8.3 published 2026-08-03T16:57:52Z.
What changed
NousResearch/hermes-agent issue #82121 reports: Bug Description MCP server configurations that use ${workspaceFolder} or ${workspaceFolderBasename} can be bound to the backend default workspace instead of the workspace of the session making the tool call. In a gateway process serving multiple sessions, the same process-global MCP transport can then be reused across distinct session workspaces. For filesystem-style MCP servers, this can make a tool read from or write to the wrong project without an obvious routing error. Steps to Reproduce 1. Configure a stdio MCP server whose fixed launch arguments include ${workspaceFolder} and ${workspaceFolderBasename}. 2. Start one Hermes gateway process and record two active sessions with different working directories, such as session-alpha and session-beta. 3. Invoke the same MCP server from each session and have the server report its fixed launch root and process identity. 4. Observe that, before the fix, both variables expand to the backend default workspace and the later session reuses the original process-global server. Expected Behavior Each MCP call should expand workspace context variables from the active session's authoritative working directory. Calls may reuse a transport only
NousResearch/hermes-agent PR #82122 reports: What does this PR do? MCP servers configured with ${workspaceFolder} or ${workspaceFolderBasename} now resolve those values from the session making each tool call instead of from the backend default workspace. This prevents workspace-sensitive servers from silently reading or modifying the wrong project when one process serves multiple sessions, while preserving one stable public tool schema per configured server. Symptom Two sessions with different authoritative working directories can invoke the same workspace-sensitive MCP tool but receive a transport whose fixed arguments point to the backend workspace or the first session's workspace. Impact Filesystem-style MCP tools can return files from or write changes to the wrong project. The verified scenario is a single gateway process serving multiple session working directories; broader deployment frequency was not measured. Bug Cause Trigger:** tools/mcp_tool.py::_workspace_folder, _load_mcp_config, and the server lookup paths used by regular tools and generated resource/prompt utilities. Causal chain:** 1. MCP configuration is loaded before a tool call supplies task/session identity. 2. Workspace context variables are eagerly expanded from the backend/default root and the transport is cached by raw server
NousResearch/hermes-agent issue #82117 reports: Bug Description When the Hermes desktop app runs hermes serve --isolated, the process loads the **global root** ~/.hermes/.env into os.environ once at startup (via load_hermes_dotenv() in hermes_cli/main.py:699). When a user opens a chat for a different profile (e.g. vish), the gateway's per-turn handler sets a HERMES_HOME **contextvar** via set_hermes_home_override() — but it does **not** reload that profile's.env into os.environ. Any plugin that reads os.environ directly picks up the root.env's credentials regardless of which profile the session is scoped to. This causes **cross-profile credential leakage**: a vish session authenticates to OpenViking as default/default-agent (from the root.env) instead of vish/vish-agent (from /home/ben/.hermes/profiles/vish/.env). The auto-recall context then injects memories from the default-agent namespace — including another profile's soul/identity files — into the wrong session. Steps to Reproduce 1. Configure the desktop app with multiple profiles, each with its own.env containing different OPENVIKING_ACCOUNT / OPENVIKING_USER values 2. Put OPENVIKING_ACCOUNT=default, OPENVIKING_USER=default-agent in the root ~/.hermes/.env 3. Put OPENVIKING_ACCOUNT=vish, OPENVIKING_USER=vish-agent in ~/.hermes/profiles/vish/.env 4. Open a chat in the desktop app as the vish profile 5. Observe the
Why it matters
Session identity cannot stop at the public tool schema. Fixed launch arguments, cached transports and credential lookup all need the same tenant and workspace authority as the call. The operator test is whether visible output, retained state and authority still describe the same event after retries, background work or restart.
Current
The primary record was open when captured on 2026-08-09. The tagged-release baseline was v2026.8.3 published 2026-08-03T16:57:52Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/NousResearch/hermes-agent/issues/82121. Supporting records are https://github.com/NousResearch/hermes-agent/pull/82122 and https://github.com/NousResearch/hermes-agent/issues/82117. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Audit every process-global cache in a multi-profile gateway. Stable schemas may be shared; workspace roots, credentials and transport ownership may not. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.