Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: --model flag on isolated cron jobs does not override session model [5 pull requests, 2 comments, 2 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#58575•Fetched 2026-04-08 02:00:48
View on GitHub
Comments
2
Participants
2
Timeline
11
Reactions
0
Author
litefutlitefut
Participants
litefutlitefutStarhappyshStarhappysh
Timeline (top)
cross-referenced ×4referenced ×3commented ×2labeled ×2

openclaw cron add/edit --model anthropic/claude-haiku-4-5 --session isolated sets the model correctly in payload.model, but the isolated session always initializes with the default model (claude-sonnet-4-6) instead.

Root Cause

openclaw cron add/edit --model anthropic/claude-haiku-4-5 --session isolated sets the model correctly in payload.model, but the isolated session always initializes with the default model (claude-sonnet-4-6) instead.

PR fix notes

PR #58992: fix(cron): clear stale model state on new isolated sessions

Description (problem / solution / changelog)

Summary

  • Clear model, modelProvider, modelOverride, and providerOverride when creating new isolated cron sessions
  • Prevents stale model state from shadowing payload.model override and triggering LiveSessionModelSwitchError

Details

When resolveCronSession creates a new session for an isolated cron job, it spreads ...entry from the previous session to preserve per-session overrides. However, this also preserves stale model fields:

  • modelOverride/providerOverride from a previous /model command can shadow the cron payload's model override in resolveCronModelSelection
  • model/modelProvider from a previous fallback can trigger LiveSessionModelSwitchError when the next run tries to use the primary model

The fix adds these four fields to the isNewSession cleanup block, alongside the existing delivery context cleanup.

Fixes #58575 Fixes #58585

Test plan

  • Create cron job with --model haiku --session isolated; verify session uses haiku, not agent default
  • Trigger model fallback in one cron run; verify next run uses primary model without error
  • Verify non-isolated (reused) sessions still preserve model state correctly

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) [email protected]

Changed files

  • src/cron/isolated-agent/delivery-target.ts (modified, +65/-35)
  • src/cron/isolated-agent/session.ts (modified, +8/-0)

PR #58998: fix(cron): prevent agent default model from overriding payload.model on isolated sessions

Description (problem / solution / changelog)

Summary

  • When a cron job specifies payload.model (e.g. via --model flag) but no explicit fallbacks, and the agent has no configured fallback chain, fallbacksOverride resolved to undefined
  • Inside runWithModelFallback -> resolveFallbackCandidates, when fallbacksOverride is undefined, the agent's configured primary model is silently appended as a last-resort fallback candidate
  • This causes isolated cron sessions to fall back to the agent default model instead of using the payload-specified model
  • Fix: when the payload carries an explicit model override and both payloadFallbacks and agent-level fallbacks are undefined, default fallbacksOverride to [] (empty array) to prevent the agent primary model injection

Fixes #58575 Related: #58065, #57947

Test plan

  • Create cron job with --model anthropic/claude-haiku-4-5 --session isolated
  • Trigger the job and verify session JSONL shows the specified model, not the agent default
  • Verify cron jobs without explicit model override still use the full fallback chain
  • Verify payload-level fallbacks arrays are still respected when present

🤖 Generated with Claude Code

Changed files

  • src/cron/isolated-agent/run.ts (modified, +7/-1)

PR #59000: fix(cron): clear stale model/provider overrides on new isolated sessions

Description (problem / solution / changelog)

Summary

  • When an isolated cron session rolls to a new sessionId (forceNew=true), the session entry preserves all fields from the previous entry via object spread (...entry)
  • This causes modelOverride and providerOverride from prior sessions to leak into the new session
  • These stale overrides can interfere with model resolution in resolveCronModelSelection, which checks sessionEntry.modelOverride as a fallback when no payload model is specified
  • Fix: clear modelOverride and providerOverride alongside the existing delivery routing state cleanup when starting a fresh session

Fixes #58927 Related: #58575, #58065

Test plan

  • Create a cron job with --session isolated and a specific --model
  • Run the job, verify the model is used correctly
  • Set a model override via /model on the cron session, then run the job again
  • Verify the new isolated session does NOT inherit the manual model override
  • Verify non-isolated sessions still preserve model overrides as expected

🤖 Generated with Claude Code

Changed files

  • src/cron/isolated-agent/session.ts (modified, +6/-0)

PR #59204: fix(cron): honor payload.model override by bypassing allowlist gate

Description (problem / solution / changelog)

Summary

  • The cron --model flag override was being validated against the model allowlist via resolveAllowedModelRef. When the override model was not in the allowed set, it silently fell back to agent defaults with only a warning — making it impossible to use non-allowlisted models in cron jobs.
  • Per the docs, payload.model has the highest priority and should always be honored. Now resolves the model ref directly via resolveModelRefFromString without the allowlist check, returning an error only for invalid model ref formats.

Test plan

  • Run a cron job with --model set to a model not in the allowlist
  • Verify the cron job uses the specified model (no fallback)
  • Run npx vitest run src/cron/isolated-agent/run.cron-model-override.test.ts — all tests pass
  • Run npx vitest run src/cron/isolated-agent/run.skill-filter.test.ts — all tests pass

Fixes #58575

— Joel Nishanth · offlyn.AI

