PR #18947: fix(delegate): always reload delegation config from disk, drop stale CLI_CONFIG cache (#18946)

• Repository: NousResearch/hermes-agent
• Author: yonefive71
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/18947

Description (problem / solution / changelog)

Summary

Fixes #18946. hermes config set delegation.<key> <value> writes config.yaml on disk and reports success, but the change had no effect on the running process — delegate_task continued using the previously-cached values until the CLI/gateway was restarted. Silent failure with no warning.

The bug

tools/delegate_tool.py:2322 — _load_config() consulted cli.CLI_CONFIG first and only fell through to a fresh disk read when CLI_CONFIG was empty:

def _load_config() -> dict:
    try:
        from cli import CLI_CONFIG
        cfg = CLI_CONFIG.get("delegation", {})
        if cfg:
            return cfg          # <-- runtime cache wins; disk ignored
    except Exception:
        pass
    try:
        from hermes_cli.config import load_config
        full = load_config()
        return full.get("delegation", {})
    except Exception:
        return {}

CLI_CONFIG is initialized once at cli.py:600 (CLI_CONFIG = load_cli_config()) and never refreshed. hermes config set mutates the file on disk but has no IPC channel to notify the running process. Result: stale cache silently wins for the lifetime of the process.

This affected every delegation.* knob (model, provider, max_iterations, max_concurrent_children, reasoning_effort, base_url, api_key, inherit_mcp_toolsets, etc.) since they all flow through the same _load_config() path.

Fix

Always read fresh from hermes_cli.config.load_config(). The disk read is cheap — config.yaml is small and only consulted at delegation boundaries (i.e. when a subagent is spawned), not on every API call.

cli.CLI_CONFIG is preserved as a fallback only for test contexts where hermes_cli.config isn't importable but CLI_CONFIG has been mocked in directly. The order is inverted from before: disk first, in-memory cache second.

Tests

tests/tools/test_delegate.py::TestLoadConfigDiskFreshness — three cases:

• test_disk_changes_visible_after_initial_load — the headline regression: disk holds new value, CLI_CONFIG holds old value, _load_config() returns the new value
• test_falls_back_to_cli_config_when_disk_read_fails — preserves test-context behaviour where CLI_CONFIG is mocked but hermes_cli.config.load_config raises
• test_returns_empty_dict_when_both_sources_fail — defensive: both sources fail → returns {}, doesn't propagate exception

Verified the empty-CLI_CONFIG fallback path implicitly through the existing 121 tests in TestDelegationCredentialResolution / TestDelegationProviderIntegration / etc., which all mock _load_config directly and therefore aren't affected by the implementation change.

Full test run:

$ pytest tests/tools/test_delegate.py -q
124 passed in 2.44s

Notes for reviewers

• The disk read on each _load_config() call is well within budget — delegation is invoked at subagent-spawn time (a heavy operation involving network roundtrips, agent construction, and tool schema enumeration). One additional YAML load adds microseconds to an operation that already takes hundreds of milliseconds minimum.
• An mtime-based reload would be slightly more efficient, but adds complexity (cache invalidation logic, atomicity concerns on writes, etc.) for a savings that's not measurable. If profiling later shows this as a hot path, an mtime check is a backwards-compatible refinement.
• Behavior in test contexts that mock cli.CLI_CONFIG directly (not hermes_cli.config.load_config) is preserved by the fallback — see test_falls_back_to_cli_config_when_disk_read_fails. The 121 existing tests in this file mock _load_config itself, so they're indifferent to the change.

Fixes #18946

Changed files

• tests/tools/test_delegate.py (modified, +88/-0)
• tools/delegate_tool.py (modified, +22/-13)

PR #18967: fix(delegate): read delegation config from disk first to avoid stale cache

• Repository: NousResearch/hermes-agent
• Author: Thatgfsj
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/18967

Description (problem / solution / changelog)

Summary

Fixes #18946

_load_config() in tools/delegate_tool.py checked the runtime cache (cli.CLI_CONFIG) first and never fell back to disk when the cache existed. This meant hermes config set delegation.model <X> wrote to disk correctly but the running process continued using the old value silently.

Changes

Reverse the priority in _load_config(): always read from the persistent config file first, falling back to CLI_CONFIG only when the disk read fails. This makes delegation.* changes take effect immediately without requiring a process restart.

Test plan

# Start hermes, then from another shell:
hermes config set delegation.model some-other-model
# delegate_task should now use the new model without restart

Changed files

• tools/delegate_tool.py (modified, +12/-12)

PR #18978: fix(tools): prefer load_config() over stale CLI_CONFIG in delegate _load_config()

• Repository: NousResearch/hermes-agent
• Author: shellybotmoyer
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/18978

Description (problem / solution / changelog)

Fix

Reverses the priority in _load_config() so that load_config() (which has mtime-based cache invalidation) is checked before the in-memory CLI_CONFIG dict.

Problem

hermes config set delegation.model X writes to disk and reports success, but _load_config() in delegate_tool.py checks the in-memory CLI_CONFIG dict first. Since CLI_CONFIG was loaded once at process startup and never invalidated, the stale cached value wins — the new disk config is never read until the process restarts.

This affects CLI, gateway, and cron — any long-running process that calls delegate_task() after a config change via hermes config set.

Root Cause

_load_config() prioritized CLI_CONFIG (stale in-memory dict) over load_config() (mtime-cached disk reads with automatic invalidation). The load_config() function in hermes_cli/config.py already handles cache invalidation correctly by checking (mtime_ns, size) on every call — it just was never reached because CLI_CONFIG was checked first.

Fix Details

• Try hermes_cli.config.load_config() first (mtime-aware, always fresh)
• Fall back to cli.CLI_CONFIG only if load_config() fails
• Added if cfg: guard to the CLI_CONFIG path for consistency

Testing

1. Start a gateway session with delegation.model: google/gemini-2.5-flash
2. From another shell: hermes config set delegation.model google/gemini-3-flash-preview
3. Call delegate_task(...) from the original session
4. Before fix: subagent uses gemini-2.5-flash (stale cache)
5. After fix: subagent uses gemini-3-flash-preview (fresh from disk)

Fixes #18946

Changed files

• tools/delegate_tool.py (modified, +12/-10)