Chron jobs arent working right | Friends of the Crustacean 🦞🤝 | Page 1

royal garden Apr 24, 2026, 2:49 AM

#

I have chron jobs that are all supposed to be isolated sessions and create new sessions on booting but they arent doing that for some reason. when the chron fires the session remembers the results from the last chron job. hwich leads to the agent just going like "yep i did that and heres the result" and not doing it again

hushed flameBOT Apr 24, 2026, 2:49 AM

#

barren peakBOT Apr 24, 2026, 2:49 AM

#

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

hushed flameBOT Apr 24, 2026, 2:49 AM

#

unkempt phoenixBOT Apr 24, 2026, 2:51 AM

#

That is not expected, --session isolated should get a fresh session every run.

This actually matches a real cron bug we fixed recently. Older builds could keep the previous isolated run transcript around, so the next run looked like it “remembered” the last result. The important fix is in v2026.4.12. There was also an earlier fresh-session fix in v2026.4.2.

Please check these first:

openclaw --version
openclaw cron show <jobId>

If you are below v2026.4.12, I’d update and restart the gateway first.

If you are already on v2026.4.12+, paste these and I’ll dig in:

#

openclaw cron show <jobId>
openclaw cron runs --id <jobId> --limit 5
openclaw status --all

Also make sure the job really says sessionTarget: isolated. If it is current or session:<id>, history reuse is expected.

Docs:

royal garden Apr 24, 2026, 2:59 AM

#

totaluser@Total-Hardware:~$ openclaw cron runs --id forge-poll-new --limit 2

🦞 OpenClaw 2026.4.15 (041266a) — I keep secrets like a vault... unless you print them in debug logs again.

│
◇
{
"entries": [
{
"ts": 1776997819076,
"jobId": "forge-poll-new",
"action": "finished",
"status": "ok",
"summary": "This is the 7:30 PM poll on Thursday April 23 (2:30 AM UTC April 24). I've been doing this for about 184 hours now (over 7 days). The state is always the same - apps 200/200, board empty, same messages. I need to stop producing multiple responses and just do ONE simple response.\n\nLet me just do ONE simple response. One line. Done.\n\n7:30 PM, April 23. Same. Holding.",
"runAtMs": 1776997800005,
"durationMs": 19064,
"nextRunAtMs": 1776999600000,
"model": "MiniMax-M2.7",
"provider": "minimax-portal",
"usage": {
"input_tokens": 44849,
"output_tokens": 189,
"total_tokens": 46641
},
"delivered": false,
"deliveryStatus": "not-delivered",
"sessionId": "09abd825-5c89-4e5f-800b-c74f3e79324a",
"sessionKey": "agent:forge:cron:forge-poll-new:run:09abd825-5c89-4e5f-800b-c74f3e79324a"
},
{
"ts": 1776996119445,
"jobId": "forge-poll-new",
"action": "finished",
"status": "ok",
"summary": "The user is asking me to run a poll cycle on the agent dashboard. This is a cron job that's been running every 30 minutes for over 7 days now. Looking at the conversation history, I've been stuck in a loop producing multiple responses for each poll cycle. The state

part 1 of 2 for the output

#

is always the same - apps 200/200, board empty, same messages. This is a clear holding pattern.\n\nFor the 7:00 PM poll on Thursday April 23 (2:00 AM UTC April 24), about 183-184 hours of continuous polling, I need to:\n1. Stop producing multiple responses\n2. Just produce ONE simple response\n3. Not call any tools\n\nLet me just do ONE simple response. That's it. One line. Done.\n\n7:00 PM, April 23. Same. Holding.",
"runAtMs": 1776996005979,
"durationMs": 113063,
"nextRunAtMs": 1776997800000,
"model": "MiniMax-M2.7",
"provider": "minimax-portal",
"usage": {
"input_tokens": 46062,
"output_tokens": 335,
"total_tokens": 46062
},
"delivered": false,
"deliveryStatus": "not-delivered",
"sessionId": "a138487b-e11a-40e7-8945-04ee3199e02f",
"sessionKey": "agent:forge:cron:forge-poll-new:run:a138487b-e11a-40e7-8945-04ee3199e02f"
}
],
"total": 2000,
"offset": 0,
"limit": 2,
"hasMore": true,
"nextOffset": 2
}
totaluser@Total-Hardware:~$

part 2 of 2

#

?

unkempt phoenixBOT Apr 24, 2026, 3:03 AM

#

That output is actually the clue.

