Summary

All cron jobs using sessionTarget: isolated + delivery.mode: announce are silently failing to deliver. The job runs successfully but the announce step fails every time.

Steps to reproduce

1. Create a cron job with sessionTarget: isolated and delivery.mode: announce
2. Set the job to run an agentTurn that produces output (not NO_REPLY)
3. Wait for the job to fire (or trigger manually via openclaw cron run <id>)
4. Observe: job runs, content is generated, delivery fails

Expected behavior

The cron subagent completes its turn, and the result is announced to the configured delivery target (Discord DM, channel, etc.) without requiring any additional authentication.

Actual behavior

The subagent runs successfully but fails to deliver. The gateway rejects the announce step with 1008: pairing required. The job is marked as error with lastError: "cron announce delivery failed" and enters exponential backoff.

OpenClaw version

2026.2.19-2

Operating system

macOS 26.3 (arm64)

Install method

No response

Logs, screenshots, and evidence

gateway/ws: security audit: device access upgrade requested
  reason=scope-upgrade
  device=6612d119ea51b1f4c9ce96df9b0d80c397fb00a9f9bbb1b5058a259c73e04f31
  scopesFrom=operator.admin,operator.approvals,operator.pairing,operator.read
  scopesTo=operator.write

gateway connect failed: Error: pairing required

Subagent completion direct announce failed for run <jobId>:<runId>:
  gateway closed (1008): pairing required
  Gateway target: ws://127.0.0.1:18789
  Source: local loopback

Impact and severity

Affected: Any user running isolated cron jobs that announce output — daily briefs, alerts, summaries, or any scheduled agent turn with deliver/announce enabled
Severity: Blocks workflow — scheduled automations silently fail; the job appears to run but output is never delivered
Frequency: 100% reproducible — every isolated cron job with announce delivery fails on every run
Consequence: Users receive no output from scheduled jobs. Consecutive error backoff (60s → 300s → …) means jobs increasingly fall behind. There is no fallback or retry path that succeeds. Jobs that ran previously may have silently stopped working after a version update without any user-visible warning

Additional information

• Jobs using a pinned sessionKey pointing to an existing authenticated session still fail — the scope issue is on the subagent device token, not the session routing
• Jobs that return NO_REPLY (no delivery needed) are unaffected
• The delivery queue accumulates stuck entries that time out on every gateway restart and are never recovered (Found 6 pending delivery entries → Recovery time budget exceeded → 0 recovered)
• The gateway is local loopback only (127.0.0.1); this is not a remote/network auth issue — the subagent is on the same machine and should not need to re-pair for write scope
• Workaround: none found. The --best-effort-deliver flag exists but does not resolve the underlying scope rejection