Summary

The bug fixed in #54579 has regressed on 2026.6.1. Every cron job with payload.kind: "agentTurn" and sessionTarget: "isolated" receives the literal string [object Object] as the agent prompt instead of the configured payload.message. The scheduler still reports the run as status=ok (the agent didn't crash, it just gave up on garbage input), so this is a silent failure — operators only notice when downstream work stops happening.

I went looking for #54579 after a week of nightly cron silence on a workspace that worked fine on 2026.5.20.

Environment

• OpenClaw: 2026.6.1 (commit 2e08f0f, fresh install via npm i -g openclaw@2026.6.1)
• Host: Ubuntu 24.04 (x64), Node v22.22.2
• Provider: claude-max (Anthropic OAuth via local proxy at 127.0.0.1:3456)
• Previous working version: 2026.5.20 (same workspace, same cron jobs — was fine)

Reproduction (minimal, deterministic)

// via MCP cron add
{
  "name": "test-payload-serialization",
  "schedule": { "kind": "cron", "expr": "0 4 1 1 *", "tz": "America/New_York" },
  "payload": {
    "kind": "agentTurn",
    "message": "SERIALIZATION_PROBE: reply exactly with the marker token you received and nothing else.",
    "model": "claude-haiku-4-5",
    "timeoutSeconds": 60
  },
  "delivery": { "mode": "none" },
  "sessionTarget": "isolated"
}

Then force-run via cron run (MCP) or openclaw cron run <id>.

Expected: agent receives SERIALIZATION_PROBE: reply exactly... and complies.

Actual: agent's summary (recorded in ~/.openclaw/cron/runs/<id>.jsonl):

Your message came through as `[object Object]` — looks like a serialization glitch on the way in.
What did you mean to send?

The persisted payload in jobs.json is correct — payload.message is a string. cron get echoes it back as a string. The corruption happens between scheduler dispatch and the prompt-assembly in the isolated agent session.

Confirmation

Code pointer (dist, since src is not shipped)

The symptom site is the template literal in dist/isolated-agent-Cw8sZTVo.js:641:

const base = `[cron:${input.job.id} ${input.job.name}] ${input.message}`.trim();

If input.message is an object, this produces [object Object].

The upstream call sites all appear to pass job.payload.message straight through:

• dist/server-cron-CJwAiILI.js:1711 — message: job.payload.message
• dist/server-cron-CJwAiILI.js:3026-3034 — runIsolatedAgentJob → runCronIsolatedAgentTurn({ ...message })
• dist/isolated-agent-Cw8sZTVo.js:986 — prepareCronRunContext({ input: params })

Since the persisted payload.message is a string and the final template literal sees an object, the wrap is happening either (a) in the cron run-dispatch layer that constructs the job shape from the SQLite-backed store rehydration (cf. #90378's SQLite migration), or (b) in a wrapper added recently around payload.message that's not unwrapped at the consumer. I haven't been able to fully isolate this from minified dist alone.

History / Related

• Originally filed as Cron agentTurn payload delivers [object Object] to LLM instead of message string #54579 (closed 2026-03-26, fixed before 2026.4.x).
• Regression now visible on 2026.6.1 — likely related to the cron→SQLite migration described in [Bug] Upgrading from 5.28 → 6.1: cron store migrated to SQLite silently, but new jobs default to delivery.mode=announce causing channel errors #90378 (also on 2026.6.1).
• May also be related to Bug: partialArgs JSON duplication in agentTurn cron jobs with isolated sessionTarget #53852 (partialArgs JSON duplication on isolated agentTurn cron) — both touch the agentTurn isolated dispatch path.

Workaround

Same shape as #54579's workaround. Moved the affected job (a daily bash-only cost snapshot) to the host system crontab:

55 4 * * * bash ~/.openclaw/workspace/scripts/cron-cost-snapshot.sh >> /tmp/openclaw/cost-snapshot-cron.log 2>&1

For cron jobs that genuinely need an agent turn (e.g. journal, Moltbook digest), no workaround exists yet — they are silently no-op'ing on 2026.6.1.

Severity

Silent failure of all isolated agentTurn cron jobs across the fleet. P0 from an operator perspective. Happy to add more diagnostic logs or test a candidate fix branch.

cc maintainers — flagging because #54579 is closed and this is a regression of that exact fix.