fix(approval): use per-job ContextVar for cron-session flag instead of leaking env var (#56771)

[Tranquil-Flow]

What

execute_code (and dangerous-command guards) were blocked in interactive gateway/CLI/TUI sessions whenever HERMES_CRON_SESSION=1 was present in the process environment — even though the user never ran a cron job in that session (#56771).

Root cause

cron/scheduler.py set os.environ["HERMES_CRON_SESSION"] = "1" process-wide at job start and never cleared it. The approval system then gates on env_var_enabled("HERMES_CRON_SESSION") at 4 sites. When the gateway and scheduler share a process (the normal architecture), the env var leaks via inheritance into every concurrent interactive session, so the approval system treats user chats as cron and blocks execute_code / dangerous commands.

This was the only place in the codebase that set the var, and approval.py was the only consumer — so replacing the process-global set has no other side effects.

Fix

Replace the process-global env var with a task-local ContextVar so the cron flag cannot leak into concurrent interactive sessions:

• gateway/session_context.py — add _CRON_SESSION ContextVar (mirroring the existing _UNSET sentinel pattern of the session vars) plus set_cron_session() / clear_cron_session() / is_cron_session() helpers. is_cron_session() checks the ContextVar first and falls back to the env var only for backward compat with tests / CLI cron paths that set it directly (in production the scheduler no longer sets it, so interactive sessions fall through to False).
• cron/scheduler.py — replace the os.environ set with set_cron_session(True); add clear_cron_session() to the run_job() finally block. The flag is set before the scheduler's existing copy_context() (line 2861) that the agent thread runs inside (_cron_context.run(agent.run_conversation)), so real cron jobs still see True and cron_mode: deny keeps working.
• tools/approval.py — add _is_cron_session() (contextvar-aware, lazy-imported like the existing get_session_env calls) and replace all 4 env_var_enabled("HERMES_CRON_SESSION") checks with it.

Why ContextVar and not env-var reordering

The scheduler sets the cron flag before spawning the agent in a worker thread via copy_context().run(...). ContextVars propagate downward through ctx.run, so the agent thread sees True; concurrent interactive sessions run in their own tasks/contexts where the var is _UNSET, so they resolve to False. By contrast os.environ is shared across all threads/process-children, which is precisely the leak this fixes. Competing approaches that merely reorder the gateway/cron precedence checks (or gate on interactive indicators) leave the env var leaking into spawned subprocesses and reverse the original design invariant that cron takes absolute priority over gateway approval.

How verified

• 11 new regression tests (tests/tools/test_cron_session_leak.py): contextvar resolution, the core thread-isolation mechanism (scheduler thread sets the flag, concurrent gateway thread does not see it), env-var fallback for backward compat, contextvar-overrides-leaked-env, and the full check_execute_code_guard + _is_gateway_approval_context matrix (cron blocks, interactive allowed, interactive-after-scheduler-ran still allowed).
• 325 existing approval/cron tests pass.
• 612 scheduler tests pass.
• Branch is exactly one focused commit ahead of main (0 1).

Closes #56771.

---

Auto-published by Moonsong via Path B automated pipeline.

[harjothkhara]

Recommendation: this looks like the strongest lane for the #56771 cron-session leak cluster, including the newer corroborating reports like #57736 and #60350.

Why I would pick this over the sibling PRs:

• fix(approval): use per-job ContextVar for cron-session flag instead of leaking env var (#56771) #56796 removes the source leak by replacing the scheduler-owned os.environ["HERMES_CRON_SESSION"] write with a per-job ContextVar, then reads that same scoped marker from all approval guards.
• fix(cron): clean up HERMES_CRON_SESSION env var after each job run (#56771) #57124 / closed fix(cron): clean up HERMES_CRON_SESSION env var after each job run (#59236) #59242 only pop the env var in run_job() cleanup. That is minimal, but an interactive gateway session can still run while a long cron job is active, so it can still see the process-global cron marker during the job.
• fix(approval): let gateway session indicators override process-wide cron flag #56784 / fix(approval): ignore leaked cron env in gateway sessions #57169 are consumer-side filters that protect some gateway contexts, but they intentionally leave the legacy env marker alive in the process and therefore still allow inherited process state to leak into subprocesses or any non-gateway approval path.
• fix: isolate cron approval context #36004 is the older same-direction ContextVar lane, but fix(approval): use per-job ContextVar for cron-session flag instead of leaking env var (#56771) #56796 has the tighter current issue linkage plus focused thread-isolation coverage and a fully green check rollup.

Local proof on #56796:

scripts/run_tests.sh tests/tools/test_cron_session_leak.py tests/tools/test_cron_approval_mode.py tests/tools/test_execute_code_approval_cluster.py -- -q
# 58 tests passed

git diff --check origin/main...HEAD
# clean

.venv/bin/python scripts/check-windows-footguns.py cron/scheduler.py gateway/session_context.py tools/approval.py tests/tools/test_cron_session_leak.py tests/tools/test_cron_approval_mode.py tests/tools/test_execute_code_approval_cluster.py
# pass

Two-lens read: the runtime mechanism is covered because the new test demonstrates scheduler-thread cron state does not appear in a sibling gateway thread, while real cron contexts still hit cron_mode. Architecturally, this follows the existing contextvars.copy_context() path in cron/scheduler.py instead of trying to infer interactivity from a stale process environment.

[teknium1]

Thanks for targeting the scheduler-owned process-global marker: current main still writes os.environ["HERMES_CRON_SESSION"] in cron/scheduler.py:2812, while the approval gates consume it in tools/approval.py:241, :2173, :2700, and :3121.

Problems

• tools/approval.py:189 now delegates cron detection to gateway.session_context.is_cron_session(). The existing cron-mode tests in tests/tools/test_request_tool_approval.py:106-107 and :116-117 mock only approval.env_var_enabled, so that mock no longer controls the cron branch. Those tests need to set the environment marker or mock _is_cron_session.

Suggested changes

• Update both affected tests and include tests/tools/test_request_tool_approval.py in the focused validation set.

Automated hermes-sweeper review.

[teknium1]

This bypasses the approval.env_var_enabled mock used by tests/tools/test_request_tool_approval.py:106-107 and :116-117; those two cron-mode tests will no longer simulate cron in a clean environment. Please update them to set HERMES_CRON_SESSION or mock _is_cron_session.