Summary

The cron tool's JSON schema validation rejects null for payload.model and payload.fallbacks, preventing users from clearing these fields to re-enable global inheritance. The underlying Gateway protocol and service code already support null clears, but the tool schema blocks them before they reach the service layer.

Background

• #91362 / #91379: Implemented cron fallback inheritance (shipped in v2026.6.11)
• #93369: Added --clear-fallbacks, nullable fallback update clears, docs, and tests (also shipped)
• #100577: User report about cron fallbacks not inheriting (closed as duplicate)
• #100668: Follow-up about cron update null clears not working (closed as already-implemented, see root cause below)

Root Cause

The cron tool's own JSON schema for patch.payload still requires fallbacks to be a non-null array. The null value is rejected by tool-side validation before it can reach the Gateway service, where mergeCronPayload would correctly delete the stored override.

Reproduced on v2026.6.11 (e085fa1)

cron update --patch {"payload":{"model":null,"fallbacks":null}}
→ Validation failed: patch.payload.fallbacks: must be array

Layer Analysis

Expected Behavior

cron update should accept model: null and fallbacks: null in the patch payload, allowing users to clear stored per-job overrides and revert to agent-level global defaults.

Workaround

Delete and recreate the cron job without these fields in payload.

End-to-End Verification

Recreating a cron job without fallbacks → inheritance works correctly:

• Set payload.model: "xiaomi/mimo-v2.5-pro" (fails with 402)
• No payload.fallbacks set → inherited global ["openai/gpt-5.5", ...]
• Job fell back to openai/gpt-5.5 and completed successfully (fallbackUsed: true)