fix(env): multi-profile serve no longer leaks a routed profile's terminal backend into the shared process env (#102769, salvage #97014) - #103625
Merged
kshitijk4poor merged 1 commit intoSep 5, 2026
Conversation
In a multiplex dashboard (one process serving every profile on the host),
a secondary profile's terminal.backend could leak into the shared
os.environ and silently override the launch profile's terminal backend.
A profile configured for terminal.backend: ssh would find itself running
every command locally because a sibling profile with backend: local had
polluted the shared environment.
The tell is an asymmetric env state on the launch session:
TERMINAL_ENV=local # leaked from a sibling profile
TERMINAL_SSH_HOST=10.10.0.103 # still the launch profile's, untouched
A restart does not help: as soon as the sibling profile is touched again
(a turn, a cron tick), the shared env is re-poisoned.
Root cause: env_loader._reapply_terminal_config_bridge() guards "only
re-bridge config into the shared os.environ when this load is for the
process's own profile" via _process_hermes_home(). That helper delegated
to get_hermes_home(), which follows the context-local
set_hermes_home_override a per-request task installs. When a per-turn
handler is scoped to a secondary profile and triggers a dotenv reload,
both sides of the comparison resolve to that secondary profile, the guard
passes, and the bridge writes the wrong profile's terminal.backend into
the shared environment. Because the secondary profile's config carries no
TERMINAL_SSH_* keys, only TERMINAL_ENV is overwritten, producing the
asymmetric state above.
The helper was introduced for the config-cache key (where following the
active home is correct) and later reused for the terminal bridge guard,
where the override-following semantics are wrong.
Fix: delegate _process_hermes_home() to get_process_hermes_home(), the
override-immune resolver built for exactly this. It reflects the scope the
process was launched under, ignoring per-task overrides. Both call sites
(the bridge guard and the secrets-cache reuse check) want the true process
home. Single-profile / CLI behaviour is unchanged: with no active
override the two resolvers are identical.
Complements the terminal_tool._active_environments session-key fix: that
scopes the per-session environment cache; this keeps the shared os.environ
the cache reads TERMINAL_ENV from uncontaminated in the first place.
Adds tests/hermes_cli/test_terminal_bridge_profile_scope.py covering both
the override-immune resolver and the no-leak reload behaviour.
kshitijk4poor
enabled auto-merge (rebase)
September 5, 2026 11:26
alt-glitch
added
type/bug
This was referenced Sep 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In a multi-profile
hermes serve(Desktop backend with the in-process multiplex cron ticker), a routed profile'sterminal.*config no longer leaks into the sharedos.environ, so the launch profile's next unscoped turn stays on its own terminal backend instead of running inside another profile's Docker container with that profile's volumes mounted.Salvage of #97014 by @Bergmann89 (single commit cherry-picked unchanged, authorship preserved). Fixes #102769, #96992. Supersedes duplicate #103512.
Root cause
env_loader._reapply_terminal_config_bridgeguards "only bridge config → env for the process's own profile" by comparing against_process_hermes_home(), which resolved throughget_hermes_home()— a resolver that FOLLOWS the context-localset_hermes_home_overridethe cron ticker installs per profile. Under the override the guard passed for the secondary profile andapply_terminal_config_to_env()wrote itsTERMINAL_ENV=docker/TERMINAL_DOCKER_VOLUMES=…into the process-global environment.Change
_process_hermes_home()delegates tohermes_constants.get_process_hermes_home(), the override-immune resolver that already exists for exactly this. Its other caller (_load_secrets_configshared-cache reuse) now also refuses the shared cache under an override — the safe direction.tests/hermes_cli/test_terminal_bridge_profile_scope.py), red onorigin/main.Validation
backend: local, secondary profilebackend: docker+ volumes; scope to the secondary viaset_hermes_home_overrideandload_hermes_dotenv(hermes_home=<secondary>)(what the cron tick does)TERMINAL_ENV=docker,TERMINAL_DOCKER_VOLUMES=["scout-session:/session"]; branch: both stay unsetscripts/run_tests.shenv_loader / terminal-bridge / scheduler_provider suites