Bug type
Regression (worked before, now fails)
Summary
I’m seeing what looks like a remaining or regressed variant of the earlier local exec / heartbeat-routing bugs.
The visible heartbeat cron job is correctly scheduled hourly, but heartbeat-related sessions appear to be re-triggered by local exec completed events, causing duplicate heartbeat handling and repeated appends to the daily memory file.
In practice, this produced hundreds of duplicate Hourly heartbeat check entries in a single day file. The visible heartbeat cron job remains hourly, but heartbeat-related sessions appear to be re-triggered by local exec completed events. This causes duplicate heartbeat handling and repeated appends to the daily memory file. In one case, memory/2026-03-14.md accumulated 835 Hourly heartbeat check entries, including minute-by-minute overnight entries despite cron history showing only hourly runs.
Environment
OpenClaw: 2026.3.13
Install method: npm global
OS: Linux arm64 (Raspberry Pi)
Kernel: 6.12.62+rpt-rpi-2712
Node: v22.22.1
npm: 10.9.4
Expected behavior
A heartbeat cron job scheduled hourly should:
run once per scheduled interval
perform its checks
optionally run openclaw memory index --verbose
finish without re-entering heartbeat handling
Actual behavior
The visible cron schedule remained hourly, but the daily memory file accumulated minute-by-minute heartbeat entries overnight.
Example:
memory/2026-03-14.md contained 835 Hourly heartbeat check headings
entries ran minute-by-minute overnight, despite cron history showing only hourly heartbeat runs
What I found
I inspected:
cron run history
active and deleted/reset session transcripts
the daily memory file contents
Findings:
The actual heartbeat cron job is still hourly:
schedule: 0 8-21 * * *
timezone: America/Los_Angeles
The duplicate logging is real:
memory/2026-03-14.md had 835 heartbeat-style entries
Deleted/reset heartbeat-related session transcripts show incoming prompts prefixed with:
System: [timestamp] Exec completed (...) Memory Index (main) ...
followed by the normal generic heartbeat prompt.
In those sessions, the agent then proceeds to:
read HEARTBEAT.md
read memory/context files
run more execs
append another heartbeat log entry
This strongly suggests heartbeat-like sessions are being re-entered by their own local exec completion events.
Suspected trigger
The most suspicious step is:
openclaw memory index --verbose
Current hypothesis:
a heartbeat/session turn runs
it launches local exec
the resulting local exec completed event is routed back into a heartbeat/generic session path
that causes another heartbeat-style turn
which appends another heartbeat entry
repeat
Related upstream work
This looks closely related to prior fixes in the same area:
PR #26213 — detect local exec completed / exec failed events in heartbeat prompt
Description says local exec completion events were being missed and fell back to the generic heartbeat prompt, causing misinterpretation of command output and duplicate replies.
PR #31388 — retry session-event runs on failure and pass sessionKey for exec wakes
Review discussion mentions exec completion events possibly still targeting the wrong session if sessionKey is not passed through in all paths.
This report may be:
a regression of that earlier bug family, or
a remaining variant affecting heartbeat sessions that run local execs like memory indexing
Impact
This does not appear to be a cron scheduling bug.
Instead, it causes:
duplicate heartbeat handling
noisy/repeated heartbeat logs
corrupted/useless daily memory files
potential repeated user-facing heartbeat behavior if routing/delivery is enabled
Reproduction (best-effort)
I don’t yet have a minimal repo-level repro, but the observed pattern is:
Have a heartbeat-like task/session that:
reads heartbeat instructions
appends to memory/YYYY-MM-DD.md
runs:
openclaw memory index --verbose
Let the session run in a context where local exec completion wakes are enabled
Observe whether System: Exec completed ... gets injected into a follow-up heartbeat/generic prompt
Observe duplicate heartbeat handling and repeated file appends
Evidence
Cron history:
heartbeat job schedule is still hourly
schedule: 0 8-21 * * *
timezone: America/Los_Angeles
Memory file:
memory/2026-03-14.md contained 835 Hourly heartbeat check headings
Session transcripts:
Incoming prompt contained:
System: [timestamp] Exec completed (...) Memory Index (main) ...
followed immediately by the generic heartbeat prompt.
That session then performed normal heartbeat-style handling again.
Ask
Could you check whether there is still a path where local exec completed events:
fall back to the generic heartbeat prompt, or
wake / re-target the wrong session, especially for heartbeat/session-event flows that call local exec?
My guess is the fix area is somewhere in the overlap of:
local exec completion event classification
wake/session-event routing
sessionKey propagation
heartbeat prompt selection
Steps to reproduce
Reproduction (best-effort)
I don’t yet have a minimal repo-level repro, but the observed pattern is:
Have a heartbeat-like task/session that:
reads heartbeat instructions
appends to memory/YYYY-MM-DD.md
runs:
openclaw memory index --verbose
Let the session run in a context where local exec completion wakes are enabled
Observe whether System: Exec completed ... gets injected into a follow-up heartbeat/generic prompt
Observe duplicate heartbeat handling and repeated file appends
Expected behavior
A heartbeat cron job scheduled hourly should run once per scheduled interval, perform its checks, optionally run openclaw memory index --verbose, and finish without re-entering heartbeat handling or appending duplicate heartbeat log entries.
Actual behavior
The visible heartbeat cron job remains hourly, but heartbeat-related sessions appear to be re-triggered by local exec completed events. This causes duplicate heartbeat handling and repeated appends to the daily memory file. In one case, memory/2026-03-14.md accumulated 835 Hourly heartbeat check entries, including minute-by-minute overnight entries despite cron history showing only hourly runs.
OpenClaw version
2026.3.13
Operating system
OS: Linux arm64 (Raspberry Pi) Kernel: 6.12.62+rpt-rpi-2712
Install method
npm global
Model
openai-codex/gpt-5.4
Provider / routing chain
OpenClaw -> local heartbeat/session flow -> local exec runtime -> exec completion wake/session-event routing If they want a model-style string only, use: openai-codex/gpt-5.4 (main agent)
Config file / key location
~/.openclaw/openclaw.json ; cron configuration for hourly-checks ; agents.defaults.memorySearch.provider
Additional provider/model setup details
This does not appear to depend on the normal chat model route. The main issue seems to be in the local heartbeat/session flow and local exec completion handling, not in upstream model provider routing.
Relevant context:
main agent model: openai-codex/gpt-5.4
local memory indexing uses:
openclaw memory index --verbose
local embeddings provider
the suspected failure path is:
heartbeat/session turn
local exec
local exec completed event
wake/session routing
generic heartbeat prompt re-entry
So the bug appears to live in heartbeat/session-event/exec completion plumbing, not in the model provider chain.
Logs, screenshots, and evidence
Key evidence:
Cron history remains hourly
heartbeat job schedule: 0 8-21 * * *
timezone: America/Los_Angeles
Daily memory file shows duplicate heartbeat logging
memory/2026-03-14.md contained 835 Hourly heartbeat check headings
Deleted/reset session transcripts show exec completion injected into heartbeat-style prompts
Incoming prompt included:
System: [timestamp] Exec completed (...) Memory Index (main) ...
followed by the generic heartbeat prompt.
Those sessions then performed normal heartbeat handling again
read HEARTBEAT.md
read memory/context files
run more execs
append another heartbeat log entry
Related upstream references
PR #26213 — local exec completed / exec failed events falling back to generic heartbeat prompt
PR #31388 — possible wrong-session wake issues when sessionKey is not propagated correctly
Impact and severity
No response
Additional information
No response
Bug type
Regression (worked before, now fails)
Summary
I’m seeing what looks like a remaining or regressed variant of the earlier local exec / heartbeat-routing bugs.
The visible heartbeat cron job is correctly scheduled hourly, but heartbeat-related sessions appear to be re-triggered by local exec completed events, causing duplicate heartbeat handling and repeated appends to the daily memory file.
In practice, this produced hundreds of duplicate Hourly heartbeat check entries in a single day file. The visible heartbeat cron job remains hourly, but heartbeat-related sessions appear to be re-triggered by local exec completed events. This causes duplicate heartbeat handling and repeated appends to the daily memory file. In one case, memory/2026-03-14.md accumulated 835 Hourly heartbeat check entries, including minute-by-minute overnight entries despite cron history showing only hourly runs.
Environment
OpenClaw: 2026.3.13
Install method: npm global
OS: Linux arm64 (Raspberry Pi)
Kernel: 6.12.62+rpt-rpi-2712
Node: v22.22.1
npm: 10.9.4
Expected behavior
A heartbeat cron job scheduled hourly should:
run once per scheduled interval
perform its checks
optionally run openclaw memory index --verbose
finish without re-entering heartbeat handling
Actual behavior
The visible cron schedule remained hourly, but the daily memory file accumulated minute-by-minute heartbeat entries overnight.
Example:
memory/2026-03-14.md contained 835 Hourly heartbeat check headings
entries ran minute-by-minute overnight, despite cron history showing only hourly heartbeat runs
What I found
I inspected:
cron run history
active and deleted/reset session transcripts
the daily memory file contents
Findings:
The actual heartbeat cron job is still hourly:
schedule: 0 8-21 * * *
timezone: America/Los_Angeles
The duplicate logging is real:
memory/2026-03-14.md had 835 heartbeat-style entries
Deleted/reset heartbeat-related session transcripts show incoming prompts prefixed with:
System: [timestamp] Exec completed (...) Memory Index (main) ...
followed by the normal generic heartbeat prompt.
In those sessions, the agent then proceeds to:
read HEARTBEAT.md
read memory/context files
run more execs
append another heartbeat log entry
This strongly suggests heartbeat-like sessions are being re-entered by their own local exec completion events.
Suspected trigger
The most suspicious step is:
openclaw memory index --verbose
Current hypothesis:
a heartbeat/session turn runs
it launches local exec
the resulting local exec completed event is routed back into a heartbeat/generic session path
that causes another heartbeat-style turn
which appends another heartbeat entry
repeat
Related upstream work
This looks closely related to prior fixes in the same area:
PR #26213 — detect local exec completed / exec failed events in heartbeat prompt
Description says local exec completion events were being missed and fell back to the generic heartbeat prompt, causing misinterpretation of command output and duplicate replies.
PR #31388 — retry session-event runs on failure and pass sessionKey for exec wakes
Review discussion mentions exec completion events possibly still targeting the wrong session if sessionKey is not passed through in all paths.
This report may be:
a regression of that earlier bug family, or
a remaining variant affecting heartbeat sessions that run local execs like memory indexing
Impact
This does not appear to be a cron scheduling bug.
Instead, it causes:
duplicate heartbeat handling
noisy/repeated heartbeat logs
corrupted/useless daily memory files
potential repeated user-facing heartbeat behavior if routing/delivery is enabled
Reproduction (best-effort)
I don’t yet have a minimal repo-level repro, but the observed pattern is:
Have a heartbeat-like task/session that:
reads heartbeat instructions
appends to memory/YYYY-MM-DD.md
runs:
openclaw memory index --verbose
Let the session run in a context where local exec completion wakes are enabled
Observe whether System: Exec completed ... gets injected into a follow-up heartbeat/generic prompt
Observe duplicate heartbeat handling and repeated file appends
Evidence
Cron history:
heartbeat job schedule is still hourly
schedule: 0 8-21 * * *
timezone: America/Los_Angeles
Memory file:
memory/2026-03-14.md contained 835 Hourly heartbeat check headings
Session transcripts:
Incoming prompt contained:
System: [timestamp] Exec completed (...) Memory Index (main) ...
followed immediately by the generic heartbeat prompt.
That session then performed normal heartbeat-style handling again.
Ask
Could you check whether there is still a path where local exec completed events:
fall back to the generic heartbeat prompt, or
wake / re-target the wrong session, especially for heartbeat/session-event flows that call local exec?
My guess is the fix area is somewhere in the overlap of:
local exec completion event classification
wake/session-event routing
sessionKey propagation
heartbeat prompt selection
Steps to reproduce
Reproduction (best-effort)
I don’t yet have a minimal repo-level repro, but the observed pattern is:
Have a heartbeat-like task/session that:
reads heartbeat instructions
appends to memory/YYYY-MM-DD.md
runs:
openclaw memory index --verbose
Let the session run in a context where local exec completion wakes are enabled
Observe whether System: Exec completed ... gets injected into a follow-up heartbeat/generic prompt
Observe duplicate heartbeat handling and repeated file appends
Expected behavior
A heartbeat cron job scheduled hourly should run once per scheduled interval, perform its checks, optionally run openclaw memory index --verbose, and finish without re-entering heartbeat handling or appending duplicate heartbeat log entries.
Actual behavior
The visible heartbeat cron job remains hourly, but heartbeat-related sessions appear to be re-triggered by local exec completed events. This causes duplicate heartbeat handling and repeated appends to the daily memory file. In one case, memory/2026-03-14.md accumulated 835 Hourly heartbeat check entries, including minute-by-minute overnight entries despite cron history showing only hourly runs.
OpenClaw version
2026.3.13
Operating system
OS: Linux arm64 (Raspberry Pi) Kernel: 6.12.62+rpt-rpi-2712
Install method
npm global
Model
openai-codex/gpt-5.4
Provider / routing chain
OpenClaw -> local heartbeat/session flow -> local exec runtime -> exec completion wake/session-event routing If they want a model-style string only, use: openai-codex/gpt-5.4 (main agent)
Config file / key location
~/.openclaw/openclaw.json ; cron configuration for hourly-checks ; agents.defaults.memorySearch.provider
Additional provider/model setup details
This does not appear to depend on the normal chat model route. The main issue seems to be in the local heartbeat/session flow and local exec completion handling, not in upstream model provider routing.
Relevant context:
main agent model: openai-codex/gpt-5.4
local memory indexing uses:
openclaw memory index --verbose
local embeddings provider
the suspected failure path is:
heartbeat/session turn
local exec
local exec completed event
wake/session routing
generic heartbeat prompt re-entry
So the bug appears to live in heartbeat/session-event/exec completion plumbing, not in the model provider chain.
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response