Cron: allow per-job opt-in to send_message tool

Problem

Cron jobs that need to actively send messages to specific channels (e.g., a WhatsApp group) cannot do so because the cron runner:

1. Hard-disables the messaging toolset (disabled_toolsets=["cronjob", "messaging", "clarify"] in cron/scheduler.py:1045)
2. Injects a system instruction telling the agent not to use send_message (cron/scheduler.py:744)

This is a deliberate safety measure, and it makes sense for the common case where deliver handles everything. But it creates a gap for a legitimate use case: cron jobs that need to send formatted messages to a channel different from the deliver target, while keeping deliver for execution summaries.

Current workaround (and why it's bad)

Agents discover they don't have send_message and fall back to curl against platform bridge APIs directly (e.g., WhatsApp bridge on localhost:3000). This:

• Bypasses all framework safety layers (rate limiting, chunking, platform auth)
• Is fragile and platform-specific (breaks when bridge ports/paths change)
• Produces confusing agent behavior (agent "searching for ways to send" wastes tokens)
• Can't benefit from framework improvements to message delivery

There is no clean workaround within the framework. enabled_toolsets on the job config cannot override disabled_toolsets (by design — disabled_toolsets is always applied as the final subtraction step, see model_tools.py:369).

Proposal

Add a per-job opt-in to re-enable the messaging toolset for specific cron jobs:

{
  "name": "daily-group-report",
  "allow_messaging": true,
  "deliver": "origin",
  "prompt": "Generate the report and send it to whatsapp:[email protected] using send_message..."
}

When allow_messaging: true:

1. Remove "messaging" from disabled_toolsets for this job
2. Skip injecting the "do NOT use send_message" preamble for this job
3. Keep "cronjob" and "clarify" disabled (recursion guard and no-op for cron)

This is backward compatible — default behavior is unchanged. Jobs that don't set allow_messaging continue to work exactly as today.

Why not just multi-target deliver? (#13469)

#13469 proposes letting deliver accept an array of targets. That solves the multi-destination problem but doesn't cover cases where the agent needs to compose and format the message differently per target (e.g., a detailed report to a group chat, a one-line summary to DM). With allow_messaging, the agent can send a richly formatted message to the group while deliver handles the execution summary to DM.

The two proposals are complementary, not competing.

Implementation sketch

In cron/scheduler.py, run_job():

# Current:
disabled_toolsets=["cronjob", "messaging", "clarify"],

# Proposed:
_job_disabled = ["cronjob", "clarify"]
if not job.get("allow_messaging"):
    _job_disabled.append("messaging")
disabled_toolsets=_job_disabled,

For the prompt preamble, skip the "do NOT use send_message" line when allow_messaging is true:

if not job.get("allow_messaging"):
    cron_hint = "[IMPORTANT: ... do NOT use send_message ...]"
else:
    cron_hint = "[IMPORTANT: You are running as a scheduled cron job. ...]"

Tool-facing API (cronjob tool create/update):

{"action": "create", "allow_messaging": true, ...}

Use cases

• Scheduled reports sent to group chats (WhatsApp, Discord, Slack channels) with custom formatting
• Alert/notification jobs that broadcast to a specific channel
• Jobs that write to files and notify a channel about the result