openclaw - 💡(How to fix) Fix Recurring post-update/runtime regressions: cron jobs can lose file/shell/mail tools and still report `ok`

Summary

We are seeing a recurring class of runtime regressions in OpenClaw after environment/runtime changes or updates: background/cron jobs lose access to expected local tools, which breaks real work but is not always surfaced clearly by job state.

The latest concrete example was on May 21, 2026 at 12:00 Europe/Berlin in a daily store-tracking job. The run started, but the task could not complete because the cron runtime did not have the expected local file/shell tools and did not have a usable mail path for himalaya.

Why this matters

This does not look like a one-off incident. In historical project memory and prior Telegram operational history, there were repeated issues around:

• gateway reachability
• pairing
• tool availability
• session/runtime differences

So the current failure appears to fit a broader pattern: after changes in OpenClaw/runtime behavior, background execution environments can diverge from the interactive/main session in ways that break automations.

Concrete symptoms from the May 21, 2026 incident

A cron job scheduled for 0 12 * * * (Europe/Berlin) was supposed to:

• read local runbook/state files
• update local state
• send a required email via himalaya

Instead, the run summary reported it was blocked because it could not access:

• local file/shell tools needed to read/write runbook + state
• a usable himalaya mail tool/path

Operationally, that meant:

• no state update
• no email sent
• no generated mail artifact for that day

Additional bug: misleading run status

The most concerning part is that the job state still looked formally successful enough that it would be easy to miss:

• the run summary itself described the task as blocked/incomplete
• but the job state still recorded an ok-style last run status rather than a failure state that would reliably trigger attention

This turns a runtime/tool regression into a silent automation failure.

Expected behavior

If a cron/background job cannot access required execution capabilities that its workflow depends on, OpenClaw should:

1. mark the run as failed or blocked in a machine-visible way
2. surface which required capability was missing
3. make the mismatch between interactive session capabilities and cron runtime capabilities explicit
4. optionally support declarative capability requirements for jobs so unsupported runs fail fast and loudly

Requested improvements

Possible fixes / product directions:

• add explicit capability introspection for cron/job runtimes before execution begins
• let jobs declare required capabilities (filesystem read/write, shell, specific tools like himalaya, web, etc.)
• fail the run with a distinct status if required capabilities are unavailable
• include missing capability diagnostics in jobs-state.json / run metadata
• improve parity guarantees or visibility between main-session and cron-session tool exposure
• add regression coverage for post-update/runtime capability drift

Minimal reproduction pattern

1. Create a cron job that depends on:
   • local file read/write
   • shell access
   • a mail CLI/tool path such as himalaya
2. Let the cron job run in a runtime/session where those capabilities are not exposed
3. Observe that the workflow becomes incomplete, and verify whether the resulting persisted job status clearly indicates failure

Impact

This can break operational automations silently, especially:

• monitoring emails
• scheduled reports
• stateful background tasks
• deployment or maintenance routines

The issue is less about one specific mail job and more about trust in background execution semantics after runtime changes.

Context

This report comes from practical OpenClaw usage over Telegram and local workspace automation, where similar tool/gateway/runtime availability problems have been encountered more than once.