OpenClaw’s Isolated-Cron Leak Is the Kind of Bug That Makes Agent Automation Feel Haunted

The fastest way to make an automation platform feel cursed is to let background work speak in the wrong voice. OpenClaw’s isolated-cron report from April 26 hits exactly that nerve. Issue #72141 says a cron job configured with sessionTarget=isolated produced output that closely mirrored the parent session’s most recent assistant reply. Then a later run emitted REPLY_SKIP, and the parent session received an inter-session message it treated as new user input. If that description is accurate, this is not just a quirky scheduler bug. It is the sort of context leak that makes operators stop trusting the platform’s mental model.

The report was opened at 11:50:32 UTC against OpenClaw 2026.4.23 on Ubuntu 24.04 ARM64. The setup matters because it sounds ordinary: a parent session on Telegram, a cron job using payload.kind=agentTurn, sessionTarget=isolated, agentId=main, and model google/gemini-3-flash-preview. In other words, not a weird lab experiment. Exactly the kind of automation path users reach for when they want recurring work to happen away from the main transcript. The observed cron output reportedly began with “Recibido, Juli. Confirmo el diagnóstico:” and then restated the parent session’s prior diagnostic content nearly verbatim. That alone is unsettling. The later routing weirdness makes it worse.

One detail in the issue jumps off the page: openclaw cron list reportedly showed sessionKey: agent:main:main even for jobs configured with sessionTarget=isolated. That is the sort of artifact that turns a strange reply into an architectural suspicion. If the scheduler is resolving or persisting the same session key it uses for the parent context, then “isolated” may be a label attached too late in the pipeline, or a promise that one layer believes and another quietly overrides. The reporter explicitly points to the runtime expectation that resolveCronSession({ forceNew: input.job.sessionTarget === "isolated" }) should guarantee isolation. The system behavior, as reported, suggests that guarantee is not holding.

This matters because context boundaries are the real product in agent automation. Users will forgive a cron that fails. They will forgive a cron that runs late. They might even forgive a cron that needs a retry. What they do not forgive is a cron that appears to have inherited private transcript state it was not supposed to see, then replies with borrowed language in a place that muddies authorship. That is how software starts feeling haunted. Not because it is intelligent, but because it becomes hard to say which process knew what and when.

There is a same-day adjacent report in issue #72151 about async exec completion replies escaping their originating Slack thread. Pair that with the older cron bookkeeping lineage around issue #71547, and a pattern emerges. OpenClaw is doing the hard work of background execution, but the delivery and isolation semantics are still sharp edges. Different bugs, same anxiety: when work happens off to the side, can the platform prove which context owns the result?

That proof requirement is more important than a lot of agent companies seem willing to admit. The category loves talking about autonomy, but autonomy is only tolerable when context partitioning is boringly reliable. Once you add recurring jobs, isolated sessions, spawned workers, multi-channel delivery, and persistent memory, every boundary becomes a systems problem. Transcript inheritance, session-key allocation, delivery-context preservation, and event routing all need explicit tests. “Should be isolated” is not an implementation detail. It is a contract.

For practitioners, the immediate advice is cautious but practical. If you rely on OpenClaw cron jobs for anything sensitive or anything where context provenance matters, audit them like you would audit access control. Verify the configured sessionTarget, inspect the resolved session key, and compare actual outputs against the expected prompt boundary. If a background job feels a little too aware of the main conversation, assume that instinct is worth investigating. Also, prefer narrow prompts and narrowly scoped tools for background jobs until the isolation story is more battle-tested. Good boundaries start with product design, but operators can still reduce blast radius.

There is a deeper industry lesson here too. Background agents are quietly becoming job schedulers with personality attached. That means they inherit scheduler obligations plus conversational obligations. Traditional schedulers have to prove which job ran where, with what inputs, and what output it produced. Agent schedulers have to do all of that while also preserving authorship, thread identity, and prompt isolation. The control-plane burden is heavier than many teams realize. That is why bugs like this are more revealing than benchmark charts. They show where the real engineering load lives.

OpenClaw deserves some credit for getting far enough into real use that these issues surface concretely. This is not a vague “AI got weird” anecdote. The report includes version details, reproduction settings, observed text, session-key evidence, and explicit expectations from the code path. That is the kind of operational bug report a platform can actually learn from. But the lesson should land hard: isolation claims in agent systems have to be earned through relentless boring correctness, not optimistic naming.

My view is simple. This issue is nominally about one misbehaving cron. The real story is that session isolation is now one of the most important trust primitives in agent infrastructure. If OpenClaw wants users to schedule recurring research, digests, follow-ups, and delegated work with confidence, it has to make “isolated means isolated” feel dull and unquestionable. Right now, reports like this say it is not there yet. That is fixable. But it is not cosmetic.

Sources: OpenClaw issue #72141, OpenClaw v2026.4.23 release, issue #71547, issue #72151