Refresh Hermes env before cron and MCP loads

[bee-san]

Summary

• Re-read Hermes .env/BSM secrets before cron jobs and MCP config expansion so rotated values are visible during per-run reloads.
• Added regression coverage for cron reload, env-source cache reset, and MCP config interpolation order.

Tests

• python -m pytest tests/test_bitwarden_secrets.py tests/test_env_loader_secret_sources.py -q -o 'addopts='
• python -m pytest tests/cron/test_scheduler.py -q -o 'addopts='
• python -m pytest tests/cron/test_cron_profile.py -q -o 'addopts='
• python -m pytest tests/cron/test_cron_workdir.py -q -o 'addopts='
• python -m pytest tests/hermes_cli/test_config_env_expansion.py -q -o 'addopts='
• python -m pytest tests/hermes_cli/test_mcp_config.py tests/hermes_cli/test_mcp_tools_config.py tests/hermes_cli/test_custom_provider_model_switch.py -q -o 'addopts='
• python -m pytest tests/tools/test_mcp_tool.py -q -o 'addopts='

[liuhao1024]

Correct fix. The key change in tools/mcp_tool.py—calling load_hermes_dotenv() before load_config()—ensures env vars are refreshed before config.yaml expansion. The reset_secret_source_cache() change clears the Bitwarden cache properly. Tests verify the order of operations. No issues found.

[liuhao1024]

Correct fix. The key change in tools/mcp_tool.py—calling load_hermes_dotenv() before load_config()—ensures env vars are refreshed before config.yaml expansion. The reset_secret_source_cache() change clears the Bitwarden cache properly. Tests verify the order of operations. No issues found.

[teknium1]

Thanks for identifying the dotenv/config ordering issue. The cron half has already landed through later work: current cron/scheduler.py:2776-2793 resets the secret-source cache and reloads Hermes dotenv, shipped in 836732f54.

Problems

• The scheduler hunk is now superseded and the PR is conflicting against current main; it should not be reapplied over the current cron path.
• The added MCP test mocks load_config(), so it does not exercise the real expansion at hermes_cli/config.py:7010, where stale environment values are materialized before the current reload at tools/mcp_tool.py:3766-3770.

Suggested changes

• Salvage the MCP-only reorder: call load_hermes_dotenv() before load_config() in tools/mcp_tool.py.
• Add a temp-HERMES_HOME regression using real config.yaml expansion and a refreshed .env value.

Automated hermes-sweeper review.

[bee-san]

Rebased onto current main and narrowed to the still-missing behavior at exact head 6f2fd9a92: MCP config now reloads Hermes env/BSM sources before config expansion, and refresh clears stale secret-source provenance. Current main already had the cron reload path, so that duplicate production hunk was dropped while its regression coverage was preserved. Focused validation: 228 tests passed across env-loader/MCP plus the cron regression before the final assertion portability fix; the exact three affected regressions then passed, Ruff passed, and git diff --check passed.

[bee-san]

Exact-head QA confirms the MCP reload ordering at 6f2fd9a is correct (including a real temp-HERMES_HOME config expansion from a refreshed synthetic .env value), and the broader focused suite passed. The rollout gate is still blocked by the BWS failure-output path this reload can exercise: _run_bws_list embeds up to 200 raw characters of backend stderr/stdout in RuntimeError, apply_bitwarden_secrets stores str(exc), and env_loader prints the resulting error. A synthetic backend marker survived unchanged. Before this rollout merges, please make failure output generic/redacted and add tests asserting backend stderr/exception, bootstrap-token, and secret-value sentinels never reach terminal/log output while startup remains non-fatal.

[bee-san]

QA verdict at exact head 6f2fd9a92: blocked. The focused env-loader/MCP/cron suite passes (450 tests), but the required two-pass refresh behavior does not: a vault-owned value remains in os.environ after the remote key disappears. No real profile, gateway, cron, or Bitwarden state was modified.

[bee-san]

Exact-head independent QA at ca3186895bd07825d2af9e12e4b690b03eb4de27: the changed/focused suite passed (570 tests) and Ruff passed, including redaction, rotation, removal, failed-source retention, shell/.env replacement, collision, cron, and MCP coverage. One refresh edge case still blocks rollout:

• hermes_cli/env_loader.py:475-484 converts a malformed/unreadable config.yaml into {}. After reset_secret_source_cache() has moved provenance into _PENDING_SECRET_OWNERSHIP, _apply_external_secret_sources() intentionally continues on an empty config (:413-429), and apply_all() removes the matching source-owned env values before finding no enabled source to restore them. A synthetic two-pass probe produced before='known-good', after=None, and cleared provenance. This differs from the adjacent failed-fetch behavior, which retains the known-good value, and can drop live credentials during a gateway/cron reload while a config edit is malformed.

Please distinguish config parse/read failure from an intentionally empty/disabled secrets config. On parse/read failure, retain pending ownership plus current known-good values and leave the home retryable; add a regression covering valid first load → reset → malformed config → value/provenance retained without leaking parser/backend details.

GitHub's required All required checks pass context is also absent because the fork CI run ended action_required; this head is not merge-eligible yet.

[teknium1]

Closing with thanks — the bug halves of this have landed on main via the secrets cluster: #69056 made failed secret loads retryable (the permanent-skip half), #69053 fixed MCP stdio servers missing vault-injected vars, and cron jobs re-enter load_hermes_dotenv() per run. What remains from your PR is mid-process refresh of ROTATED values inside one long-lived process — a real feature ask, but it belongs as a small TTL knob on the orchestrator's once-per-process guard (a few lines in apply_all/env_loader), not a cli.py+gateway+tui patch. If you want to resubmit that focused version against the current agent/secret_sources/registry.py, we'd welcome it. Thanks @bee-san!