fix(cron): clean up HERMES_CRON_SESSION env var after each job run (#56771)

[AlexFucuson9]

Problem

When the cron scheduler runs in-process via InProcessCronScheduler (same Python process as the gateway), run_job() sets os.environ["HERMES_CRON_SESSION"] = "1" but never removes it in the finally block. Since os.environ is process-global and shared across all threads, this sentinel leaks into interactive gateway sessions.

Impact: After any cron job runs, execute_code and terminal commands in Telegram/gateway interactive sessions are blocked with the cron-deny approval error until the gateway process is restarted.

Root Cause

• cron/scheduler.py:2444 — sets os.environ["HERMES_CRON_SESSION"] = "1"
• cron/scheduler.py:3025+ — finally block cleans up TERMINAL_CWD, ContextVars, session DB, agent resources — but not HERMES_CRON_SESSION
• tools/approval.py:2655 — check_code_execution_approval() reads HERMES_CRON_SESSION from os.getenv() and blocks execution

The codebase already uses ContextVars for per-job session state to avoid exactly this class of cross-session pollution, but HERMES_CRON_SESSION was left as a raw os.environ write.

Fix

Add os.environ.pop("HERMES_CRON_SESSION", None) to the finally block in run_job(), alongside the existing TERMINAL_CWD cleanup. This ensures the env var is only present while a cron job is actively running.

Fixes #56771

[alt-glitch]

This was generated by AI during triage.

Competing fix cluster for #56771 (all open, all different sites/mechanisms): this PR (#57124) cleans up the leaked HERMES_CRON_SESSION at the source (os.environ.pop in run_job's finally); #56796 replaces the process-global env var with a per-job ContextVar (gateway/session_context.py); #56784 reorders the approval-context check so gateway session indicators take precedence over the cron flag (consumer side). This one is the smallest surgical source-side fix. Flagging for a maintainer to pick the canonical approach; not marking any as a duplicate.

[teknium1]

Thanks for isolating the source of the leak. The current main implementation still has the process-global marker at cron/scheduler.py:2812, so the underlying report is valid.

Problems

• The added cleanup is unsafe with concurrent jobs. cron/scheduler.py:3741-3788 dispatches workdir-less jobs in parallel; when one job reaches this pop, another active cron job can lose its cron classification. The approval gates at tools/approval.py:2173, 2700, and 3121 would then no longer apply approvals.cron_mode to that remaining job.
• Cleanup only after run_job() returns still leaves an interactive gateway request misclassified while any cron job is active: the process-global flag is set at cron/scheduler.py:2812, and _is_gateway_approval_context() prioritizes it at tools/approval.py:241-245.
• This diff adds no regression test for the cross-thread gateway/cron case.

Suggested changes

• Scope the cron marker per job (for example with the existing ContextVar session-state approach) and have the approval gates read that scoped value.
• Add a concurrent-thread regression test showing gateway approval remains interactive while real cron work still honors approvals.cron_mode.

Automated hermes-sweeper review.

[teknium1]

This process-global cleanup is unsafe when due jobs run concurrently: a completed job can clear the marker while another cron job is still active, causing its approval checks to stop enforcing approvals.cron_mode. The cron marker needs per-job scoped state rather than a shared env-var lifetime.