OpenClaw Heartbeat: Background Exec Runs Stop Blocking Visible Turns
Heartbeat-scheduled runs no longer compete with your interactive session for the agent lane, and exec completion notifications now arrive even when the recurring heartbeat cadence is disabled. Both fixes are merged and documented in the official gateway docs.
Two heartbeat fixes landed back to back this week, and both change behavior operators can observe from the outside: how often your interactive turns get stuck behind scheduled work, and whether background command results ever reach you at all.
Heartbeat gets its own lane
Historically, a heartbeat-triggered run and a visible turn you started by typing competed for the same processing lane, so a long-running scheduled check could delay the response to a direct request — an odd experience for anyone who left periodic health-check automations enabled on an actively used assistant.
PR #126853 moves heartbeat runs onto a background lane with three properties worth knowing:
- Visible turns keep priority — the main lane stays available for interactive work; heartbeat work yields rather than blocks it.
- Overlap is now possible and proven — the PR includes an E2E test (
pr126853-heartbeat-visible-lane-proof) asserting a heartbeat run can execute concurrently with a visible turn instead of serializing behind it. - The embedded fallback honors the same contract — deployments using the embedded runner get lane forwarding too, so the fix is not limited to full gateway installs.
Disabled cadence no longer eats exec completions
PR #126895 closes a long-standing issue (#62505): when heartbeat.every was set to disable the recurring cadence, background tools.exec runs with notifyOnExit queued their Exec completed system event and requested a targeted wake-up — but nothing delivered it, so completions silently piled up undelivered.
The fix unifies the targeted unscheduled wake policy so that disabling only the recurring schedule leaves event-driven wakes intact. The official heartbeat documentation was updated in the same change and now states it plainly: setting heartbeat.every: "0m" disables only the recurring cadence; a targeted event-driven wake can still run one agent turn, such as the completion follow-up requested by a background exec task, and does not re-enable any recurring schedule.
What operators should do
- Revisit disabled heartbeats. If you previously turned heartbeat off because scheduled runs interrupted interactive sessions or because you feared surprise scheduled activity, note that disabling cadence no longer suppresses exec-completion wakes — that is the documented, intended behavior now, not a regression.
- Expect faster interactive responses if you run frequent heartbeat automations; the lane separation removes head-of-line blocking.
- Audit heartbeat-driven automations for concurrency assumptions. Anything written assuming “a heartbeat run never overlaps my active conversation” is now wrong; check automations that touch shared files or state during your working hours.
- Keep tool policy as your safety control. The docs are explicit that cadence settings are not a security boundary — use tool policy and sandboxing to constrain what heartbeat-triggered turns may do, since those turns can now fire even with
"0m"configured.
Interpretation note: behavioral descriptions follow the merged diffs, their tests, and the current official docs retrieved August 23, 2026; operational impact estimates are ours.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF