Cron runtime leaks background process notifications to origin chat regardless of deliver target #75

New issue

Closed

opened 2026-05-18 00:03:56 +00:00 by Mark · 1 comment

Mark commented

2026-05-18 00:03:56 +00:00

Owner

Observation

LLM-driven cron jobs (those without no_agent: true) that execute scripts via terminal() produce background process completion notifications that route to the origin chat — the chat where the cron job was created — rather than (or in addition to) the configured deliver target.

Example: ops-task-autorun

This job had deliver: "matrix:!eNZqgrf..." set correctly, but its output was arriving in Discord wrapped in:

[Background process proc_... finished with exit code 0
Here is the final output:
OPS: FETCH — next ops task,
No ops tasks to process.]

The deliver target (Matrix) was getting the LLM response, but the background process completion notification leaked to Discord (the origin) as a side channel.

Impact

Any LLM-driven cron that calls terminal() or uses enabled_toolsets may leak output to the wrong chat
This is a systemic runtime issue, not a configuration error
Workaround: convert to no_agent: true + script: — but that eliminates LLM reasoning for jobs that need it

Root cause (speculative)

The cron runtime wraps LLM-driven job execution as a background process. When the subprocess finishes, the completion notification routes to the session origin regardless of the deliver field. The deliver field only controls where the LLM response goes, but the background process notification bypasses it.

Requires research

Trace the exact notification path: where does the background process completion event originate, and how does it select its destination?
Determine whether this affects all LLM-driven cron jobs or only those using terminal()
Design the fix: should the background process notification respect deliver, or should the cron runtime suppress these side-channel notifications entirely?

## Observation LLM-driven cron jobs (those without `no_agent: true`) that execute scripts via `terminal()` produce background process completion notifications that route to the origin chat — the chat where the cron job was created — rather than (or in addition to) the configured `deliver` target. ## Example: ops-task-autorun This job had `deliver: "matrix:!eNZqgrf..."` set correctly, but its output was arriving in Discord wrapped in: ``` [Background process proc_... finished with exit code 0 Here is the final output: OPS: FETCH — next ops task, No ops tasks to process.] ``` The `deliver` target (Matrix) was getting the LLM response, but the background process completion notification leaked to Discord (the origin) as a side channel. ## Impact - Any LLM-driven cron that calls `terminal()` or uses `enabled_toolsets` may leak output to the wrong chat - This is a systemic runtime issue, not a configuration error - Workaround: convert to `no_agent: true` + `script:` — but that eliminates LLM reasoning for jobs that need it ## Root cause (speculative) The cron runtime wraps LLM-driven job execution as a background process. When the subprocess finishes, the completion notification routes to the session origin regardless of the `deliver` field. The `deliver` field only controls where the LLM response goes, but the background process notification bypasses it. ## Requires research - Trace the exact notification path: where does the background process completion event originate, and how does it select its destination? - Determine whether this affects all LLM-driven cron jobs or only those using `terminal()` - Design the fix: should the background process notification respect `deliver`, or should the cron runtime suppress these side-channel notifications entirely?

Mark added the

research

label

2026-05-18 00:03:56 +00:00

Mark added

blocked:needs-decision

and removed

research

labels

2026-05-20 17:56:04 +00:00

Mark closed this issue

2026-05-23 16:36:34 +00:00

Mark commented

2026-05-23 16:36:39 +00:00

Author

Owner

Already fixed — commit dbafa083b (May 9) changed run_job() to clear HERMES_SESSION_PLATFORM/_CHAT_ID to empty strings instead of seeding them from the origin. This prevents terminal_tool.py from routing background process notifications to the origin chat. The HERMES_CRON_AUTO_DELIVER_* vars handle delivery routing instead. Filed May 18, fix was already deployed 9 days prior.

**Already fixed** — commit dbafa083b (May 9) changed `run_job()` to clear `HERMES_SESSION_PLATFORM`/`_CHAT_ID` to empty strings instead of seeding them from the origin. This prevents `terminal_tool.py` from routing background process notifications to the origin chat. The `HERMES_CRON_AUTO_DELIVER_*` vars handle delivery routing instead. Filed May 18, fix was already deployed 9 days prior.