Summary

A long-running cron agentTurn can be configured to target the same persistent session key as a user-facing Telegram direct chat. In the incident that triggered this, a daily repost cron ran inside the live chat session lane, failed before a clean completion, and the next human Telegram message was recorded into the same cron transcript instead of being handled as a clean live-chat turn. The user-facing bot looked silent until another session intervened.

There is a second related failure mode: after rerouting the job to isolated execution and manually running it, the cron task stayed running with no childSessionKey, no progress after startedAt, and openclaw tasks cancel reported Task has no cancellable child session.

Environment

• OpenClaw: 2026.6.5 (5181e4f)
• Runtime: OpenAI Codex / openai/gpt-5.5
• Surface: Telegram direct chat
• Job shape: recurring cron, payload.kind = agentTurn, long timeoutSeconds = 3600

What happened

1. A daily background repost sweep was configured as a cron agentTurn with sessionTarget: "session:<telegram-direct-session-key>".
2. The run failed with: Codex stopped before confirming the turn was complete. Some work may already have been performed; verify the current state before retrying.
3. A later Telegram voice note to the same bot was appended to the same session/transcript as the cron prompt rather than getting a clean user-facing lane.
4. The visible Telegram bot did not promptly answer the human's message. Another session had to prod/recover it.
5. Manual mitigation was to update the cron to sessionTarget: "isolated" and clear the explicit live-chat sessionKey, so future long repost sweeps do not occupy the Telegram conversation session.
6. A manual isolated rerun then showed another bug: the task remained running, had no childSessionKey, lastEventAt === startedAt, and could not be cancelled because there was no cancellable child session.

Expected behavior

• A background cron should not be able to monopolize, contaminate, or block a live user-facing chat session by default.
• If a cron really targets a specific chat session, incoming human messages should still be routed to a responsive live lane, preempt the background turn, or fail with a clear visible state instead of silently waiting behind cron work.
• Stalled cron dispatches with no child session should be marked failed after a short dispatch watchdog window and should always be cancellable/clearable.

Actual behavior

• The cron and live Telegram message shared the same session/transcript lane.
• The user-facing bot appeared not to answer a direct message until manual/inter-session recovery.
• After rerouting to isolated execution, the manual run could still get stuck as a childless running cron task with no useful progress and no cancel path.

Suggested fixes

• Add validation or a loud warning when a cron agentTurn targets a user-facing session key, especially Telegram/DM sessions, and prefer isolated for long-running background jobs.
• Separate background cron execution lanes from visible conversation reply lanes, even when the cron wants access to the same persona/context.
• Add a dispatch watchdog: if no child session/model activity is created within N seconds, mark the cron run failed, clear runningAtMs, and surface a useful diagnostic.
• Make openclaw tasks cancel <cron-run> work even when the task has no childSessionKey; at minimum clear the durable task/run marker and cron runningAtMs safely.
• Add regression tests:
  • cron agentTurn targets a user-facing session; a live human message arrives; the human gets a clean live response path.
  • cron run stalls before child session creation; it self-fails and can be cancelled.

Related issues

Possibly related to #84983 and #84583, but this report is specifically about sessionTarget: session:<live-chat> cross-contaminating the user-facing transcript and the childless running-task/cancel failure after isolated reroute.