fix(cron): condition requireExplicitMessageTarget on resolved delivery by Anandesh-Sharma · Pull Request #28017 · openclaw/openclaw

Anandesh-Sharma · 2026-02-26T23:10:38Z

Summary

Fixes "Action send requires a target" errors when a cron job's delivery target resolution fails
requireExplicitMessageTarget was unconditionally set to true for all cron isolated agent runs
Now conditioned on deliveryRequested && resolvedDelivery.ok so the agent isn't blocked by a target that was never resolved

Root Cause

In src/cron/isolated-agent/run.ts:469, the requireExplicitMessageTarget flag was hardcoded to true. When resolveDeliveryTarget() returns { ok: false } (e.g. missing session history, no configured channel), the embedded PI agent still enforced the explicit target requirement on its message tool, producing the "Action send requires a target" error.

Fix

Condition the flag on both deliveryRequested (delivery was actually requested in the cron job payload) AND resolvedDelivery.ok (the target was successfully resolved). When either condition is false, the agent can use messaging tools without the explicit target constraint.

Test plan

Verify cron jobs with valid delivery targets still enforce explicit message targets
Verify cron jobs without configured delivery (or failed resolution) no longer produce "send requires a target" errors
Verify disableMessageTool is still correctly set based on deliveryRequested

Fixes #27898

🤖 Generated with Claude Code

When a cron job's delivery target resolution fails (resolvedDelivery.ok is false), the agent was still started with requireExplicitMessageTarget: true. This caused "Action send requires a target" errors because the agent's message tool demanded a target that was never resolved. Condition the flag on both deliveryRequested AND resolvedDelivery.ok so the agent can still use messaging tools freely when no valid delivery target exists. Fixes openclaw#27898 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

greptile-apps · 2026-02-26T23:13:56Z

Greptile Summary

This PR fixes a bug where cron jobs without configured delivery targets (or with failed target resolution) would produce "Action send requires a target" errors. The fix changes requireExplicitMessageTarget from being unconditionally true to being conditioned on both deliveryRequested && resolvedDelivery.ok.

Changed requireExplicitMessageTarget logic on line 472 to only enforce explicit message targets when delivery is both requested and successfully resolved
Added clear comment explaining the fix and referencing issue Cron jobs: Message delivery fails with 'Action send requires a target' #27898
The logic correctly handles three scenarios: (1) no delivery requested - agent can use message tool freely, (2) delivery requested with successful resolution - explicit target enforced, (3) delivery requested but resolution failed - no explicit target required since delivery would fail anyway

Confidence Score: 5/5

This PR is safe to merge with minimal risk
The change is a simple, well-reasoned conditional fix that addresses a specific bug. The logic is sound - requiring an explicit message target only when both delivery is requested AND the target was successfully resolved. The code includes a clear explanatory comment and the change is minimal (single line of logic). No breaking changes or side effects are introduced.
No files require special attention

_{Last reviewed commit: cf748e6}

openclaw#28017) When a cron job's delivery target resolution fails (resolvedDelivery.ok is false), the agent was still started with requireExplicitMessageTarget: true. This caused "Action send requires a target" errors because the agent's message tool demanded a target that was never resolved. Condition the flag on both deliveryRequested AND resolvedDelivery.ok so the agent can still use messaging tools freely when no valid delivery target exists. Fixes openclaw#27898 Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

@Lukavyi

