openclaw - ✅(Solved) Fix Cron job --model override is ignored during execution [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#65129Fetched 2026-04-12 13:25:30
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
referenced ×2cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #65179: fix: apply payload.model override in cron jobs even when not in allowlist (#65129)

Description (problem / solution / changelog)

Summary

When a cron job has payload.model set, the model is stored correctly in the job config but silently ignored at execution time, reverting to the agent default. The bug affects all cron jobs with an explicit model override (#65129).

Root cause

resolveCronModelSelection calls resolveAllowedModelRef, which checks the model against agents.defaults.models. If the model is not in that allowlist, it returns { error: "model not allowed: ..." }.

The caller then hits this branch:

if (resolvedOverride.error.startsWith("model not allowed:")) {
  return {
    ok: true,
    provider,  // ← falls back to default silently
    model,
    warning: `cron: payload.model '${modelOverride}' not allowed, falling back to agent defaults`,
  };
}

The warning is logged but not surfaced to the user in cron runs output, so the behavior looks like the override is simply ignored.

Fix

payload.model is an explicit per-job declaration by the user — different from ad-hoc model selection. It should be applied as long as the model exists in the provider catalog (i.e. the provider is actually configured), regardless of the agents.defaults.models allowlist.

When resolveAllowedModelRef returns "model not allowed", we now:

  1. Check if the model is in the catalog
  2. If yes → re-resolve with models: {} (allowAny=true) so the override takes effect
  3. If no → keep the fallback with a clearer warning message

This preserves the allowlist constraint for ad-hoc/session model selection while correctly honoring explicit cron job configurations.

Repro

# Add a cron job with a model not in agents.defaults.models
openclaw cron add --name test --at 1m --session isolated \
  --message "test" --model google/gemini-2.5-flash-preview

# Trigger and check — without fix, shows default model
openclaw cron run <id>
openclaw cron runs --id <id>

Fixes #65129

Changed files

  • src/cron/isolated-agent/model-selection.ts (modified, +55/-9)
  • src/infra/net/ssrf.ts (modified, +4/-1)
RAW_BUFFERClick to expand / collapse

Version: 2026.3.28 (f9b1079)

Summary: When creating or editing a cron job with --model, the model is correctly stored in the job configuration (visible in openclaw cron list and ~/.openclaw/cron/jobs.json), but the actual execution always uses the default agent model instead.

Steps to reproduce:

  1. Create a cron job with explicit model: openclaw cron add --name test --at 1m --session isolated --message test --model PROVIDER/MODEL --announce --channel discord --to channel:ID --delete-after-run
  2. Verify config: openclaw cron list shows the configured model
  3. Verify payload: ~/.openclaw/cron/jobs.json contains the model in the payload
  4. Trigger execution: openclaw cron run ID
  5. Check result: openclaw cron runs --id ID shows the default model (not the configured one)

Expected: Job executes with the configured model

Actual: Job executes with the default agent model, ignoring the per-job configuration

Additional notes:

  • Model override is stored correctly but never applied during execution
  • Appears to affect all cron job types (one-shot and recurring)

extent analysis

TL;DR

The issue can be resolved by ensuring that the --model parameter is correctly applied during cron job execution, potentially by modifying the execution logic to prioritize the job-specific model configuration over the default agent model.

Guidance

  • Review the cron job execution logic to verify that it correctly retrieves and applies the model configuration from the job payload stored in ~/.openclaw/cron/jobs.json.
  • Check for any overrides or defaults in the execution code that might be causing the default agent model to be used instead of the configured model.
  • Verify that the --model parameter is correctly parsed and stored in the job configuration when creating or editing a cron job.
  • Test the execution of cron jobs with different models to ensure that the issue is not specific to a particular model or provider.

Example

No code snippet is provided as the issue does not include specific code details.

Notes

The root cause of the issue appears to be a mismatch between the stored job configuration and the actual execution logic, but without access to the codebase, it is difficult to provide a more specific solution.

Recommendation

Apply a workaround by modifying the execution logic to prioritize the job-specific model configuration, as the issue seems to be related to the execution process rather than the configuration storage.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING