#embedded agent issue

1 messages · Page 1 of 1 (latest)

lunar jasper
#

Hi @misty fjord — running 2026.4.25 on Windows/Node 24, upgraded from 4.23 today. Seeing a recurring cascade on cron-triggered embedded agent runs:
[agent/embedded] embedded run agent end: isError=true model=claude-haiku-4-5
error=LLM request rejected: messages: at least one message is required
Happens when a cron fires (e.g. nightly backup at 6 PM) on what appears to be an idle-reset main session. The session has no messages at that point so the API rejects the call, then all fallbacks fail in sequence.
This didn't happen on 4.23. I noticed the 4.25 release notes mention separating "reset freshness from session-store updatedAt so heartbeat, cron, exec, and gateway bookkeeping no longer prevent configured daily/idle resets from rolling." Is there a new default idle reset TTL that wasn't present in 4.23? And is the fix to set isolatedSession: true on the heartbeat/cron, or is there a session reset config I should be setting explicitly?

misty fjordBOT
#

This looks like a 4.25 reset/cron edge-case, not a new default idle TTL.

Short version:

  • No new idle reset TTL: idle reset is optional. Default lifecycle is daily reset at 4 AM gateway-local time unless you configured session.reset.idleMinutes / legacy session.idleMinutes.
  • The 4.25 change means cron/heartbeat/exec bookkeeping no longer keeps sessions fresh, so configured daily/idle resets now actually roll.
  • For a “nightly backup” style job, I’d use isolated cron, not main-session wake:
openclaw cron add \
  --name "Nightly backup" \
  --cron "0 18 * * *" \
  --session isolated \
  --message "Run the nightly backup and report the result." \
  --announce
#

agents.defaults.heartbeat.isolatedSession: true only affects heartbeat runs; it’s not the main fix for cron jobs. For cron, the important bit is --session isolated / sessionTarget: "isolated".

I’d do:

  1. Upgrade to the latest patch after 2026.4.25 if you can.
  2. Run:
openclaw doctor --fix
openclaw gateway restart
openclaw cron list
  1. Check the job is not a legacy/main-session system-event job unless that’s intentional.

If it still reproduces on latest, this is worth a GitHub issue with the redacted cron job record + log lines around cron:<jobId>: https://github.com/openclaw/openclaw/issues

lunar jasper
#

@misty fjord Thanks, that's helpful on the cron side. One follow-up on Pattern 2 and an unanswered question on Pattern 1:
On Pattern 2: Does --session isolated also apply to the heartbeat, or should that be handled separately via agents.defaults.heartbeat.isolatedSession: true? Want to make sure both are covered.
On Pattern 1 — session ending on assistant turn (still unexplained):
This one happened independently of any cron or heartbeat — the session file ends up with a trailing assistant message, session file repaired: rewrote N assistant message(s) fires, but the repair doesn't recover it and the next run hits "does not support assistant message prefill." This cascades through all fallbacks and kills the session entirely.
What's writing incomplete assistant turns to the session file in the first place? Is this a known 4.25 regression on Windows, or is something in our config causing premature session writes? It happened on two different session IDs today across multiple gateway restarts, which suggests it's not a one-off.

misty fjordBOT
#

Yep — separate knobs:

Pattern 2 / cron vs heartbeat

  • --session isolated applies to that cron job only.
  • Heartbeat isolation is separate:
{
  agents: {
    defaults: {
      heartbeat: {
        isolatedSession: true,
        lightContext: true,
      },
    },
  },
# 
}

If your cron is --session isolated, it runs as its own cron agent turn and doesn’t rely on heartbeat. If your cron is --session main --wake now, then it’s enqueueing a main-session event and waking heartbeat, so heartbeat config matters.

Pattern 1 / trailing assistant prefill
That does not sound like normal config. A transcript naturally ends with an assistant message after a completed reply, but strict providers reject that if it gets replayed as a “prefill” without a new user/function turn.

The current changelog has fixes that match this pretty closely:

  • Anthropic: remove trailing assistant prefill payloads with extended thinking.
  • Anthropic/Gemini: strip stale trailing assistant/model prefill turns from outbound replay.

So I’d treat this as a likely 4.25 regression / replay-sanitization bug, not “your config is writing bad turns.”

Also: session file repaired: rewrote N assistant message(s) is narrower than it sounds — it repairs empty assistant error turns on disk. It won’t necessarily remove a valid-looking trailing assistant turn that later becomes an invalid provider prefill.