openclaw - 💡(How to fix) Fix Support script target type in openclaw cron (currently systemEvent | agentTurn only)

Motivation

Enable script-only cron demotions without requiring a launchd LaunchAgent workaround. The current systemEvent | agentTurn payload union means any "demote this cron from an agent turn to a shell script" goal forces the user out of openclaw cron entirely and into ~/Library/LaunchAgents/ai.openclaw.*.plist. That splits the cron inventory across two surfaces — openclaw cron list no longer shows demoted jobs, breaking discovery for memory-review / cookbook-audit / ladder-review and any other tooling that uses openclaw cron list as the authoritative inventory.

Empirical case

As of 2026-05-12 I have two crons on my system demoted from agentTurn to script-only via a launchd LaunchAgent workaround:

• samissd-verify (weekly Mon 09:00 SSD-mirror drift check)
• calendar-reminder (hourly Calendar.app → Telegram reminder)

The calendar-reminder demotion alone saves ~62M agent-context tokens/week. Audit data: over a representative 72h window, the original agentTurn cron produced 0 actionable Telegrams across 176 runs while spending ~26.4M total tokens. A script-only replacement does the same job (osascript query + dedup state file + Telegram fire on events) for no agent-context cost.

Both demotions required:

1. Building a non-platform Mach-O launcher binary (~/.local/bin/openclaw-launchd-runner) so the user could grant macOS TCC permissions — Apple refuses to honor per-app TCC entitlements (FDA, Automation, etc.) on platform binaries like /bin/zsh. The tccd log line is Platform binary prompting is 'Deny' because: is Platform Binary.
2. Manually granting Full Disk Access + per-service Automation permissions (Calendar) to that launcher binary, via System Settings → Privacy & Security panels. Each new demotion that crosses a new TCC service requires another grant.
3. Managing two parallel cron-inventory surfaces (openclaw cron list AND launchd ai.openclaw.* plists), with no unified discovery between them.

Each of those steps is significant friction. A native kind: script cron type would eliminate all three because the openclaw gateway daemon already carries the relevant TCC grants on the user's system; subprocesses launched from the daemon inherit those grants without any per-binary grant ceremony.

Proposed semantics

A new payload kind alongside the existing systemEvent and agentTurn:

kind: "script"
payload:
  command: string                  // absolute path or command name on the daemon's $PATH
  args: string[]                   // argv to pass
  env?: Record<string, string>     // optional environment additions
  timeoutSeconds?: number          // optional, default 300
  captureStdout?: boolean          // if true, stdout becomes the announce payload (subject to size cap)

Execution: the cron runs the command as a subprocess of the openclaw gateway daemon. Existing delivery modes (announce, webhook, none) remain unchanged; when captureStdout: true, the script's stdout (subject to a size cap) becomes the announce payload, exactly like the agent-turn final reply does today.

Session targets: script payload effectively is a fourth execution style alongside main | isolated | current | custom, but since no agent context is spawned, the session-target axis is irrelevant. Treating it as implicitly "no session" is the cleanest mental model.

Backwards compatibility

Additive only. Existing systemEvent and agentTurn kinds remain unchanged. Old crons need no migration. The CronPayload TypeBox union at dist/plugin-sdk/src/gateway/protocol/schema/cron.d.ts gains a third literal; existing readers/writers either understand it or reject it cleanly per the existing union-validation path.

Reference

OpenClaw 2026.5.7 (eeef486), macOS Darwin 25.4.0. Can provide additional empirical data on token savings, the TCC-friction details (incident memory captured locally), or the launcher implementation if helpful.