fix(cron): propagate HERMES_HOME to script subprocesses

[alexzhu0]

Partial fix for the process-spawn dimension of #18594.

What this fixes

#18746 (@liuhao1024) already added a one-shot stderr warning when get_hermes_home() falls back under an active profile. That was defense-in-depth — the observability layer. This PR addresses one of the concrete spawn sites that triggers the warning: the cron script runner.

Root cause in scope

cron/scheduler.py::_run_job_script() calls subprocess.run(...) without env=, so the child inherits only the shell environment. On systemd / launchd / docker-exec deployments where the cron daemon's unit file doesn't ship an explicit Environment=HERMES_HOME=..., the child starts with HERMES_HOME unset and get_hermes_home() falls back to ~/.hermes (default profile) — silently corrupting cross-profile data as described in the incident report in #18594.

Fix shape

Inject the scheduler's resolved _hermes_home into the child env via setdefault semantics:

child_env = dict(os.environ)
child_env.setdefault("HERMES_HOME", str(_hermes_home))

• setdefault semantics: if the shell env already has HERMES_HOME (user explicitly ran hermes with an override), that wins.
• dict(os.environ) base: all other env vars (PATH, HOME, HERMES_PROFILE, user custom markers) still flow through — no clean-env regression.

Why only cron/scheduler.py

I audited all subprocess spawns under cron/, hermes_cli/, and tools/:

Spawn site	Passes env= ?	HERMES_HOME propagated?
cron/scheduler.py:595 _run_job_script	❌ no env	This PR
hermes_cli/kanban_db.py:2117 kanban dispatcher	✅ env = dict(os.environ)	✅ inherits naturally
tools/skills_hub.py:193 gh auth lookup	(not scope — reads GitHub token, doesn't need HERMES_HOME)	n/a
tools/environments/docker.py	✅ explicit env mapping	✅
tools/terminal_tool.py	✅ passes configured env	✅

So this is the single narrow fix that was needed at the cron layer. Other layers aren't regressed.

Not in scope

• Changes to get_hermes_home() itself — @liuhao1024's call was that classic-mode users rely on the ~/.hermes fallback, so strict raising isn't viable. Agreed. Spawn-layer propagation is the right fix.
• Changes to the systemd gateway unit template — that's a separate file and already has Environment=HERMES_HOME=... where needed.
• Audit of MCP stdio subprocesses — different failure mode, different fix.

Tests

3 new in TestRunJobScript, 7 existing → 10/10 pass:

• test_script_sees_hermes_home_when_shell_env_dropped — the core regression: scheduler has _hermes_home resolved, shell env drops HERMES_HOME, child must still see it
• test_script_env_does_not_overwrite_explicit_shell_value — setdefault semantics guard
• test_script_inherits_other_env_vars — dict(os.environ) base semantics guard

Full file: 40/40 pass.

Files

• cron/scheduler.py: +11 / -1
• tests/cron/test_cron_script.py: +96

[alexzhu0]

Status / gentle ping — opened 2026-05-04, no review yet.

This is a partial fix for the spawn dimension of #18594. #18746 (@liuhao1024) already added the observability layer (one-shot stderr warning when get_hermes_home() falls back). This PR closes one of the concrete spawn sites — cron's script runner was launching subprocesses without propagating HERMES_HOME, so cron-spawned scripts under a non-default profile would silently fall back to ~/.hermes/ instead of the active profile dir.

Re: failing CI — nix (ubuntu-latest), Scan PR for critical supply chain risks, and test are all failing on main for unrelated reasons (Anthropic 1M-beta header config mismatch, OpenAI max_completion_tokens rename, matrix _auto_create_thread await semantics). None touch cron/ or subprocess spawn code. Happy to rebase if a fresh run would help clear the noise.

cc @teknium1 — small, surgical fix; would appreciate eyes when you get a moment.

[alexzhu0]

Closing — defense-in-depth piece (warning when fallback hits) shipped via @liuhao1024's #18746 in v0.12.0, and the cron subsystem has shifted significantly enough that this branch is now DIRTY against main. The narrower spawn-propagation fix would need to be re-derived against the new tenant/profile-aware kanban dispatcher. Not worth a stale rebase against the new layout — happy to revisit if the warning-channel telemetry shows actual occurrences in the wild.