#Cronjob Session Pruning

1 messages · Page 1 of 1 (latest)

golden tinsel
#

I have a few cron jobs that run every 5 minutes. They run in isolated sessions. After a week it seems like everything slows down until they are cleared. Is it possible to prune just cron job sessions and retain other chat sessions for much longer?

openclaw sessions | wc -l
203

crude cliffBOT
regal vaporBOT
#

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

crude cliffBOT
orchid barnBOT
#

Yep, that’s possible, and it already has a separate knob.

Use cron.sessionRetention for isolated cron run sessions only. Keep your normal chat/session retention under session.maintenance.

{
  cron: {
    sessionRetention: "6h", // or "1h", "24h", "7d", false to disable
  },

  session: {
    maintenance: {
      mode: "enforce",
      pruneAfter: "60d",
      maxEntries: 1000,
    },
# 
  },
}

A couple important details:

  • cron.sessionRetention only applies to completed isolated cron runs
  • it does not prune normal chat sessions
  • openclaw sessions cleanup is the broader session-store cleanup path, not the cron-specific one
  • cron run logs are separate, via cron.runLog.maxBytes and cron.runLog.keepLines

So for your case, the pattern is:

  • short cron.sessionRetention
  • longer session.maintenance.pruneAfter

If you’re still seeing week-over-week buildup, I’d check these first:

golden tinsel
#

after setting cron.sessionRetention what can i run to force a clean up. or how long do i need to wait to see results?

golden tinsel
#

would that include sub agents the cron spawns? they do not seem to be getting removed.

{
  "key": "agent:main:subagent:49a6a60e-4a4b-4930-87d9-5b4155b8e215",
  "updatedAt": 1776487280012,
  "ageMs": 25249165,
  "sessionId": "b1398fdf-7c61-48b1-9349-4ae3168f817d",
  "abortedLastRun": false,
  "inputTokens": 26984,
  "outputTokens": 108,
  "totalTokens": 13677,
  "totalTokensFresh": true,
  "model": "removed",
  "modelProvider": "removed",
  "contextTokens": 200000,
  "agentId": "main",
  "kind": "direct"
}
orchid barnBOT
#

Right, those are different.

cron.sessionRetention only cleans up cron run session keys, basically keys shaped like:

agent:<id>:cron:<jobId>:run:<uuid>

Your example is:

agent:main:subagent:49a6...

So no, cron.sessionRetention will not remove that.

For subagents, the knobs are:

#
  • agents.defaults.subagents.archiveAfterMinutes
    default is 60
  • cleanup: "delete" on the sessions_spawn call
    which archives the child session immediately after completion

So if your cron jobs spawn helper subagents and you do not need to keep their session rows around, the best option is usually:

{
  agents: {
    defaults: {
      subagents: {
        archiveAfterMinutes: 15
      }
    }
  }
# 
}

or have the spawned subagents use:

cleanup: "delete"

One important caveat from the docs: subagent auto-archive is best effort, and pending archive timers can be lost on a gateway restart. In that case, old subagent rows can linger until broader session.maintenance cleanup catches them.

So short version:

  • cron.sessionRetention → cron run sessions only
  • subagent sessions → archiveAfterMinutes / cleanup: "delete"
  • openclaw tasks maintenance --apply is for task records, not these session rows
golden tinsel
#

The agents.defaults.subagents.archiveAfterMinutes is set to 30 minutes.
but "openclaw sessions" shows hours old sessions

direct agent:main:subag...2e38d0 15h ago minimax/minimax-m2.5 16k/197k (8%) id:46c21ba9-c4a1-4cd2-8596-d82006201dbc
direct agent:main:subag...6fe043 15h ago minimax/minimax-m2.5 16k/197k (8%) id:66ac6b45-2d49-467f-bad0-be2788c878e9
direct agent:main:subag...1f4443 15h ago MiniMaxAI/MiniMax-M2.7 13k/200k (7%) id:d094428a-4a66-4610-b9b6-b4246504e14c

orchid barnBOT
#

Yeah, that explains it.

Based on the current source, archiveAfterMinutes is not a blanket “remove all old subagent sessions from openclaw sessions” knob.

What it appears to do in practice:

  • if the subagent was spawned with cleanup: "delete", it gets a scheduled sessions.delete
  • if it was spawned with cleanup: "keep" (the default), the runtime cleans up its internal run bookkeeping, but the session row stays in sessions.json

So those 15h-old agent:main:subagent:... rows strongly suggest your cron-spawned subagents are being created with the default:

cleanup: "keep"

If you want them to disappear from openclaw sessions, spawn them like this:

# 
{
  cleanup: "delete"
}

So for cron-spawned one-shot helper agents, I’d recommend:

  • keep your parent cron run isolated
  • set spawned subagents to cleanup: "delete"

One more caveat:

  • even with delete-mode, auto-cleanup is still best-effort, and a gateway restart can interrupt pending timers

Also, what version are you on?

# 
openclaw --version

If you want, paste one sessions_spawn(...) call from the cron flow and I’ll tell you exactly what to change.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index it for the next person.

golden tinsel
#

i launch subagents using regular words like this

Launch a subagent with this EXACT task:
"job description listed here" or an md file is passed in

orchid barnBOT
#

Yep, that’s the gap.

If you say only:

Launch a subagent with this EXACT task...

you’re constraining the task text, but not the spawn options.

So the agent will usually do sessions_spawn(...) with the default:

cleanup: "keep"

That means the subagent session row sticks around.

If you want those cron-spawned helpers cleaned up, make the instruction explicit, for example: