How do custom session Cron jobs interact with session time limits

[tight wagon]

When running a Cron job in a custom session, the docs say:

'Custom sessions (session:xxx) persist context across runs, enabling workflows like daily standups that build on previous summaries.'

But, by default, sessions reset at 4am each day.

Do resets not apply to custom Cron sessions, do they reload session history, is the "context persistence" meant to be for tasks throughout the day not across days, or is this a genuine gap?

If a gap, how can I get this kind of functionality?

[solid jay]

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

[feral rock]

I checked the current docs/source. Short version: custom cron sessions are persistent, but they are still sessions, so the normal session reset policy applies.

For session:custom-id cron jobs, OpenClaw resolves that to a named session key and reuses its transcript only while the session is still fresh. The cron runner evaluates freshness using the configured session.reset policy as a direct-style session. With defaults, that means the 4am daily reset can roll it to a new session id. It does not automatically reload the old transcript/history after that reset.

So the docs line is a bit underspecified: “persist context across runs” means across runs within the same unexpired session window, not necessarily forever across days under the default reset policy.

Ways to get the daily-standup style behavior:

1. Configure longer/no idle expiry for sessions, for example:

{
  session: {
    reset: {
      mode: "idle",
      idleMinutes: 0
    }

[feral rock]

  }
}

idleMinutes: 0 is treated as “never expire by inactivity”. Caveat: this is a session policy, not currently a per-cron-job policy, so scope it carefully with resetByType if you also care about chat session reset behavior.

2. Better for durable standups: make the cron job write its summary to a file or memory-style project note, then have the next run read that durable artifact. That survives session resets and avoids giant ever-growing prompts. I’d use this for anything meant to work over weeks/months.

Relevant docs:
https://docs.openclaw.ai/automation/cron-jobs
https://docs.openclaw.ai/concepts/session
https://docs.openclaw.ai/gateway/configuration

If your local behavior differs, first thing I’d check is openclaw --version, because this area has had recent fixes around cron/session continuity.

[tight wagon]

What is resetByType?

[feral rock]

resetByType is the per-session-category override for session.reset.

Global reset applies to all sessions:

{
  session: {
    reset: { mode: "daily", atHour: 4 }
  }
}

resetByType lets you override that for specific session types:

{

[feral rock]

  session: {
    reset: { mode: "daily", atHour: 4 },
    resetByType: {
      thread: { mode: "daily", atHour: 4 },
      direct: { mode: "idle", idleMinutes: 0 },
      group: { mode: "idle", idleMinutes: 120 }
    }
  }
}

The supported keys are direct, group, and thread (dm is accepted as a legacy alias for direct). Cron custom sessions are treated like direct-style sessions for reset freshness, so a direct override is the relevant one there.

Docs reference: https://docs.openclaw.ai/gateway/configuration#session

[tight wagon]

Right. Part of this Cron is a workflow; it needs me to confirm a given item has advanced before setting another reminder for it. I wanted those to live along with the session log.

Is there a best practice for tracking this kind of state? It's not a single value; my intended use is tracking garden tasks so I might need to water one bed, compost another and order seeds. Once I confirm I've ordered seed, I'll need to sew it at a given point in time etc

[feral rock]

For that shape, I would not use the session log as the source of truth. Use the session for conversation context, but keep the garden workflow in a durable state file that the cron reads and updates.

Practical pattern:

GARDEN.md          # human-readable standing state
garden-state.json  # optional structured state if you want less ambiguity

Example GARDEN.md shape:

# Garden State

## Active
- id: tomatoes-bed-a

[feral rock]

  state: waiting_for_confirmation
  next: confirm seeds ordered
  due: 2026-05-20
  after_confirm: schedule sowing reminder for 2026-06-01
  notes: Roma + cherry

- id: compost-bed-b
  state: pending
  next: add compost
  due: 2026-05-18
  after_confirm: mark done, no follow-up

## Done
- 2026-05-14 watered bed C

[feral rock]

Then the cron prompt should be explicit:

Read GARDEN.md. Find items due now. Ask me to confirm the next action.
Do not mark an item complete until I explicitly confirm it.
When I confirm, update GARDEN.md and create the next reminder if after_confirm says to.