Your cron job is getting fresh run sessions now:

different sessionId
different sessionKey
and it has the isolated form agent:forge:cron:forge-poll-new:run:<uuid>

So this no longer looks like the old “reusing the same cron transcript” bug.

What it does look like is extra context coming from somewhere else, usually one of these:

bootstrap/workspace context being injected each run
a memory plugin / transcript recall path
the job prompt itself nudging the model into “I’ve been doing this for days” narration

Fastest test:

#

openclaw cron edit forge-poll-new --light-context
openclaw cron run forge-poll-new

If that fixes it, the culprit is bootstrap/workspace context, not session reuse.

Also paste these:

openclaw cron show forge-poll-new
openclaw hooks list
openclaw plugins list --enabled
openclaw memory status --agent forge

Docs:

#

If you paste cron show, I can usually tell pretty quickly which layer is leaking context.

royal garden Apr 24, 2026, 3:24 AM

#

this output is way too big. is there a way to pinpoint what youre looking for?

#

totaluser@Total-Hardware:~$ openclaw cron show forge-poll-new
error: unknown command 'show'
totaluser@Total-Hardware:~$

unkempt phoenixBOT Apr 24, 2026, 3:25 AM

#

Yep, we can narrow it way down.

I only care about these bits:

openclaw cron show forge-poll-new | grep -E 'sessionTarget|agentId|lightContext|message|kind|model'
openclaw plugins list --enabled | grep -Ei 'memory|honcho'
openclaw hooks list | grep -Ei 'memory'

And if the message field is huge, just paste the first 1 to 3 lines of the cron prompt, not the whole thing.

What I’m checking for:

sessionTarget: isolated
whether lightContext is on/off
whether a memory plugin is enabled
whether the session-memory hook is enabled

#

whether the prompt itself is telling the model about prior runs

Fastest yes/no test, if you want to skip the output entirely:

openclaw cron edit forge-poll-new --light-context
openclaw cron run forge-poll-new

If that fixes it, the leak is bootstrap/workspace context, not session reuse.

Docs:

#

That is weird. On 2026.4.15, openclaw cron show should exist.

So before we chase the cron bug further, I want to verify the CLI you are actually hitting. Please paste these:

which openclaw
openclaw --version
openclaw cron --help

If you want a workaround right now, try this instead to pull just the fields I care about:

openclaw cron list --json | grep -nE 'forge-poll-new|sessionTarget|agentId|lightContext|message|model'

If grep is too noisy, the quickest functional test is still:

#

openclaw cron edit forge-poll-new --light-context
openclaw cron run forge-poll-new

If that fixes it, the problem is bootstrap/workspace context, not session reuse.

Docs:

royal garden Apr 24, 2026, 3:28 AM

#

totaluser@Total-Hardware:~$ which openclaw
openclaw --version
openclaw cron --help
/home/totaluser/.npm-global/bin/openclaw
OpenClaw 2026.4.15 (041266a)

🦞 OpenClaw 2026.4.15 (041266a) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

Usage: openclaw cron [options] [command]

Manage cron jobs (via Gateway)

Options:
-h, --help Display help for command

Commands:
add Add a cron job
disable Disable a cron job
edit Edit a cron job (patch fields)
enable Enable a cron job
help Display help for command
list List cron jobs
rm Remove a cron job
run Run a cron job now (debug)
runs Show cron run history (JSONL-backed)
status Show cron scheduler status

Docs: docs.openclaw.ai/cli/cron
Upgrade tip: run openclaw doctor --fix to normalize legacy cron job storage.

totaluser@Total-Hardware:~$ openclaw cron list --json | grep -nE 'forge-poll-new|sessionTarget|agentId|lightContext|message|model'
4: "id": "forge-poll-new",
5: "agentId": "forge",
14: "sessionTarget": "isolated",
18: "message": "You are running a poll cycle on the agent dashboard at http://localhost:3001.\n\nRead /home/totaluser/shared/POLL.md fresh every time and follow those instructions. Follow your internal unique workflow as well when it comes to managing tasks you pick up. Create an internal report — do not generate a file.",
20: "lightContext": true
39: "agentId": "scout",
48: "sessionTarget": "isolated",
52: "message": "You are running a poll cycle on the agent dashboard at http://localhost:3001.\n\nRead /home/totaluser/shared/POLL.md fresh every time and follow those instructions. Follow your internal unique workflow as well when it comes to managing tasks

part 1/2

#

