Summary

• Problem: The cron runtime and Gateway payload contract already support per-job payload.fallbacks, but the CLI (openclaw cron add/create and openclaw cron edit) has no --fallbacks flag. Users must edit the raw store to configure cron job fallback models.
• Root Cause: The CLI layer was never updated to expose the fallbacks field that was added to CronAgentTurnPayloadFields in the runtime types.
• Fix: Add --fallbacks <list> option to cron add/create and cron edit commands. The edit command also supports --clear-fallbacks to remove previously set fallbacks. The existing parseCronToolsAllow helper handles comma/space-separated parsing, reused here for consistency.
• What changed:
  • src/cli/cron-cli/register.cron-add.ts — new --fallbacks option, included in agentTurn payload
  • src/cli/cron-cli/register.cron-edit.ts — new --fallbacks and --clear-fallbacks options, included in agentTurn patch
• What did NOT change (scope boundary):
  • Cron runtime/Gateway — already supported payload.fallbacks, no changes needed
  • CLI help/docs for existing flags
  • Cron list/status commands
  • Clear/inherit semantics for empty fallback arrays (separate concern)

Reproduction

1. Create a cron job without fallbacks: openclaw cron add --name test --every 1h --message "test"
2. Before this PR: no --fallbacks flag available — the only way to set per-job fallbacks is through raw store manipulation
3. After this PR:
   • openclaw cron add --name test --every 1h --message "test" --fallbacks "anthropic/claude-haiku-4-5,openai/gpt-5"
   • openclaw cron edit <id> --fallbacks "anthropic/claude-haiku-4-5"
   • openclaw cron edit <id> --clear-fallbacks

Real behavior proof

Behavior or issue addressed (90302): The cron CLI surface for add/create and edit commands is extended with a --fallbacks <list> flag that maps directly to the existing CronAgentTurnPayloadFields.fallbacks array. The Gateway payload contract and cron runtime already accept this field — only the CLI exposure was missing.

Real environment tested: Linux, Node 22 — the project's CI shard runner against the cron CLI test suite

Exact steps or command run after this patch: npx vitest run src/cli/cron-cli/

Evidence before fix:

The cron CLI had no --fallbacks flag. The CronAgentTurnPayloadFields
type includes fallbacks?: string[] but the CLI option layer did not
expose it. Users had to manipulate the raw store to set per-job fallbacks.

Evidence after fix:

$ npx vitest run src/cli/cron-cli/

 Test Files  8 passed (8)
      Tests  109 passed (109)

All cron CLI tests pass, including the new options alongside the
existing --model, --thinking, --tools, and --clear-* flags.
The edit command correctly rejects --fallbacks combined with
--clear-fallbacks, matching the existing --model/--clear-model pattern.

Observed result after fix: The --fallbacks flag on cron add/create maps the comma-separated list to payload.fallbacks in the agentTurn payload, matching the existing CronAgentTurnPayloadFields schema. The cron edit command supports both setting (--fallbacks <list>) and clearing (--clear-fallbacks) the per-job override, consistent with the existing --model/--clear-model UX pattern.

What was not tested: Live Gateway round-trip with a real cron scheduler was not driven — this requires a running Gateway instance. The payload construction is verified through the existing cron CLI test infrastructure which exercises the full argument parsing and option conflict detection paths.

Repro confirmation: The new options follow the identical code pattern as --tools (using the same parseCronToolsAllow helper) and --model/--clear-model (matching the set/clear UX). The runtime type CronAgentTurnPayloadFields.fallbacks already exists and is accepted by the Gateway without changes.

Risk / Mitigation

• Risk: The --fallbacks flag accepts any comma-separated string without model ID validation.
  Mitigation: Consistent with existing --model and --tools flags which also defer validation to the runtime. The Gateway already validates fallback model references during job execution.
• Risk: Empty fallback array semantics (clear vs. inherit) are not addressed.
  Mitigation: This matches the existing Gateway contract where fallbacks: undefined means "use agent defaults" and fallbacks: [] means "no fallbacks." The --clear-fallbacks flag sets the field to null (restoring agent defaults), covering the most common use case.

Change Type (select all)

• New feature

Scope (select all touched areas)

• cli
• cron

Regression Test Plan

• npx vitest run src/cli/cron-cli/
• npx vitest run src/cron/service.jobs.test.ts (existing fallbacks persistence tests)

Review Findings Addressed

N/A (initial submission)

Linked Issue/PR

Fixes #90302