Summary

When a cron job has delivery.accountId explicitly set (e.g. "buma" for a multi-account Telegram setup), isolated agent cron runs ignore this value and deliver via accountId: "default" instead. This causes 403 errors when the default bot is not a member of the target group.

Root Cause

src/cron/isolated-agent/run.ts:376 calls resolveDeliveryTarget without passing job.delivery.accountId:

const resolvedDelivery = await resolveDeliveryTarget(cfgWithAgentDefaults, agentId, {
  channel: deliveryPlan.channel ?? "last",
  to: deliveryPlan.to,
  sessionKey: params.job.sessionKey,
  // ❌ job.delivery.accountId is NOT passed here
});

delivery-target.ts then falls back to buildChannelAccountBindings to find the accountId, but the binding lookup fails to resolve the correct account, resulting in accountId: "default" in the queued delivery entry.

Steps to Reproduce

1. Configure a multi-account Telegram setup (e.g. accounts.buma and accounts.default)
2. Create a cron job with agentId: "buma", delivery.accountId: "buma", delivery.to: "<group_id>", sessionTarget: "isolated"
3. Run the job — delivery queue entry will have accountId: "default" instead of "buma"
4. If the default bot is not in the target group, message fails with 403: Forbidden: bot was kicked from the supergroup chat

Workaround

Manually edit the delivery queue JSON file to set accountId: "buma" and retryCount: 0, then restart the gateway.

Expected Behavior

job.delivery.accountId should be passed through to resolveDeliveryTarget (or applied after resolution) so isolated cron jobs deliver via the correct bot account.

Environment

• openclaw 2026.2.23
• Telegram multi-account setup
• Cron job sessionTarget: "isolated", wakeMode: "now"