Summary

Cron-owned isolated jobs with explicit Discord announce delivery can resolve to a poisoned delivery context and fail with Unknown Channel even when the cron job definition itself is correct.

In this case, a job configured to announce to Discord DM target user:<redacted> repeatedly re-acquired deliveryContext: {"to":"heartbeat"} and finished deliveryStatus: not-delivered.

Environment

• OpenClaw 2026.4.8 (9ece252)
• Host: macOS
• Gateway restarted cleanly during repro
• Discord delivery target format: channel=discord, to=user:<redacted>

Why this looks like a product bug, not misconfiguration

I checked the current docs before filing this:

• cron docs say isolated jobs plus announce delivery are the intended pattern for report-style/background work
• Discord docs say outbound targets should use explicit prefixes like user:<id> or channel:<id>
• troubleshooting docs say to verify cron runs, delivery target, auth, and logs

The setup matches that guidance. The failure persisted after job normalization, job recreation, and a clean gateway restart.

Minimal repro story

1. Create or normalize a cron job to use:
   • sessionTarget: isolated
   • delivery.mode: announce
   • delivery.channel: discord
   • delivery.to: user:<redacted>
   • delivery.bestEffort: true
2. Run the job and inspect cron runs plus session state.
3. Observe delivery failure with:
   • delivery payload failed (bestEffort): Unknown Channel
4. Restart the gateway cleanly.
5. Force one bounded rerun.
6. Observe the same failure again.

Observed behavior

The failing post-restart canary run showed:

• cron job: 36abfb0a-44b5-4c7d-822f-ade7d9db9435
• run session: 3c9ab8ba-5d20-4be7-8fed-2faf34853bf4
• delivered: false
• deliveryStatus: not-delivered

Gateway log:

• [cron:36abfb0a-44b5-4c7d-822f-ade7d9db9435] delivery payload failed (bestEffort): Unknown Channel

Session-context symptom:

• the canary base cron session briefly rebuilt cleanly after restart, then re-acquired:
  • deliveryContext: {"to":"heartbeat"}

That poisoned context is inconsistent with the explicit Discord announce target.

Expected behavior

Cron-owned isolated jobs with explicit Discord announce delivery should honor the configured Discord target and should not inherit or reapply unrelated heartbeat delivery context.

Current best hypothesis

This looks like a deterministic cron session-context lookup / inheritance / precedence bug in the agent:main:cron:* path, not just stale in-memory state.

Reason:

• job definition is correct
• recreated jobs still failed
• fresh gateway restart did not clear the behavior
• poisoned context was re-applied after restart

Extra notes

Independent read-only review by a validator lane and a thinker lane both converged on the same conclusion class:

• not well explained by simple stale RAM alone
• better explained by deterministic polluted-context precedence / cron session-context resolution

Offer

If useful, I can provide a sanitized evidence bundle structure and exact pre/post restart session-context diffs.