* main: (31 commits) fix(browser): resolve correct targetId in navigate response after renderer swap (openclaw#25326) fix: sed escaping and UID mismatch in Podman Quadlet setup (openclaw#26414) fix(cron): pass heartbeat target=last for main-session cron jobs (openclaw#28508) (openclaw#28583) fix(cron): disable messaging tool when delivery.mode is none (openclaw#21808) (openclaw#21896) fix: clear delivery routing state when creating isolated cron sessions (openclaw#27778) fix(cron): avoid marking queued announce paths as delivered (openclaw#29716) fix(cron): enable completion direct send for text-only announce delivery (openclaw#29151) fix(cron): force main-target system events onto main session (openclaw#28898) fix(cron): condition requireExplicitMessageTarget on resolved delivery (openclaw#28017) feat(cron): add --account flag for multi-account delivery routing (openclaw#26284) fix: schedule nextWakeAtMs for isolated sessionTarget cron jobs (openclaw#19541) fix: sandbox browser docker no-sandbox rollout (openclaw#29879) (thanks @Lukavyi) GitHub: add regression bug issue template and routing (openclaw#29864) thanks @Takhoffman feat(feishu): add chat info/member tool (openclaw#14674) feat(feishu): add markdown tables, positional insert, color_text, and table ops (openclaw#29411) feat(feishu): add parent/root inbound context for quote support (openclaw#18529) fix: land android onboarding and voice reliability updates (openclaw#29796) fix(android-voice): rotate playback token per assistant reply fix(android-voice): retry talk config after transient failures fix(android-voice): cancel in-flight speech when speaker muted ...

openclaw#28017) When a cron job's delivery target resolution fails (resolvedDelivery.ok is false), the agent was still started with requireExplicitMessageTarget: true. This caused "Action send requires a target" errors because the agent's message tool demanded a target that was never resolved. Condition the flag on both deliveryRequested AND resolvedDelivery.ok so the agent can still use messaging tools freely when no valid delivery target exists. Fixes openclaw#27898 Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Resolved conflicts: - CHANGELOG.md: take upstream release notes - extensions/feishu/src/{channel,reply-dispatcher,send}.ts: take upstream (community replyInThread impl supersedes ours, PR openclaw#27325) - src/agents/compaction.ts: merge timing logs with upstream identifier preservation + buildCompactionSummarizationInstructions - src/agents/pi-extensions/compaction-safeguard.ts: merge timing logs with upstream summarizationInstructions param - src/cron/isolated-agent/run.ts: merge upstream requireExplicitMessageTarget condition (openclaw#28017) + disableMessageTool none-mode (openclaw#21896) with our ownerNumbers + senderIsOwner additions Post-merge fixes: - Restore DEFAULT_CONTEXT_TOKENS import in attempt.ts (auto-merge dropped it) - Adjust memory flush test to match our cache-stable systemPrompt design (flush instructions in user prompt, not extraSystemPrompt)

openclaw#28017) Cherry-pick from upstream openclaw/openclaw 2851926. When delivery target resolution fails, the agent is no longer blocked by an explicit target requirement it cannot satisfy. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

openclaw#28017) When a cron job's delivery target resolution fails (resolvedDelivery.ok is false), the agent was still started with requireExplicitMessageTarget: true. This caused "Action send requires a target" errors because the agent's message tool demanded a target that was never resolved. Condition the flag on both deliveryRequested AND resolvedDelivery.ok so the agent can still use messaging tools freely when no valid delivery target exists. Fixes openclaw#27898 Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

openclaw#28017) Cherry-pick from upstream openclaw/openclaw 2851926. When delivery target resolution fails, the agent is no longer blocked by an explicit target requirement it cannot satisfy.

openclaw#28017) When a cron job's delivery target resolution fails (resolvedDelivery.ok is false), the agent was still started with requireExplicitMessageTarget: true. This caused "Action send requires a target" errors because the agent's message tool demanded a target that was never resolved. Condition the flag on both deliveryRequested AND resolvedDelivery.ok so the agent can still use messaging tools freely when no valid delivery target exists. Fixes openclaw#27898

openclaw#28017) When a cron job's delivery target resolution fails (resolvedDelivery.ok is false), the agent was still started with requireExplicitMessageTarget: true. This caused "Action send requires a target" errors because the agent's message tool demanded a target that was never resolved. Condition the flag on both deliveryRequested AND resolvedDelivery.ok so the agent can still use messaging tools freely when no valid delivery target exists. Fixes openclaw#27898 Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

openclaw-barnacle bot added the size: XS label Feb 26, 2026

Takhoffman mentioned this pull request Feb 28, 2026

fix(cron): only require explicit message target when delivery is requested #28002

Closed

3 tasks

Takhoffman merged commit 2851926 into openclaw:main Feb 28, 2026
28 checks passed

github-actions bot mentioned this pull request Feb 28, 2026

📡 Upstream Digest — 2026-02-28 18:22 UTC curtismercier/openclaw-mods#147

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(cron): condition requireExplicitMessageTarget on resolved delivery#28017

fix(cron): condition requireExplicitMessageTarget on resolved delivery#28017
Takhoffman merged 1 commit intoopenclaw:mainfrom
Anandesh-Sharma:fix/cron-send-requires-target-27898

Anandesh-Sharma commented Feb 26, 2026

Uh oh!

greptile-apps bot commented Feb 26, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Anandesh-Sharma commented Feb 26, 2026

Summary

Root Cause

Fix

Test plan

Uh oh!

greptile-apps bot commented Feb 26, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants