OpenClaw Cron Bug: agentTurn Jobs May Send [object Object] to the LLM Instead of Your Prompt

A newly reported cron regression means some agentTurn jobs may deliver [object Object] to the LLM instead of the prompt text you actually configured.

That creates a very specific failure mode:

• the cron job exists correctly
• the stored message string is correct
• the run still fires
• but the model responds to the serialization artifact instead of your intended instruction

Source:

• Issue report: openclaw/openclaw#54579

What this bug looks like in practice

The issue report describes a job configured with a message like:

• Say: HELLO WORLD

But when the job runs, the summary and model behavior point to [object Object] instead of the expected message string.

That strongly suggests the configured job payload is being transformed incorrectly somewhere between:

1. the cron job definition stored on disk
2. the cron execution pipeline inside the Gateway
3. the final LLM request construction

Why this matters

This is not a cosmetic output glitch.

If you rely on cron-driven agent workflows, the impact can be much larger:

1. Scheduled automations stop doing the right work

   • reminders, digests, cleanup jobs, and reporting prompts may all run with corrupted instructions.

2. You may think the model is failing when the real failure is serialization

   • switching providers or changing prompts will not help if the cron payload is already malformed before the API call.

3. Cross-symptom confusion gets worse

   • the same report also mentions Telegram DM responses showing “typing” but not delivering a final answer, which may share the same execution-path defect.

How to confirm you are hitting the same regression

You are likely seeing the same issue if all of the following are true:

• your cron payload type is agentTurn
• the configured prompt text in the job definition is correct
• the job runs, but the output clearly reflects [object Object] or behaves as if the prompt was lost
• changing model/provider does not fix it

A minimal verification loop:

1. Create a one-purpose cron job whose message is unmistakable.
2. Use a prompt like: Reply with exactly: HELLO WORLD.
3. Trigger the job immediately.
4. If the result references [object Object] or ignores the expected string entirely, the cron message is likely being serialized incorrectly.

What the issue report already ruled out

The original reporter tested a surprisingly wide blast radius and still saw contamination:

• clearing agent sessions
• disabling channels
• disabling plugins
• disabling hooks
• changing models
• moving to a clean workspace

Most importantly, the report says the stored job definition still contained the correct string message.

That narrows the likely fault domain to the Gateway cron execution path, not the model provider and not the job authoring step.

Temporary workarounds

1) Move critical scheduled jobs out of cron agentTurn for now

If the task is operationally important, avoid relying on agentTurn cron payloads until the bug is fixed.

2) Prefer direct external schedulers for must-run tasks

The issue reporter used a temporary workaround based on:

• launchd for scheduling
• direct CLI invocation for the model step
• openclaw message send for delivery

On Linux, the equivalent idea would be a system scheduler plus an explicit script path.

3) Reduce ambiguity in your test prompts

Use prompts with deterministic output like:

• Reply with exactly: HELLO WORLD
• Return only the word OK

That makes corruption much easier to detect than long natural-language prompts.

What maintainers will likely need to inspect

Based on the current evidence, the likely inspection points are:

• cron job payload deserialization
• conversion from cron payload object to agent/session request
• LLM request assembly for agentTurn runs

That is still a technical hypothesis, not a confirmed root cause.

What to include in a useful bug follow-up

If you want to help this get fixed faster, include:

• OpenClaw version and commit hash
• the exact cron payload type used
• the literal configured message string
• whether the job definition on disk still shows the correct string
• whether the same prompt works outside cron
• whether multiple model providers show the same corruption

Split the cron payload path into four checkpoints before fixing it

When the LLM receives [object Object], do not only inspect the prompt. First narrow the path with four checkpoints:

1. Cron trigger layer: record the job name, trigger time, and whether this was a retry or concurrent fire, so duplicate delivery is visible.
2. agentTurn input layer: preserve the raw payload passed into agentTurn, especially whether message, content, or input is a string or an object.
3. Serialization layer: determine whether the object became a string inside the cron wrapper or only right before the LLM adapter.
4. Side-effect layer: mark whether the cron already sent messages, wrote external APIs, committed code, or triggered deployment, so the same work is not replayed after the fix.

These four checkpoints turn “the model behaved strangely” into a concrete data-shape regression, and help readers decide whether the fix belongs in the cron entrypoint, the agentTurn contract, or the adapter input guard.

Run three regression checks before re-enabling cron jobs

Even after a patch removes [object Object], do not restore every production cron immediately. Run three small checks first:

1. Re-test the same job definition: keep the original job shape, change only the message to Reply with exactly: HELLO WORLD, and verify the Gateway passes a string into the LLM.
2. Shadow-run the real task: copy the production prompt into a job that cannot write external systems, then compare the summary, delivery path, and logged payload.
3. Re-enable in batches: restore read-only checks or reminders first, then bring back jobs that send messages, write APIs, commit code, or trigger deployment.

This prevents a serialization fix from becoming a second wave of side effects. For readers searching cron agentTurn [object Object] fixed but should I re-enable jobs, the key question is not only whether the patch landed, but whether every scheduled run now receives the intended string.

Source

• openclaw/openclaw#54579