Made with Cursor

Changed files

  • src/cron/isolated-agent/model-selection.ts (modified, +14/-15)
  • src/cron/isolated-agent/run.cron-model-override.test.ts (modified, +40/-11)
  • src/cron/isolated-agent/run.skill-filter.test.ts (modified, +9/-22)

PR #68277: docs(troubleshooting): document isolated-cron payload.model silent-fallback workaround

Description (problem / solution / changelog)

Summary

Adds a troubleshooting section for users hitting the silent-fallback bug cluster (#59257, #58575, #49168) where an isolated cron job with payload.model: "ollama/..." completes with lastStatus: "ok" but the actual inference ran on the configured agent default, silently billing the wrong provider.

The root-cause fixes are currently split across #57094 (caller-supplied defaults seam) and #58992 (stale runtime-model-state seam), both open. Until they land, affected users need a working configuration pattern — this doc section documents it so people can find it during triage rather than having to dig through the long issue comment thread.

What's included

  • Symptoms and detection steps (log grep for embedded run start: runId=... provider=... model=..., compare against payload.model)
  • Working workaround pattern: per-agent profile in agents.list with fallbacks: [], pointing the affected cron's agentId at the worker profile
  • Auth profile + allowlist setup steps

Provenance

The workaround pattern was originally posted by @mschultz77-gravelroad in https://github.com/openclaw/openclaw/issues/59257#issuecomment-4196017313. This PR surfaces it into the canonical troubleshooting doc location.

I've independently verified the pattern on a local install at v2026.4.15: 5 affected cron jobs routed cleanly to Ollama after applying the fix (real 258s+ local inference durations, correct sessionKey=agent:worker-qwen:cron:... in logs).

Cleanup plan

Once #57094 + #58992 both merge, this section should be updated (or removed in favor of a simpler note) since the workaround won't be needed anymore.

Test plan

  • Mintlify link rules: all internal links root-relative, no .md suffix
  • Docs content rules: uses placeholder paths (~/.openclaw/...), no personal hostnames
  • Section styling matches existing troubleshooting.md sections (symptoms / detection / fix / related)

🤖 Generated with Claude Code

Changed files

  • docs/gateway/troubleshooting.md (modified, +81/-0)
  • src/cron/isolated-agent/session.ts (modified, +11/-0)

Code Example

{"type":"model_change","modelId":"claude-sonnet-4-6"}

### OpenClaw version

• OpenClaw: 2026.3.28 (f9b1079)

### Operating system

 macOS 25.3.0 (arm64)

### Install method

npm (global install) - OpenClaw version: 2026.3.28

### Model

anthropic/claude-sonnet-4-6

### Provider / routing chain

- No proxy, no router, no external gateway

### Additional provider/model setup details

_No response_

### Logs, screenshots, and evidence
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

openclaw cron add/edit --model anthropic/claude-haiku-4-5 --session isolated sets the model correctly in payload.model, but the isolated session always initializes with the default model (claude-sonnet-4-6) instead.

Steps to reproduce

  1. openclaw cron add --name "test" --cron "* * * * *" --session isolated --message "hello" --model anthropic/claude-haiku-4-5
  2. Wait for or manually trigger: openclaw cron run <id>
  3. Check session JSONL: ~/.openclaw/agents/main/sessions/<new>.jsonl
  4. Observe model_change event shows default model, not haiku

Expected behavior

Per the docs: "Resolution priority: 1. Job payload override (highest)" The isolated cron session should start with the specified model.

Actual behavior

Session transcript shows:

{"type":"model_change","modelId":"claude-sonnet-4-6"}

### OpenClaw version

• OpenClaw: 2026.3.28 (f9b1079)

### Operating system

 macOS 25.3.0 (arm64)

### Install method

npm (global install) - OpenClaw version: 2026.3.28

### Model

anthropic/claude-sonnet-4-6

### Provider / routing chain

- No proxy, no router, no external gateway

### Additional provider/model setup details

_No response_

### Logs, screenshots, and evidence

```shell

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue may be resolved by verifying that the --model flag is correctly propagated to the isolated session initialization.

Guidance

  • Review the openclaw cron add command to ensure the --model flag is correctly set to anthropic/claude-haiku-4-5.
  • Check the payload.model value in the session JSONL file to confirm it matches the specified model.
  • Investigate the session initialization code to determine why the default model claude-sonnet-4-6 is being used instead of the specified model.
  • Verify that there are no other configuration files or environment variables overriding the model selection.

Example

No code snippet is provided as the issue does not contain sufficient information to create a specific example.

Notes

The issue may be related to a bug in the OpenClaw version 2026.3.28, and upgrading to a newer version may resolve the issue. However, without further information, it is unclear if this is the case.

Recommendation

Apply a workaround by manually setting the model in the session initialization code or configuration files, as the current --model flag may not be correctly propagated. This is recommended as the issue is likely related to a configuration or code issue rather than a version problem.

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…

FAQ

Expected behavior

Per the docs: "Resolution priority: 1. Job payload override (highest)" The isolated cron session should start with the specified model.

#API rate limit#retriever error#indexing error#inference speed#output truncation

Still need to ship something?

×6

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

Back to top recommendations

TRENDING