Profile isolation in every multi-profile process (gateway multiplexer,
dashboard, cron) is a ContextVar (set_hermes_home_override) that
threading.Thread targets cannot see. The plugin's daemon threads —
async writer, prefetch, sync, first-turn, init — all funnel through
HonchoSessionManager.honcho, which called get_honcho_client() with NO
config, re-resolving resolve_config_path()/resolve_active_host() from
the ContextVar-blind thread context: every background memory access
landed on the DEFAULT profile. Worse, the OAuth paths did the same, so
a token refresh on a daemon thread could persist the rotated token
into the wrong profile's honcho.json, and a 401 recovery could burn
the wrong profile's single-use refresh token.
- HonchoClientConfig gains provenance (config_path, hermes_home)
captured at resolution time inside the caller's profile scope, with
bound_config_path() for consumers
- manager.honcho passes the bound config instead of re-resolving
- OAuth paths (_apply_fresh_oauth_token, _refresh_cached_oauth,
_reauth_required, _force_reauth) use the bound path
- the honcho.json timeout memo becomes path-keyed instead of
single-slot, so multi-profile processes stop thrashing it and
returning profile A's timeout for profile B
Groundwork for per-identity client caching (#69123, #74065); the
provenance-field shape follows #81401.
Co-authored-by: angel12 <angel12@users.noreply.github.com>
Erosika
8b7d0ed4c7