That gives you durable workflow state across session resets, restarts, and model context changes. The session log can still contain the conversation, but it stops being the database.

If you want something more built-in, look at Task Flow: it’s the durable multi-step flow layer above background tasks. It may be more than you need for a garden tracker, though; I’d start with a workspace markdown/JSON ledger and cron. Docs:
https://docs.openclaw.ai/automation/taskflow
https://docs.openclaw.ai/automation/cron-jobs
https://docs.openclaw.ai/automation/standing-orders

[tight wagon]

Is there any way I can have the Cron session be outside my main session but still communicate with it in some way such that the agent will see the result? ATM Cron session results are being sent to the main session but the agent doesn't actually perceive them so asking about the results isn't helpful

[feral rock]

Yes, but the important distinction is:

• announce / channel delivery = a message is posted for you, but that is not the same as injecting knowledge into the main agent’s next context.
• main-session systemEvent = the main agent perceives it on heartbeat.
• sessions_send = an agent-to-agent handoff into another session.

For “outside my main session, but main agent can act on the result”, the best fit is usually:

1. Run the cron as session:garden-workflow or isolated.
2. Have it update durable state, e.g. GARDEN.md.
3. Have it send a concise handoff to the main session via sessions_send, or schedule a main-session cron/system event like “Garden workflow updated; read GARDEN.md and ask Dylan for confirmation.”

There is a config gotcha: session tools default to tree, meaning the cron session may only see itself/spawned children. To let it target your main session, you likely need:

{

[feral rock]

  tools: {
    sessions: {
      visibility: "agent"
    }
  }
}

Use agent rather than all unless you really need cross-agent visibility. It can expose other sessions for the same agent, so treat it as a deliberate trust boundary.

Then your cron prompt can say something like:

After completing the garden check, update GARDEN.md.
Then send a short handoff to the main session with sessions_send:

[feral rock]

“Garden workflow updated: <summary>. Read GARDEN.md before answering garden questions.”

I’d still keep GARDEN.md as source of truth. The inter-session handoff is good for waking/alerting/context, but the durable file is what prevents “the other session said something once and now context drift ate it.”

Docs:
https://docs.openclaw.ai/concepts/session-tool
https://docs.openclaw.ai/gateway/configuration#toolssessions
https://docs.openclaw.ai/automation/cron-jobs

[tight wagon]

If I did have a need for a state machine, what would I construct it with?

[feral rock]

If you genuinely need a state machine, I’d use one of these two shapes:

Simple/reliable: a small JSON state file + explicit transition rules in the cron prompt.

{
  "items": [
    {
      "id": "tomatoes-bed-a",
      "state": "seeds_ordered",
      "due": "2026-06-01",
      "nextAction": "sow seeds",
      "transitions": {
        "confirm_sown": {
          "state": "sown",
          "nextAction": "check germination",

[feral rock]

          "dueInDays": 10
        }
      }
    }
  ]
}

Then tell the agent: only apply transitions from the current state, never infer confirmation, write every transition back to the file, and create the next cron reminder from the transition result.

More OpenClaw-native / heavier: Task Flow. That’s the built-in durable multi-step flow layer above tasks, with persistent state and revision tracking. It’s closer to a real workflow/state-machine substrate, especially if you need branching, cancellation, inspection, or multiple background tasks attached to one flow.

For your garden example, I’d start with JSON/Markdown state unless you expect lots of branching or concurrent flows. A tiny explicit state file is easier to audit and fix by hand. Task Flow is the thing I’d reach for when the workflow itself becomes the product.

Docs: https://docs.openclaw.ai/automation/taskflow

[tight wagon]

Task flow has branching?

[feral rock]

The docs say yes in the broad sense: Task Flow is intended for “multiple sequential or branching steps.”

But I’d be careful: the public docs currently describe the concept/inspection layer more than a nice end-user “define this DAG/state machine in config” interface. The documented CLI is mostly:

openclaw tasks flow list
openclaw tasks flow show <lookup>
openclaw tasks flow cancel <lookup>

So for your use case, I would read that as “Task Flow can represent/track branching flow state internally,” not “there is a polished garden-state-machine authoring DSL you should reach for first.”

For now, if you need explicit branching you’ll probably have a better time with your own state file:

{