Summary

OpenClaw cron tool works in the main session, but appears unavailable or mis-routed when a cron job itself runs as an isolated cron agent and tries to inspect cron state.

This breaks self-health-check jobs that are supposed to use the platform cron tool to inspect other cron jobs.

Repro shape

We had a cron-health-check job whose purpose was:

• list all cron jobs with the OpenClaw cron tool
• flag consecutiveErrors > 0, lastRunStatus = error, or lastErrorReason = timeout
• also check VPS health + sandbox process health

The exact same conceptual check behaves differently depending on execution lane:

Main session / normal chat

Using the OpenClaw cron tool from the main session works. We can successfully list jobs and inspect their state.

Isolated cron agent

When the health-check job runs as sessionTarget: "isolated", it fails to access cron state. Observed failure modes across runs included:

• cron: not found
• openclaw command not found
• generic “cron 状态未成功取到” summaries

This happened even after tightening the prompt to explicitly say:

• use the OpenClaw cron tool
• do not inspect local files
• do not run shell commands like cron or openclaw cron

We also tried:

• openai-codex/gpt-5.4-mini with thinking=medium
• openai-codex/gpt-5.4-mini with thinking=high
• anthropic/claude-sonnet-4-6

The isolated path still failed.

Strong evidence this is not just prompt/model error

We then changed the job from:

• sessionTarget: "isolated"
• payload.kind: "agentTurn"

to:

• sessionTarget: "main"
• payload.kind: "systemEvent"

So the scheduled reminder enters the main session, and the main-session agent performs the cron check there.

After that change, the same health-check workflow worked again.

That strongly suggests:

• the OpenClaw cron tool itself is fine
• the main session can access/use it
• but isolated cron-agent runs cannot reliably access it, or are silently falling back to shell-command behavior instead of real tool calls

Why this matters

This prevents a very natural self-monitoring pattern:

• cron job A checks cron jobs B/C/D using the platform cron tool

Right now, that pattern appears broken specifically in isolated cron-agent execution.

Expected behavior

If the OpenClaw cron tool is available in normal agent contexts, isolated cron-agent runs should either:

1. also receive the cron tool and be able to use it normally, or
2. fail explicitly at tool availability/planning time with a clear capability error

They should not degrade into trying shell commands like cron / openclaw.

Current workaround

We changed the health-check job to run as:

• sessionTarget: main
• payload.kind: systemEvent

This works, but it is a workaround, not a fix.

Request

Could maintainers confirm whether this is an intentional restriction or a regression?

If intentional, it would help to document clearly that isolated cron-agent runs cannot use the platform cron tool.

If not intentional, this seems like a real bug in isolated cron-agent tool availability / tool routing.