Bug: Cron Job Narration Leaking to Slack (and Other Channels)

A subtle but confusing bug has surfaced in OpenClaw: when your cron jobs run, internal assistant narration can accidentally leak to your Slack DMs (or other messaging surfaces). Here's what's happening and how to work around it.

The Problem

Imagine you've set up a cron job that delivers a morning news digest to Google Chat. The job runs, sends the digest successfully, and then... you get a random Slack DM saying "履歴を更新するかの。" ("Shall I update the history?").

Wait, what? You didn't ask for anything. Why is your agent talking to you about updating history files?

What's Actually Happening

When cron jobs run through the main session (the default behavior), the assistant's intermediate responses—its internal "thinking out loud" narration—can get routed to whatever messaging surface was last active. In GitHub issue #28565, a user discovered this when their evening digest job (targeting Google Chat) leaked internal narration to their Slack DM.

The session log tells the story:

The agent correctly sent the essay to Google Chat via the message tool. But before calling the next tool (to update a history file), it narrated its intention. That narration—which should have been invisible internal processing—got routed to Slack because Slack was the user's last active channel.

Why This Happens

OpenClaw routes assistant responses to the "last active" messaging surface by default. This is usually what you want—when you're chatting with your agent on Telegram and it responds, you want that response on Telegram.

But cron jobs are different. They're background automation, not conversations. When a cron job runs and the assistant emits intermediate narration (before calling a tool, between tool calls, etc.), that narration follows the same routing logic. If your last chat was on Slack, the narration goes to Slack.

Workarounds Until It's Fixed

1. Spawn Isolated Sessions for Cron Jobs

Instead of running cron jobs through your main session, use sessions_spawn to create isolated sessions. These sessions don't inherit your "last active channel" state:

{
  "schedule": "0 8 * * *",
  "text": "Run my morning digest",
  "isolated": true
}

2. Explicitly Set Delivery Channels

When creating cron jobs, specify where output should go instead of relying on default routing:

{
  "schedule": "0 8 * * *",
  "text": "Send morning news to #announcements",
  "deliveryChannel": "slack",
  "deliveryTarget": "#announcements"
}

3. Suppress Narration in Cron Prompts

Add explicit instructions in your cron job text:

This isn't foolproof (models may still emit partial responses), but it reduces the frequency of leaks.

The Fix

The proper fix would be for OpenClaw to treat cron job intermediate responses differently from interactive chat responses. Cron execution should:

1. Not route intermediate narration to user-facing channels
2. Only deliver explicit message tool calls to specified targets
3. Optionally log narration to session transcripts without user delivery

The issue is currently open and being tracked. If you've experienced this bug, adding your scenario to the GitHub issue helps prioritize the fix.

Detecting If You're Affected

Search your Slack/Telegram/Discord history for messages from your agent that seem out of context—especially short phrases like "I'll update..." or "Let me check..." or Japanese/Chinese text if your agent uses those languages. These are likely narration leaks from background cron jobs.

This bug is a reminder that AI agents running background automation need different message routing logic than interactive chat. Until the fix lands, the workarounds above should keep your channels clean.