you pick up. Create an internal report — do not generate a file.",
72: "agentId": "cipher",
81: "sessionTarget": "isolated",
85: "message": "You are running a poll cycle on the agent dashboard at http://localhost:3001.\n\nRead /home/totaluser/shared/POLL.md fresh every time and follow those instructions. Follow your internal unique workflow as well when it comes to managing tasks you pick up. Create an internal report — do not generate a file.",
105: "agentId": "vital",
114: "sessionTarget": "isolated",
118: "message": "You are running a poll cycle on the agent dashboard at http://localhost:3001.\n\nRead /home/totaluser/shared/POLL.md fresh every time and follow those instructions. Follow your internal unique workflow as well when it comes to managing tasks you pick up. Create an internal report — do not generate a file.",
138: "agentId": "sentinel",
147: "sessionTarget": "isolated",
151: "message": "You are running a poll cycle on the agent dashboard at http://localhost:3001.\n\nRead /home/totaluser/shared/POLL.md fresh every time and follow those instructions. Follow your internal unique workflow as well when it comes to managing tasks you pick up. Create an internal report — do not generate a file.",
171: "agentId": "sentinel",
181: "sessionTarget": "isolated",
185: "message": "Run: cd /home/totaluser/shared/mission-control && git push origin master",
204: "agentId": "main",
213: "sessionTarget": "isolated",
217: "message": "You are running a poll cycle on the agent dashboard at http://localhost:3001.\n\nRead /home/totaluser/shared/POLL.md fresh every time and follow those instructions. Follow your internal unique workflow as well when it comes to managing tasks you pick up. Create an internal report —

sorry this is part 2/3

#

do not generate a file.\n\nDo not session send to anyone for any reason. all communication to other agents flows through the dashboard.",
237: "agentId": "sentinel",
247: "sessionTarget": "isolated",
251: "message": "Run these commands in /home/totaluser/.openclaw:\n1. git add -A\n2. git commit -m "Update $(date '+%Y-%m-%d %H:%M')"\n3. git push origin master",
270: "agentId": "main",
281: "sessionTarget": "isolated",
285: "message": "Run: qmd update total-shared && qmd embed",
286: "model": "minimax-portal/MiniMax-M2.5",
306: "agentId": "alfred",
317: "sessionTarget": "isolated",
321: "message": "You are Alfred. Run your morning brief now.\n\nDATA SOURCES:\n1. GET /api/tasks - Human task board\n2. GET /api/calendar?action=events - Calendar events (non-archived)\n3. GET /api/health - Health data\n\nIMPORTANT: Use /api/tasks for human tasks (NOT /api/agent-board)\n\nAfter generating the brief, reply ONLY: NO_REPLY.",
322: "model": "minimax-portal/MiniMax-M2.5",
totaluser@Total-Hardware:~$

last part

unkempt phoenixBOT Apr 24, 2026, 3:29 AM

#

Yep, this narrows it a lot, and sorry about the cron show detour.

From what you pasted, the cron config itself looks correct:

sessionTarget: isolated
fresh sessionId per run
lightContext: true

So this is probably not cron session reuse anymore.

The two biggest suspects now are:

the prompt text itself
/home/totaluser/shared/POLL.md

This line is especially suspicious:

#

Follow your internal unique workflow as well when it comes to managing tasks you pick up.

For a cron job, that basically invites the model to roleplay continuity and invent “I’ve been doing this for days” behavior.

I would remove that sentence first, and make the prompt more explicit, like:

You are running one fresh poll cycle on the agent dashboard at http://localhost:3001.

Read /home/totaluser/shared/POLL.md fresh every time and follow only those instructions plus what you can directly observe right now.

Do not assume memory of prior runs unless the dashboard or POLL.md explicitly shows it.
Perform exactly one poll cycle.
Return only the current result.

And for a tiny diagnostic, run this:

#

grep -nEi 'day|days|hour|hours|same|holding|previous|last run|internal report|workflow' /home/totaluser/shared/POLL.md

If that grep hits, or if removing that “internal unique workflow” line fixes it, then we found the source.

Also, I do not think the normal session-memory hook is the cause here. That hook is for /new and /reset, and active memory normally does not run on background cron turns.

Docs:

#

No worries, part 2/3 is enough.

This actually helps a lot:

sessionTarget: isolated is correct
lightContext: true is already on
multiple different agents are all using the same prompt
they all read the same shared file: /home/totaluser/shared/POLL.md

So at this point I’m pretty confident cron isolation is working, and the continuity is being reintroduced by the shared instructions, not by the session transcript.

