Description

When using the cron tool's update action to patch a job's payload, the model field cannot be cleared back to "inherit from the agent's default model". Three patch shapes all silently no-op:

1. patch: {payload: {model: null}} — null is dropped, existing value retained.
2. patch: {payload: {model: ""}} — empty string ignored, existing value retained.
3. patch: {payload: {message: "...", timeoutSeconds: 900}} (omitting model entirely) — does NOT clear it. Patch is merge at payload level, not replace.

By contrast, the same patch shape DOES clear fallbacks when set to [] — so the inconsistency is specifically on model (and likely any other singleton string field whose schema isn't nullable).

Why this matters

When a user rotates their active model profile, existing cron jobs with stale hardcoded payload.model keep running on the old model even though the agent's default would resolve correctly. Today's workarounds are unsatisfying:

• Set model to a current value (still hardcoded — defeats inheritance, requires manual re-sync on every profile change)
• Delete + recreate the cron (loses lastRunAtMs, consecutiveErrors, createdAtMs, and any other accumulated job state)
• Direct edit of the cron store (requires gateway restart, risky during live operations)

Expected behavior

One of:

• null on payload.model clears the field (treat as "inherit from agent default")
• A new patch shape such as {payload: {model: {clear: true}}} or top-level clear: ["payload.model"]
• Document the supported way to remove a payload override post-creation

Reproduction

// Existing cron payload:
{ "payload": { "model": "<model-A>", "fallbacks": ["<model-B>"], "message": "...", "timeoutSeconds": 900 } }

// Attempt to clear via cron update with patch:
{ "patch": { "payload": { "model": null, "fallbacks": null } } }

// Observed after update:
{ "payload": { "model": "<model-A>", "fallbacks": ["<model-B>"], ... } }
// model unchanged; fallbacks also unchanged when null.

// Patch with fallbacks: [] DOES clear:
{ "patch": { "payload": { "fallbacks": [] } } }
// → fallbacks now []
// model is still untouchable.

Schema note

In the cron MCP tool's JSON Schema, update.patch.payload.model is declared as {"type": "string", "description": "Model override"} — no nullable: true or anyOf: [string, null]. By contrast, update.patch.payload.toolsAllow declares anyOf: [{items: {type: string}, type: array}, {type: null}] and clears successfully when set to null. Suggest aligning model (and fallbacks for consistency) to the same nullable pattern.

Environment

• OpenClaw version: OpenClaw 2026.6.1 (2e08f0f)
• Platform: Linux