Files
hermes-agent/tools
dev-agent 9d8efb3504 fix(mcp): pin the active profile's HERMES_HOME into stdio child env
The MCP stdio spawner built its child env from an allowlist (_SAFE_ENV_KEYS)
that omits HERMES_HOME, so every stdio MCP child was launched with no
HERMES_HOME at all. Under a multiplexed host / dashboard-desktop backend
serving `--open-profile` (e.g. hermes-serve-dev.service, host home = default,
opened profile = dev) those children resolved to the platform-default home
instead of the served profile:

  - any Python child importing hermes_constants tripped
    _warn_profile_fallback_once() -> "[HERMES_HOME fallback] HERMES_HOME is
    unset but active profile is 'dev' ... Any data this process writes will
    land in the wrong profile" (issue #18594);
  - children that DO write (caches/state) landed under the default home.

Pin the ACTIVE profile's home at spawn time via get_hermes_home() (honours the
served-profile contextvar, which does not cross the process boundary;
os.environ only holds the launch profile's home). An explicit server
`env.HERMES_HOME` still wins (applied after).

Verified: tests/tools/test_mcp_stability.py,
tests/tools/test_mcp_connect_secret_scope.py -> 20 passed.
Probe: served scope (override=dev) now yields child HERMES_HOME=.../profiles/dev.
2026-11-02 13:31:06 -08:00
..
2026-10-08 19:54:07 +02:00
2026-10-09 17:34:38 +02:00
2026-10-08 19:54:07 +02:00
2026-10-08 21:29:48 +02:00
2026-10-08 21:38:05 +02:00
2026-10-09 17:34:38 +02:00
2026-10-09 17:34:38 +02:00
2026-10-09 17:34:38 +02:00
2026-10-09 17:34:36 +02:00
2026-10-08 21:29:48 +02:00
2026-10-09 17:34:38 +02:00
2026-10-09 17:34:38 +02:00
2026-10-09 17:34:38 +02:00