[Bug] Switching memory provider leaves stale sub-keys in merged config — causes gateway instability and crashes

[wyl1988]

Bug Description

When a user switches memory.provider from one provider to another (e.g., hindsight → openviking), the config deep-merge logic updates the top-level provider key but does not remove the old provider's sub-keys.

For example, after changing memory.provider from hindsight to openviking:

# Profile config.yaml (correctly updated)
memory:
  provider: openviking

# But main config.yaml still has:
memory:
  provider: hindsight      # ← overridden by profile
  hindsight:                # ← stale sub-key NOT removed
    base_url: http://localhost:36813

Deep merge result: provider=openviking (from profile) + hindsight.base_url (from main, stale). Some code paths that read main config for provider initialization probe the stale hindsight.base_url, attempt to connect to a non-existent service (port 36813), fail, and cause:

1. Gateway WSS disconnections (keepalive ping timeout)
2. SIGTERM with exit code 1 (FAILURE)
3. Automatic restart loops

Impact

Observed in production (20-profile deployment):

• Gateway WSS disconnected twice in 40 minutes after switching from hindsight to openviking
• Gateway crashed with exit code 1 and auto-restarted
• Root cause was stale hindsight.base_url in main config.yaml that was never cleaned up

This affects any memory provider switch, not just hindsight → openviking.

Steps to Reproduce

1. Configure memory.provider: hindsight with hindsight.base_url in main config.yaml
2. In a profile config, set memory.provider: openviking
3. Uninstall hindsight service (stop + disable)
4. Restart gateway
5. Observe WSS disconnections and gateway crashes

Expected Behavior

When memory.provider changes, the merge logic should either:

1. Remove the old provider's sub-keys from the merged result
2. Or warn the user about stale sub-keys

Workaround Applied

Manually remove stale hindsight sub-keys from main config.yaml.

Environment

• Hermes Agent: 0.18.0
• 20 profiles, switched from hindsight to openviking

[teknium1]

Thanks for the detailed report. Automated hermes-sweeper review could not reproduce the stated configuration path on current main.

• Named profiles are independent HERMES_HOME directories; hermes_cli/main.py:500-521 resolves the selected profile before config imports, and hermes_cli/config.py:747-749 reads only that home’s config.yaml.
• The runtime loader deep-merges defaults with that one selected file (hermes_cli/config.py:6982-7046); it does not merge a named profile with the default profile’s config.
• In multiplexed gateways, gateway/run.py:1441-1472 scopes config, memory, and credentials to the routed profile, and gateway/run.py:17238-17246 runs the turn inside that scope.
• Memory initialization selects only memory.provider (agent/agent_init.py:1395-1460), so an inactive provider’s stale configuration is not initialized.

The reported default-config hindsight settings therefore cannot be combined with a routed profile’s memory.provider: openviking through the described merge path on current main.