OpenClaw merged a P1 cron fix this morning for a nasty interaction between scheduled jobs, existing chat sessions, subagents, and memory access.
PR #166417, "fix(cron): subagents lose memory access when a cron job runs in their parent chat," addresses a case where a scheduled check-in could make already-spawned child agents lose access to Knowledge and other memory-slot tools.
The failure mode was especially awkward because the cron job did not have to reset the session intentionally. A cron run targeting an existing conversation could rotate the parent session's lifecycle revision. Existing subagents still held the old parent revision, so later memory calls failed with an authority error until the subagent was respawned.
What Users Saw
The PR describes a live failure on a main Gateway: a five-minute check-in cron job targeted a dashboard session, rotated that session's revision, and left all eight previously spawned subagents unable to call Knowledge. Their calls were denied with a trusted-agent or trusted-session authority error.
That matters because cron is often used for recurring background work inside the same long-lived conversation:
- Morning or evening status checks
- Project watchers
- Inbox or calendar scans
- Scheduled summaries
- Periodic agent workflows that depend on prior context
Those workflows should not silently invalidate the child agents that the parent conversation already trusts.
What Changed
OpenClaw now keeps the existing lifecycle revision when a cron run reuses a live session in place. A new revision is still minted for cases that genuinely represent a new incarnation: new sessions, stale resets, forced rollovers, different source sessions, rows without a revision, and exact-run cron: sessions.
For exact-run cron sessions, the run happens in a hidden :run: row while continuation ownership and superseded-base checks use the base revision as the per-run generation.
The fix also tightens persistence ownership. Because reused sessions now share a revision with other writers, OpenClaw requires the session id of the run's last committed row. A same-revision session-id replacement is rejected rather than adopted.
Why This Matters
Memory access in OpenClaw is authority-sensitive for good reasons. A child agent should not inherit memory access across a real parent reset, and the PR keeps that behavior. The bug was that an ordinary in-place cron run looked like a reset to the owners responsible for memory audience leases.
The improved behavior is more precise: reuse keeps lineage; real resets still revoke it.
That distinction is important for users building persistent agent workflows. Cron should be a way to add scheduled motion to an existing conversation, not a background event that accidentally severs the conversation's children from their memory scope.
Evidence From the PR
The after-fix proof used a fresh dashboard session and a spawned subagent. The subagent successfully called knowledge_status, then a cron job ran in the parent session and replied. The parent revision stayed the same, and the same child could call knowledge_status again with no memory-audience denial.
As a control, the authors reset the parent session. That minted a new revision, and the old child was then correctly denied memory access.
The test suite adds coverage for in-place reuse, fresh sessions, stale sessions, forced rollovers, differing source sessions, revision-less rows, and exact-run cron sessions. The changed cron isolated-agent tests passed, including a 519-test run across 45 files.
Bottom Line
This fix makes cron safer for long-lived OpenClaw workspaces. Scheduled jobs can now run inside an existing chat without making the chat's subagents look untrusted, while real resets still draw the right authority boundary.