OpenClaw merged PR #98755, "fix(cron): detach session-targeted runs" on July 1st, tightening a subtle but important boundary between scheduled work and live conversations.
The fix targets current and session:<id> cron jobs. These jobs were using the source chat or session key as the execution session, which meant scheduled work could block or contaminate the same transcript a human was actively using.
That is a small implementation detail with a very visible operator impact.
What Changed
The PR changes isolated, current, and session:<id> cron jobs to run as detached execution targets. The selected source session is still used for delivery, but the actual scheduled work gets its own execution context.
That split lets OpenClaw preserve the intent of session-targeted cron: send results back to the relevant chat, topic, or transcript. At the same time, it keeps the scheduled agent turn from becoming part of the live interaction lane.
The PR body also mentions cleanup around task rows that could otherwise be left in awkward childless or no-handle states.
Why This Matters
Cron jobs are one of the places where OpenClaw becomes a long-running operations system. A job can wake an agent, run checks, summarize state, execute maintenance, or monitor external services while the user is elsewhere.
Those jobs still need to report to the right place. But they should not take over the same session state that a user may be steering in real time.
When scheduled work shares the live transcript too directly, several things can go wrong:
- A cron run can block the chat lane while the user is trying to interact
- Scheduled output can alter the context of the live conversation
- Task bookkeeping can become harder to reason about
- Recovery after a failed or interrupted run can leave confusing session artifacts
Detached execution is the cleaner model: run the job separately, then deliver the result to the selected source.
A Stronger Automation Boundary
This also fits the direction OpenClaw has been taking over the last several releases. Cron delivery, target awareness, action-required output preservation, and session wake behavior have all been getting more explicit.
PR #98755 continues that trend by separating where a job runs from where its result lands.
That distinction matters for reliability, but it also matters for trust. Operators should be able to schedule work against a conversation without worrying that the job will silently reshape the active transcript or compete with a human turn.
Validation
The PR is labeled P1 and includes Telegram-visible proof tags, which is the right test surface for this class of bug. The failure is not just internal bookkeeping; it affects how scheduled work appears in real channel sessions.
The reported change focuses on source-session delivery, detached execution targeting, and related task-state behavior. That makes the fix narrow enough to reason about while addressing the operational symptom.
Bottom Line
OpenClaw cron jobs now have a sharper execution boundary for session-targeted work.
Scheduled jobs can still report back to the conversation they are meant to serve, but they no longer have to run inside the live session they are reporting to. For operators who use cron as an automation layer, that is a cleaner and safer default.