Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In direct webchat sessions, heartbeat configured with target: "last" is skipped with reason: "no-target", preventing scheduled background execution.

Steps to reproduce

1. Open a direct webchat session in OpenClaw.
2. Configure heartbeat with isolatedSession: true and target: "last".
3. Wait for a heartbeat tick or trigger a manual heartbeat/system wake.
4. Run openclaw system heartbeat last.
5. Observe status: skipped and reason: no-target.

Expected behavior

NOT_ENOUGH_INFO

Actual behavior

In a direct webchat session with heartbeat configured to use target: "last", openclaw system heartbeat last returned status: skipped and reason: no-target, and the heartbeat v2 test state remained unchanged with step-001 still todo.

OpenClaw version

openclaw 2026.4.2

Operating system

Raspberry Pi OS on Raspberry Pi 4, Linux ARM64 (6.12.75+rpt-rpi-v8)

Install method

docker

Model

gpt 5.4

Provider / routing chain

webchat -> OpenClaw gateway

Additional provider/model setup details

• Direct webchat session in OpenClaw
• Heartbeat configured under agents.defaults.heartbeat
• Heartbeat running in isolated light-context mode
• Observed heartbeat config included:
  • every: "1h"
  • activeHours: { start: "08:00", end: "23:00" }
  • lightContext: true
  • isolatedSession: true
  • target: "last"
  • directPolicy: "allow"
• At the time of investigation, the heartbeat model config was set to:
  • model: "anthropic/claude-4-5-20251001"
• Main session metadata showed deliveryContext: { "channel": "webchat" } with no concrete to / lastTo

That keeps it relevant and non-sensitive.

Logs, screenshots, and evidence

### CLI evidence
`openclaw system heartbeat last` returned:


{
  "status": "skipped",
  "reason": "no-target"
}
This was observed both after the scheduled heartbeat window and after a manual wake/system-event test.

Session metadata evidence
Observed main session metadata shape:

Copy
{
  "deliveryContext": {
    "channel": "webchat"
  }
}
Notably, there was no visible concrete to or lastTo.

Heartbeat config used during diagnosis
Copy
{
  "every": "1h",
  "activeHours": {
    "start": "08:00",
    "end": "23:00"
  },
  "model": "anthropic/claude-4-5-20251001",
  "lightContext": true,
  "isolatedSession": true,
  "target": "last",
  "directPolicy": "allow"
}
Workspace / heartbeat evidence
Heartbeat session inspection showed:

heartbeat scheduler/runtime was alive
heartbeat was reading the correct workspace HEARTBEAT.md
heartbeat could read project state files
earlier heartbeat runs successfully updated STATE.yaml
This ruled out:

heartbeat not running
wrong workspace
inability to do file/state work in principle
Actual effect on pilot state
The minimal v2 test state remained unchanged when the no-target skip occurred:

projects/heartbeat-v2-test/STATE.yaml
step-001 remained todo
Runtime code-path evidence
During diagnosis, the heartbeat delivery-target resolution logic was inspected and appeared to require both:

channel
to
Paraphrased condition:

Copy
if (!resolvedTarget.channel || !resolvedTarget.to) {
  return buildNoHeartbeatDeliveryTarget({ reason: "no-target" })
}
Contrasting clue
A manual system event successfully surfaced into the same webchat conversation.

This suggests the issue is specific to heartbeat target resolution rather than total inability to surface messages into the current chat.

Impact and severity

Affected users/systems/channels: observed in a direct webchat OpenClaw session using heartbeat in isolated mode with target: "last". Severity: blocks the intended heartbeat/autonomy workflow in this setup. Frequency: observed repeatedly during this investigation, including scheduled and manual wake tests. Consequence: scheduled heartbeat background execution was skipped with reason: "no-target", and the heartbeat v2 state-transition test did not run.

Additional information

Additional grounded context:

This was investigated on a Raspberry Pi 4 running Raspberry Pi OS / Linux ARM64.
The issue was observed before an update performed on 2026-04-14, but the exact pre-update OpenClaw version/image digest is not confirmed.
Heartbeat runtime itself appeared healthy: sessions existed, the correct workspace HEARTBEAT.md was being read, and earlier heartbeat runs were able to update STATE.yaml.
A separate earlier failure mode was also observed in the older pilot design: a malformed multi-step edit payload while attempting to append a heartbeat activity log. That appears distinct from the later no-target skip.
A manual system event could still surface into the same webchat conversation, which is why the current diagnosis focuses specifically on heartbeat target resolution rather than total chat delivery failure.
No grounded last-known-good or first-known-bad version is available.

Retested after updating to the latest available build on 2026-04-14. The issue still reproduces in the same direct webchat setup: openclaw system heartbeat last still returns status: skipped / reason: no-target, and the heartbeat v2 test state remains unchanged. This also appears inconsistent with the current heartbeat docs, which suggest the run should still happen even if no external delivery target resolves.