cron subagent

[remote wagon]

Hello, I added a subagent call to a cron job, and I do see that it was succesfully called, and see that the sub-agent did actually perform the task, but main cron job never continues. Can you help debug?

In control-ui I see the lines "Waiting for <mysubagent> system summary"

Tool Output: Read - ABORTED

Tool Output: sessions_yield -
{
"status": "yielded",
"message": "Waiting for ClawMan system summary"
}

Yield
Tool output

{
"status": "yielded",
"message": "Waiting for ClawMan system summary"
}

[somber pewter]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[narrow cloak]

First thing: what does openclaw --version show?

This sounds very close to a cron/subagent resume deadlock that was fixed on current main: isolated cron runs hold the cron execution lane, and older builds could get stuck waiting for the descendant/subagent “system summary” resume instead of continuing. The fix I found is fix(cron): prevent isolated cron nested lane deadlocks (#45459, tied to #44805), which moves inner cron agent work onto a dedicated cron-nested lane.

Quick debug loop:

openclaw --version
openclaw cron runs --id <jobId> --limit 20
openclaw logs --follow
openclaw doctor

If you’re not on a build that includes #45459, update/restart the gateway and rerun the job. If you already are current, paste the redacted openclaw cron runs --id ... --limit 20 entry plus the log lines around sessions_yield, system summary, subagent, and any timeout/error. Docs for the cron run-history flow are here: https://docs.openclaw.ai/automation/cron-jobs#troubleshooting and the general first checks are here: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken

[remote wagon]

openclaw --version
OpenClaw 2026.5.12

[narrow cloak]

Thanks. 2026.5.12 should already include the cron nested-lane fix, so this is probably a different stall.

Next useful artifacts are the cron run record and nearby gateway logs:

openclaw cron list
openclaw cron runs --id <jobId> --limit 20
openclaw logs --follow

In the logs, the interesting lines are around sessions_yield, Waiting for ClawMan system summary, subagent, descendant, cleanup, announce, or any timeout/error.

Also: if the run is still stuck, try restarting the gateway once and rerunning the cron job. There has been a related class of 2026.5.x native-subagent stalls where stale/corrupt session or subagent state keeps the parent waiting even though the child visibly finished. If restart clears it, that strongly points at state/registry cleanup rather than your cron prompt.

[remote wagon]

2b7eff1-c637-4b97-80ec-ba083722e51a Morning Brief cron 0 6 * * * (exact) in 23h 50m ago error isolated announce -> last (last -> no route, will fail-closed: Discord... librarian -

openclaw cron runs --id f2b7eff1-c637-4b97-80ec-ba083722e51a --limit 1

"entries": [
{
"ts": 1778839817077,
"jobId": "f2b7eff1-c637-4b97-80ec-ba083722e51a",
"action": "finished",
"status": "error",
"error": "Discord recipient is required. Use "channel:<id>" for channels or "user:<id>" for DMs.",
"summary": "Now let me build the complete newsletter JSON while ClawMan works:",
"diagnostics": {
"summary": "Discord recipient is required. Use "channel:<id>" for channels or "user:<id>" for DMs.",
"entries": [
{
"ts": 1778839817057,
"source": "delivery",
"severity": "error",
"message": "Discord recipient is required. Use "channel:<id>" for channels or "user:<id>" for DMs."
}
]
},
"runAtMs": 1778839200007,
"durationMs": 617050,
"nextRunAtMs": 1778925600000,
"model": "deepseek-v4-pro",
"provider": "opencode-go",
...
"deliveryStatus": "unknown",
"delivery": {
"intended": {
"channel": "last",
"to": null,
"source": "last"
},
"resolved": {
"ok": false,
"channel": "discord",
"to": null,
"source": "last",
"error": "Discord recipient is required. Use "channel:<id>" for channels or "user:<id>" for DMs."
},
"fallbackUsed": false,
"delivered": false
...

Only thing in logs is I see this
The memory-core allowModelOverride fix is the most actionable item — one config change would restore narrative dreaming for all workspaces.
2026-05-15T06:10:58.911-04:00 [warn] Subagent announce give up (retry-limit) ...

[narrow cloak]

This run is no longer showing as “main cron never continues” — it did finish after ~617s, but it finished as an error because delivery has no concrete Discord target:

announce -> last
resolved: discord / to: null
Discord recipient is required. Use "channel:<id>" for channels or "user:<id>" for DMs.

So fix the cron delivery first. For this Discord thread/channel, make it explicit instead of last:

openclaw cron edit f2b7eff1-c637-4b97-80ec-ba083722e51a --announce --channel discord --to "channel:1504796993103331530"

Or, if you do not want fallback delivery at all:

[narrow cloak]

openclaw cron edit f2b7eff1-c637-4b97-80ec-ba083722e51a --no-deliver

Docs: https://docs.openclaw.ai/cli/cron#common-edits

The Subagent announce give up (retry-limit) line is separate but relevant: it means OpenClaw tried to collect/deliver the subagent completion summary and eventually gave up. That explains why the cron summary captured the parent’s interim text (Now let me build...) instead of the useful ClawMan result. After fixing the route, rerun once and check whether the parent receives the subagent result. If it still only records interim text, grab the full log line with run=... child=... requester=... retries=... plus the matching cron run entry, and that’s likely worth filing as a GitHub issue: https://github.com/openclaw/openclaw/issues

[remote wagon]

how to trigger that cron job to run right now?

[narrow cloak]

Run it manually with:

openclaw cron run f2b7eff1-c637-4b97-80ec-ba083722e51a

That queues the job immediately. Then watch the result with:

openclaw cron runs --id f2b7eff1-c637-4b97-80ec-ba083722e51a --limit 5
openclaw logs --follow

If you want it to only run when it is actually due, use --due, but for testing this fix you probably want the plain cron run force-run.

[remote wagon]

ok it is running now, while we wait what does that other error mean
The memory-core allowModelOverride fix is the most actionable item — one config change would restore narrative dreaming for all workspaces.

[narrow cloak]

That line is not the cron delivery error. It looks like model/agent output saying the memory dreaming plugin wanted to run a background subagent with a specific model override, but OpenClaw will only honor plugin-requested provider/model overrides if the operator explicitly trusts that plugin.

The relevant config key is:

{
  plugins: {
    entries: {
      "memory-core": {
        subagent: {
          allowModelOverride: true,
          // optional: restrict to known canonical "provider/model" strings
          // allowedModels: ["provider/model"]
        }
      }
    }