openclaw - 💡(How to fix) Fix `cron run` manual trigger doesn't faithfully reproduce the scheduled execution environment [1 participants]

Summary

Running cron run <job> manually (for testing/debugging) behaves differently from the scheduled run. Observed differences include working directory, environment variables, and session context loading. This makes cron bugs hard to reproduce on a fresh shell — you can't trust that "it works when I run it manually" matches the scheduled behavior.

Observed in

• macOS deployment (Mac Mini, LaunchAgent-scheduled cron jobs)
• Windows deployment (Task Scheduler-equivalent)
• Originally noted against v2026.2.26; same pattern persists in our deployment notes through current versions, though this issue may already be partially addressed by recent cron work that I haven't tested against.

Examples of divergence

1. Working directory. Scheduled run starts in the agent workspace. Manual run starts in the shell's cwd.
2. Environment. Scheduled run inherits LaunchAgent/service-level env (minimal PATH, no terminal-set vars). Manual run inherits the interactive shell env, including any direnv / shell aliases / PATH overrides.
3. Context file loading. Scheduled run loads agents.md / soul.md / heartbeat context per the cron schedule policy. Manual run sometimes skips heartbeat context and loads a different combination.

The third one is the most painful — a manual cron run "passing" doesn't necessarily mean the scheduled run will load the same context.

Suggested fix

Either default behavior or an explicit flag (cron run --as-scheduled) that faithfully reproduces the scheduled execution environment:

• chdir to the agent workspace
• Reconstruct the env using the same logic the scheduler uses
• Load the same context files in the same order, including heartbeat

This would make cron debugging substantially easier and turn manual cron run into a true "what would happen at the scheduled time" preview.

Severity

Low-Medium. It's a developer-experience issue, not a production correctness issue, but it's a recurring source of "why did this work in testing but not in prod" confusion.

Note

Lots of recent cron work (#69285, #67807, #63105, etc.) has improved the cron infrastructure substantially. If any of that already addresses this, please point me at it and I'll update our internal docs accordingly.