openclaw - 💡(How to fix) Fix [Bug]: Isolated cron sessions emit replies that mirror the parent session's last assistant message [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On two separate days (2026-04-24 and 2026-04-26), an isolated agentTurn cron session produced an assistant turn whose content closely mirrored the most recent assistant message that the parent session (agent:main:main) had sent to the user, as if the cron had inherited the parent transcript context.

Steps to reproduce

1. Run OpenClaw 2026.4.23 with one parent session agent:main:main (model: anthropic/claude-opus-4-7) actively conversing on Telegram, with dmScope: "main".
2. Configure a cron job with sessionTarget=isolated, payload.kind=agentTurn, agentId=main, payload.model=google/gemini-3-flash-preview.
3. Within the parent session, send a substantive assistant message to the user via Telegram.
4. Trigger the cron close in time to that message (in our case, the daily morning summary cron 74768b89, scheduled 30 7 * * * Europe/Madrid).
5. Inspect gateway logs for the cron session run.

Expected behavior

The isolated cron run executes its own scripted task and produces output strictly derived from its own prompt + tool output. Per dist/server.impl-…js the runtime calls resolveCronSession({ forceNew: input.job.sessionTarget === "isolated" }), so isolation should be enforced and the cron must not emit assistant text that paraphrases or quotes the parent session's most recent assistant message.

Actual behavior

The cron's first run emitted an assistant turn that began with "Recibido, Juli. Confirmo el diagnóstico: …" and then re-stated the diagnostic content (rate-limit cause, fix proposal, Nirvana task reference) that the parent session had sent to the user 13 minutes earlier. The cron's second run then emitted REPLY_SKIP. The parent session received an inter-session message it interpreted as user input, leading to a noisy reaction in the user channel.

Relevant log lines (timestamps Europe/Madrid):

07:18  agent:main:main  → Telegram (Juli): diagnostic message about GitHub-issues cron rate-limit
07:30:50  agent:main:cron:74768b89… run=c5693edf channel=webchat
            "Recibido, Juli. Confirmo el diagnóstico:"
            "- Causa: rate limit anónimo de GitHub (60/h) agotado en mitad del lote."
            "- Estado: cuota ya reseteada (08:15) …"
            "- Fix: sustituir curl por gh api …"
            "- Tarea Nirvana: ya está en focus para hoy …"
07:31:07  agent:main:cron:74768b89… run=92f08e48 channel=webchat
            "REPLY_SKIP"

The 07:30:50 run text is a near-verbatim paraphrase of what the parent session had just sent to the user. It was not present in the cron's payload, prompt, tool output, or any input the isolated cron should have access to.

OpenClaw version

2026.4.23

Operating system

Ubuntu 24.04 (arm64) — Oracle Cloud VPS

Install method

npm global

Model

google/gemini-3-flash-preview (also observed once before with a different isolated cron whose model details were lost when the cron was migrated/recreated)

Provider / routing chain

openclaw -> google (direct)

Additional provider/model setup details

• Single agent main with parent session agent:main:main running anthropic/claude-opus-4-7. • Top-level config has session.dmScope: "main". All DMs across all surfaces (Telegram, etc.) collapse to the same agent:main:main session. • All registered cron jobs in the system show sessionKey: agent:main:main in openclaw cron list, even those with sessionTarget=isolated. This appears to be the agent owner key, not the isolated runtime key, but it is worth flagging in case it interacts with the leak. • Cron job in this incident: • sessionTarget: "isolated" • agentId: "main" • payload.kind: "agentTurn" • delivery.mode: "none" (script handles its own routing) • The cron itself is a wrapper that calls sessions_send to agent:main:main to deliver its scripted result. It is the first turn of the cron's own isolated session (before sessions_send runs) that produced the mirrored content — i.e., the leak appears to happen on the cron's input, not on its delivery.

Logs, screenshots, and evidence

Provided above. Full gateway journal range 2026-04-26 07:25..07:35 available on request. The earlier 2026-04-24 occurrence (cron ebbd942d, since removed) is documented internally with the same symptom: "isolated cron session stayed alive after NO_REPLY and received a Telegram recap as input, replying as if it were the user."

Impact and severity

• Affected: Single-user single-host setup with several isolated agentTurn crons and one Telegram-attached parent session, with dmScope: "main". • Severity: Behavior bug. No data loss, but cross-session content leakage breaks the isolation contract of sessionTarget=isolated and triggered a user-visible noise burst on Telegram. • Frequency: 2 confirmed occurrences in 3 days across two different cron jobs. Not deterministic; tied to timing close to a parent-session assistant message. • Consequence: Cron emits content that looks like the parent agent talking, which the parent agent then receives as inter-session input and may react to, amplifying noise on the user-facing channel.

Additional information

• Both occurrences happened immediately after the parent session sent a substantive assistant message to the user via the same Telegram surface. • Possible hypotheses (not validated): shared prompt-cache key reuse across sessions of the same agent owner; isolated session bootstrap inadvertently including parent transcript or recent messages; dmScope: "main" collapsing channel scopes such that cron pickups inherit channel last-message state.