openclaw - 💡(How to fix) Fix [Feature]: Allow cron agentTurn prompts to load from files [1 participants]

Summary

Allow cron agentTurn jobs to load payload.message from a file instead of requiring the full prompt inline in jobs.json.

Problem to solve

Right now cron jobs require the full payload.message to be embedded as a plain string in the job definition. That gets awkward quickly for larger prompts, especially when jobs are doing non-trivial agent work.

In practice this creates a few problems:

• long prompts are hard to read and maintain inside jobs.json
• prompt edits require rewriting the job definition instead of just editing a file
• prompt text is harder to version, diff, and review cleanly
• it encourages duplicated prompt text across jobs
• repo-based prompt files cannot be treated as the canonical source for scheduled job behavior

Current behavior is workable for short prompts, but for larger recurring workflows it becomes brittle and high-friction.

Proposed solution

Support a file-backed prompt option for cron agentTurn jobs.

A few possible designs:

Option A: explicit file field

Allow something like:

{
  "payload": {
    "kind": "agentTurn",
    "messageFile": "/path/to/prompt.md"
  }
}

Option B: relative file field

Allow repo/workspace-relative paths, for example:

{
  "payload": {
    "kind": "agentTurn",
    "messageFile": "prompts/meeting_intake.md"
  }
}

Option C: inline string with file include semantics

Allow payload.message to accept a file reference format such as @prompts/meeting_intake.md.

My preference would be an explicit field like messageFile because it is clearer and easier to validate.

Expected behavior:

• when the job runs, OpenClaw reads the file contents and uses that as the message
• support either absolute paths or well-defined relative paths
• fail clearly if the file does not exist or cannot be read
• ideally preserve backward compatibility with existing inline message jobs
• ideally define precedence if both message and messageFile are present

Alternatives considered

• Keep embedding the full prompt inline in payload.message
  • works, but becomes hard to maintain for larger jobs
• Keep a short inline prompt that tells the agent to read a file at runtime
  • workable, but indirect and less ergonomic than native support
  • pushes prompt-loading behavior into the agent layer instead of the scheduler config layer
• Use external tooling to regenerate cron jobs whenever prompt files change
  • possible, but unnecessary complexity for something that feels like a natural scheduler capability

Impact

Affected: Users building larger scheduled agent workflows, especially repo-backed knowledge or automation systems Severity: Medium Frequency: Frequent for non-trivial cron jobs Consequence: Extra manual work, harder prompt maintenance, worse diffs/review, and more brittle scheduler configuration

This is especially noticeable when cron jobs are effectively running reusable operational workflows and the actual prompt should live in version-controlled files alongside the repo.

Evidence/examples

Concrete use case: scheduled jobs for a product/docs knowledge system where the prompts are long, frequently edited, and logically belong in versioned repo files.

Examples of jobs where this would help:

• meeting intake / routing jobs
• issue reconciliation jobs
• research consolidation jobs
• weekly knowledge sweep jobs

In these cases the natural source of truth is a prompt file in the repo, but the current cron schema forces the prompt into the job JSON.

Additional information

A native file-backed prompt option would pair well with existing workspace/repo-centric OpenClaw usage.

Even limited support for agentTurn.messageFile would be a big quality-of-life improvement, as long as the behavior is explicit and validation/errors are clear.