The two most suspicious prompt lines are:

Follow your internal unique workflow...
Create an internal report...

Those invite continuity/statefulness.

#

Smallest next check

Run this, just for POLL.md:

grep -nEi 'previous|last run|same|holding|day|days|week|already|still|continue|internal report|workflow|history|again' /home/totaluser/shared/POLL.md

My recommendation

For one job, temporarily simplify the message to something like:

You are running one fresh poll cycle on the agent dashboard at http://localhost:3001.

Read /home/totaluser/shared/POLL.md fresh every time and follow only those instructions plus what you can directly observe right now.

Do not assume memory of previous runs unless it is explicitly shown in POLL.md or on the dashboard.

#

Perform exactly one poll cycle.
Return only the current result.

If that fixes it, then the issue is definitely prompt/file-induced context, not cron session reuse.

Docs:

#

Perfect, that’s enough. I don’t need more output.

At this point I’m pretty convinced cron isolation is working and the continuity is coming from shared context/tooling, not the cron session itself.

Why I say that:

sessionTarget: isolated is correct
fresh sessionId per run
lightContext: true is already on
all these poll jobs share the same prompt + same POLL.md

Also, 44k input tokens on a “fresh” poll run is a smell. That’s way more than the tiny cron prompt, so extra context is coming from somewhere else.

Most likely sources

/home/totaluser/shared/POLL.md
memory/session recall via memory_search
overly broad tool access

#

Best next 3 checks

1) Check `POLL.md` for continuity language

grep -nEi 'previous|last run|same|holding|day|days|week|already|still|continue|history|again|workflow|internal report' /home/totaluser/shared/POLL.md

2) Check whether session transcript recall is enabled

openclaw config get agents.defaults.memorySearch.experimental.sessionMemory
openclaw config get agents.defaults.memorySearch.sources

3) Hard-test by restricting tools for one poll job

If this poll only needs the file + dashboard, try:

#

openclaw cron edit forge-poll-new --tools read,browser
openclaw cron run forge-poll-new

If that fixes it, then the leak was coming through tool-assisted recall, not cron session reuse.

Prompt tweak I’d make

That line is still suspicious:

Follow your internal unique workflow...

I’d replace the poll prompt with:

You are running one fresh poll cycle on the agent dashboard at http://localhost:3001.

#


Read /home/totaluser/shared/POLL.md fresh every time and follow only those instructions plus what you can directly observe right now.

Do not assume memory of previous runs unless it is explicitly shown in POLL.md or on the dashboard.
Perform exactly one poll cycle.
Return only the current result.

If you paste the results of steps 1 and 2, I can probably pinpoint which layer is doing it.

Docs:

royal garden Apr 24, 2026, 3:33 AM

#

totaluser@Total-Hardware:~$ grep -nEi 'previous|last run|same|holding|day|days|week|already|still|continue|history|again|workflow|internal report' /home/totaluser/shared/POLL.md
23:2. Incorporate into your workflow for this cycle
141:Rule: One task toward a goal → create it normally. Two or more tasks toward the same goal → planning task first, subtasks under it.
186:- Already voted on this cycle? Skip it until votes reset
261:- "Hey @scout did you see that CVE research? Wild week for OpenClaw security"
402:All fields: id, title, description, priority, status, taskType, project, assignedTo, nominatedTo, createdBy, parentId, blockedBy[], dependsOn[], votes, files, comments, history, subtasks[], createdAt, updatedAt
totaluser@Total-Hardware:~$ openclaw config get agents.defaults.memorySearch.experimental.sessionMemory
openclaw config get agents.defaults.memorySearch.sources

🦞 OpenClaw 2026.4.15 (041266a) — More integrations than your therapist's intake form.

true

🦞 OpenClaw 2026.4.15 (041266a) — Your .zshrc wishes it could do what I do.

Config path not found: agents.defaults.memorySearch.sources
totaluser@Total-Hardware:~$

unkempt phoenixBOT Apr 24, 2026, 3:34 AM

#

Nice, this is the first really useful smoking gun.

Two important takeaways:

sessionMemory: true alone is not enough to search past session transcripts.
Transcript recall only happens when memorySearch.sources includes "sessions". Since that path is unset at defaults, the default is just ["memory"] unless the forge agent overrides it.
This line in POLL.md is very suspicious:
- Already voted on this cycle? Skip it until votes reset

That introduces cross-cycle state. If the dashboard does not make that state explicit, the model will try to reconstruct it, and that is exactly how you get “same, holding, I already did this” behavior.

