openclaw - ✅(Solved) Fix Cron tool can bind systemEvent jobs to live chat lanes and delay inbound replies after restart [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#81375Fetched 2026-05-14 03:32:51
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
1
Author
Timeline (top)
commented ×1cross-referenced ×1

A user-facing cron job created from a live chat can default to sessionTarget="main" / payload.kind="systemEvent" and inherit the caller's chat sessionKey. After a gateway or machine restart, missed-job catch-up can then wake the same chat session lane ahead of real user inbound, making WhatsApp appear connected but non-responsive.

This is related to the broader session-lane starvation class in #54488, but the trigger here is the cron tool stamping an implicit main/systemEvent job with a live chat session key.

Root Cause

A user-facing cron job created from a live chat can default to sessionTarget="main" / payload.kind="systemEvent" and inherit the caller's chat sessionKey. After a gateway or machine restart, missed-job catch-up can then wake the same chat session lane ahead of real user inbound, making WhatsApp appear connected but non-responsive.

This is related to the broader session-lane starvation class in #54488, but the trigger here is the cron tool stamping an implicit main/systemEvent job with a live chat session key.

Fix Action

Fixed

PR fix notes

PR #81376: [codex] Fix cron chat session-key binding

Description (problem / solution / changelog)

Summary

Fixes #81375.

  • Stop the cron tool from stamping the caller chat sessionKey onto implicit sessionTarget="main" / payload.kind="systemEvent" jobs.
  • Preserve explicit job.sessionKey and preserve caller-session stamping for isolated agentTurn jobs, where the run-scoped cron session and inferred announce delivery still need that context.
  • Add regression coverage for both paths.

Root Cause / Live Behavior

Observed on 2026-05-13 after a macOS restart with local OpenClaw 2026.5.10-beta.1 (dedc49c):

  • WhatsApp was healthy, linked, connected, and running.
  • A user WhatsApp hi was ingested at 11:08:08 BST (web-inbound, web-auto-reply, and gateway/channels/whatsapp/inbound all logged it), but no visible reply was delivered and typing later timed out.
  • Two due cron jobs created from the same chat were bound to sessionTarget="main", payload.kind="systemEvent", and the WhatsApp direct-chat session key. Startup catch-up put that cron work on the same session lane as the human DM; one job ran from about 11:06:35 to 11:08:39, and the next started immediately afterward.
  • Editing the live jobs to isolated agentTurn + announce delivery removed the lane collision. The WhatsApp channel stayed healthy and later outbound delivery succeeded.

I checked current upstream/latest beta before patching. 2026.5.12-beta.4 includes the adjacent WhatsApp pending-debounce close fix (#81246), and upstream main includes the active-run stuck-lane diagnostic fix (#81302), but neither changes this cron-tool session-key stamping behavior.

Real behavior proof (required for external PRs)

  • Behavior or issue addressed: User-facing cron jobs created from a live WhatsApp chat could inherit that chat's session key as implicit main/systemEvent work, so post-reboot catch-up could occupy the same session lane as a human DM and make WhatsApp appear non-responsive.
  • Real environment tested: macOS OpenClaw gateway using WhatsApp Web, local OpenClaw 2026.5.10-beta.1 (dedc49c), with private phone numbers and JIDs redacted. Inbound smoke source was local wacli using the default authenticated sender store into the OpenClaw PA WhatsApp account.
  • Exact steps or command run after this patch: Applied the same target-state mitigation on the live setup by editing the affected cron jobs to isolated agentTurn jobs with explicit WhatsApp announce delivery, then sent a fresh inbound WhatsApp message through wacli, and checked OpenClaw runtime logs plus channel status.
  • Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):
$ openclaw cron show 4aff489a-e5b4-450f-add0-c2ea03efa8b2
name: Dross aliveness heartbeat
session: isolated
agent: main
delivery: announce -> whatsapp:<redacted-owner> (explicit)
status: ok

$ openclaw cron show 406c58a8-f715-4ed6-b30f-2e29821d45f4
name: Morning calendar reminder setup
session: isolated
agent: main
delivery: announce -> whatsapp:<redacted-owner> (explicit)
status: ok

$ wacli --json --timeout 120s send text --to <redacted-pa-jid> --message "hi - codex wacli live smoke test 20260513T104309Z"
{"success":true,"data":{"id":"3EB03292C2A65E44315BFC","sent":true,"to":"<redacted-pa-jid>"},"error":null}

2026-05-13 11:43:10 BST web-inbound body="hi - codex wacli live smoke test 20260513T104309Z"
2026-05-13 11:43:10 BST web-auto-reply correlationId=3EB03292C2A65E44315BFC
2026-05-13 11:43:10 BST gateway/channels/whatsapp/inbound Inbound message <redacted-owner> -> <redacted-pa> (direct, 106 chars)
2026-05-13 11:43:14 BST gateway/channels/whatsapp/outbound Sending message -> sha256:<redacted>
2026-05-13 11:43:14 BST gateway/channels/whatsapp/outbound Sent message 3EB0E1298C5CBA7AC4A14E -> sha256:<redacted> (198ms)

$ openclaw channels status --json
{
  "accountId": "dross-pa",
  "running": true,
  "connected": true,
  "healthState": "healthy",
  "lastInboundAt": "2026-05-13T10:43:10.783Z",
  "lastOutboundAt": "2026-05-13T10:43:14.944Z"
}
  • Observed result after fix: The affected cron jobs no longer use the live WhatsApp direct-chat lane; they run isolated and announce back to the redacted WhatsApp target. A fresh inbound WhatsApp message sent via wacli was received by OpenClaw and OpenClaw sent a WhatsApp reply about four seconds later.
  • What was not tested: The source patch itself was not installed into the running local OpenClaw gateway; the live system was verified by applying the target-state cron-job mitigation that this patch makes future cron creations default to. Android/WhatsApp UI tap-path testing was not performed because the wacli sender path provided a cleaner real inbound WhatsApp smoke test.
  • Before evidence (optional but encouraged):
2026-05-13 11:08:08 BST web-inbound raw inbound body="hi"
2026-05-13 11:08:08 BST web-auto-reply inbound web message correlationId=3BB9F614B18F07BC09E6
2026-05-13 11:08:08 BST gateway/channels/whatsapp/inbound Inbound message <redacted-owner> -> <redacted-pa> (direct, 58 chars)
2026-05-13 11:09:39 BST [typing] TTL exceeded (60000ms), auto-stopping typing indicator

Verification

  • pnpm test src/agents/tools/cron-tool.test.ts (clean worktree on current origin/main): 81 passed.
  • git diff --check -- src/agents/tools/cron-tool.ts src/agents/tools/cron-tool.test.ts

Changed files

  • extensions/whatsapp/package.json (modified, +0/-1)
  • pnpm-lock.yaml (modified, +2/-103)
  • src/agents/tools/cron-tool.test.ts (modified, +17/-2)
  • src/agents/tools/cron-tool.ts (modified, +15/-1)
  • test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/codex-dynamic-tools.discord-group.json (modified, +1/-1)
  • test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/codex-dynamic-tools.heartbeat-turn.json (modified, +1/-1)
  • test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/codex-dynamic-tools.telegram-direct.json (modified, +1/-1)
  • test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/discord-group-codex-message-tool.md (modified, +4/-4)
  • test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/telegram-direct-codex-message-tool.md (modified, +4/-4)
  • test/fixtures/agents/prompt-snapshots/codex-runtime-happy-path/telegram-heartbeat-codex-tool.md (modified, +4/-4)
RAW_BUFFERClick to expand / collapse

Summary

A user-facing cron job created from a live chat can default to sessionTarget="main" / payload.kind="systemEvent" and inherit the caller's chat sessionKey. After a gateway or machine restart, missed-job catch-up can then wake the same chat session lane ahead of real user inbound, making WhatsApp appear connected but non-responsive.

This is related to the broader session-lane starvation class in #54488, but the trigger here is the cron tool stamping an implicit main/systemEvent job with a live chat session key.

Live behavior observed

Date/time: 2026-05-13, Europe/London.

Environment: local OpenClaw 2026.5.10-beta.1 (dedc49c). I also checked current upstream/latest beta: 2026.5.12-beta.4 includes adjacent WhatsApp debounce/close handling (#81246), and upstream main has a stuck-lane diagnostic fix (#81302), but I did not find a fix for this exact cron/session-key binding path.

Observed after macOS restart:

  • WhatsApp channel status was healthy, linked, connected, and running.
  • Logs showed the user's WhatsApp hi was ingested at 2026-05-13 11:08:08 BST by web-inbound, web-auto-reply, and gateway/channels/whatsapp/inbound.
  • No visible reply was delivered; the typing indicator later timed out.
  • Two due cron jobs from the same chat were bound to sessionTarget="main", payload.kind="systemEvent", and a WhatsApp direct-chat session key. The first catch-up job ran from about 11:06:35 to 11:08:39; the user message arrived while that lane was occupied, and the next catch-up job started immediately after.
  • Editing those jobs to isolated agentTurn jobs with explicit announce delivery removed the live-chat lane collision. The WhatsApp route remained healthy and later outbound sends succeeded.

No phone numbers, JIDs, tokens, or local store paths are included here; the full live evidence was from local logs/config only.

Expected behavior

For user-facing chat reminders, monitors, and check-ins, implicit cron jobs should not bind main/systemEvent work to the live chat session lane. The safe default is an isolated agentTurn with announce delivery unless the caller explicitly requests current-session binding or explicitly supplies a session key.

Proposed fix

A small tool-level guard: when cron.add normalizes an implicit main/systemEvent job, do not stamp the caller chat sessionKey onto it. Preserve explicit job.sessionKey, and preserve caller-session stamping for isolated agentTurn jobs so delivery/session context still works.

Verification

  • pnpm test src/agents/tools/cron-tool.test.ts passes locally.
  • Regression coverage asserts implicit main/systemEvent jobs are not bound to the caller chat session, while isolated agentTurn jobs still receive the caller session key.

Related: #54488, #63864

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

For user-facing chat reminders, monitors, and check-ins, implicit cron jobs should not bind main/systemEvent work to the live chat session lane. The safe default is an isolated agentTurn with announce delivery unless the caller explicitly requests current-session binding or explicitly supplies a session key.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Cron tool can bind systemEvent jobs to live chat lanes and delay inbound replies after restart [1 pull requests, 1 comments, 2 participants]