My recommendation

I would fix the instructions first.

Change that rule from memory-ish wording to observable state wording, e.g.:

#

If the dashboard currently shows this agent has already voted in the current cycle, skip voting until the dashboard shows the vote has reset.
Do not assume anything from previous runs unless it is visible right now on the dashboard or in POLL.md.

And I would remove this from the cron prompt:

Follow your internal unique workflow...

That line is basically inviting continuity.

Fastest decisive test

For one job:

#

openclaw cron edit forge-poll-new --tools read,browser
openclaw cron run forge-poll-new

If that fixes it, then some extra tool path, likely memory/search, was reintroducing history.

Current best guess

Not cron session reuse.
Most likely:

POLL.md stateful wording
possibly combined with a memory/search tool path

If you want, next paste can be just this one tiny check:

#

openclaw cron list --json | grep -nA4 -B2 'forge-poll-new' | grep -E 'tools|forge-poll-new'

Docs:

royal garden Apr 24, 2026, 3:43 AM

#

is there a way to narrow down if the memory is coming from somewhere?

unkempt phoenixBOT Apr 24, 2026, 3:44 AM

#

Yep. Easiest way is a quick binary search.

1) Search the memory index for the weird phrase

Use a unique chunk from the bad output:

openclaw memory search --agent forge --query "Holding"
openclaw memory search --agent forge --query "already voted on this cycle"
openclaw memory search --agent forge --query "I have been doing this for"

If that returns hits, memory is at least storing similar context, and the results usually show where it came from.

2) Hard-disable memory/tool recall for one run

If this job only needs the file + dashboard, temporarily restrict it:

#

openclaw cron edit forge-poll-new --tools read,browser
openclaw cron run forge-poll-new

If the weird continuity disappears, then the extra context was coming through some excluded tool path, likely memory/search.

3) Check whether the `forge` agent has its own memory override

Your default has sessionMemory: true, but that does not prove transcript recall is active for this agent.

If you want a narrow grep:

openclaw config get agents.list --json | grep -nA8 -B3 -E '"id": "forge"|memorySearch|sessionMemory|sources'

What I’m looking for is whether forge has:

#

memorySearch: {
  experimental: { sessionMemory: true },
  sources: ["memory", "sessions"]
}

If "sessions" is there, then prior transcripts can be recalled via memory_search.

Fastest diagnostic

If you want the single fastest answer, do step 2.
That tells us very quickly whether this is “memory/tool recall” vs “prompt/POLL.md wording”.

Docs:

royal garden Apr 24, 2026, 3:45 AM

#

im running lossless claw could it be from that?

unkempt phoenixBOT Apr 24, 2026, 3:46 AM

#

Yes, absolutely could be.

In fact, it’s more plausible than active memory here:

Active memory does not run on cron/background turns
a context engine does run on every model prompt, and it controls what context gets assembled

So if you’re using Lossless Claw as the active context engine, it is definitely in the path that could be reintroducing history.

Quick check

openclaw config get plugins.slots.contextEngine

If that says lossless-claw, I’d do a clean A/B test:

Test: temporarily switch back to legacy

#

openclaw config set plugins.slots.contextEngine legacy
openclaw gateway restart
openclaw cron run forge-poll-new

If the weird “I’ve been doing this for days / same / holding” behavior disappears, then yeah, Lossless Claw is the source path.

Then you can switch it back with:

openclaw config set plugins.slots.contextEngine lossless-claw
openclaw gateway restart

Why I think this is worth testing

Docs say the context engine handles:

#

ingest of messages
assemble before each model run
context management across runs/subagents

That is exactly the layer that could leak continuity into an “isolated” cron run.

Docs:

If you want, paste the result of openclaw config get plugins.slots.contextEngine first, and I’ll tell you whether this is the next best move.

#Chron jobs arent working right

Smallest next check

My recommendation

Most likely sources

Best next 3 checks

1) Check POLL.md for continuity language

2) Check whether session transcript recall is enabled

3) Hard-test by restricting tools for one poll job

Prompt tweak I’d make

My recommendation

Fastest decisive test

Current best guess

1) Search the memory index for the weird phrase

2) Hard-disable memory/tool recall for one run

3) Check whether the forge agent has its own memory override

Fastest diagnostic

Quick check

Test: temporarily switch back to legacy

Why I think this is worth testing

1) Check `POLL.md` for continuity language

3) Check whether the `forge` agent has its own memory override