PR #58103: fix: catch LiveSessionModelSwitchError in cron isolated agent runs

• Repository: openclaw/openclaw
• Author: techfitmaster
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/58103

Description (problem / solution / changelog)

Summary

Fixes a regression where cron jobs configured with a specific payload.model override always ran with the agent's default model instead of the specified override.

Root Cause

When runEmbeddedPiAgent detects a model mismatch between the current in-flight session and the persisted session store, it throws LiveSessionModelSwitchError. The main agent runner already handles this in a retry loop. However, the cron isolated session runner (cron/isolated-agent/run.ts) had no such retry logic — so any cron job with a payload.model different from the agent's primary model would hit this error and silently fall back to the agent default.

Changes

• Wrap the initial runPrompt(commandBody) call in a while(true) retry loop that catches LiveSessionModelSwitchError
• On catch: update provider/model state, update the session entry, persist the corrected model, then continue
• Mirrors the existing retry pattern in agent-runner-execution.ts exactly

Files Changed

• src/cron/isolated-agent/run.ts — adds LiveSessionModelSwitchError import and retry loop

Fixes openclaw/openclaw#58065

Changed files

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

PR #58294: fix(cron): prevent agent default model from overriding cron payload model

• Repository: openclaw/openclaw
• Author: aaronagent
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/58294

Description (problem / solution / changelog)

Summary

• Problem: When editing a cron job in the web UI and selecting a model via "Advanced", the cron execution ignores the override and uses the agent's default model instead (#58065).
• Why it matters: Users who configure per-cron model overrides (e.g. cost-optimized models for scheduled tasks) always get billed for the more expensive agent default model, and get results from the wrong model.
• What changed: When the cron payload carries an explicit model override, fallbacksOverride is now always a defined array (empty [] when no fallbacks are configured), which prevents runWithModelFallback from silently appending the agent's configured primary model as a last-resort fallback candidate.
• What did NOT change (scope boundary): Cron jobs without a payload model override still get the full fallback chain including the agent primary model. The model resolution logic in resolveCronModelSelection is unchanged. Payload-level fallbacks arrays are still respected when present.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #58065
• Related #57972, #57206
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: In src/cron/isolated-agent/run.ts, the fallbacksOverride parameter passed to runWithModelFallback was computed as payloadFallbacks ?? resolveAgentModelFallbacksOverride(params.cfg, agentId). When neither the cron payload fallbacks array nor the per-agent model fallbacks were configured (both undefined), fallbacksOverride resolved to undefined. Inside runWithModelFallback → resolveFallbackCandidates (model-fallback.ts:399), when fallbacksOverride === undefined, the agent's configured primary model is appended as the last fallback candidate. If the cron-selected model encounters any transient failure (rate limit, model-not-found in registry, overloaded, etc.), the fallback chain would reach and succeed on the agent's primary model — making it appear as though the cron model override was completely ignored.
• Missing detection / guardrail: No test verified that fallbacksOverride was a defined array (rather than undefined) when a cron payload model override was present.
• Prior context: PR #57972 fixed LiveSessionModelSwitchError handling in cron isolated sessions but did not address this separate path where the agent default silently wins through the fallback candidate list.
• Why this regressed now: The fallback behavior has always existed in runWithModelFallback, but it became more visible with the recent model provider expansions (multi-provider setups with qwen/gemini/codex) where transient failures are more common across provider boundaries.
• If unknown, what was ruled out: Model resolution in resolveCronModelSelection is correct — the payload model IS resolved and passed to runWithModelFallback as provider/model. The issue is exclusively in the fallback candidate list construction.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/cron/isolated-agent/run.cron-model-override-forwarding.test.ts
• Scenario the test should lock in: When a cron payload has model set, runWithModelFallback must receive a defined fallbacksOverride array (not undefined), preventing the agent primary from being silently appended as a fallback candidate.
• Why this is the smallest reliable guardrail: Directly asserts on the parameter passed to runWithModelFallback, which is the exact boundary where the bug manifests.
• Existing test that already covers this (if any): run.cron-model-override.test.ts covers pre-run session persistence but did not verify the fallback candidate behavior.

User-visible / Behavior Changes

• Cron jobs with a payload model override will no longer silently fall back to the agent's default model on transient failures. Instead, the run will fail with an error if the override model is unavailable, giving users clear feedback.

Diagram (if applicable)

Before:
[cron job: model=gemini] -> runWithModelFallback(fallbacksOverride=undefined)
  -> candidates: [gemini, ..., agent-default-opus]
  -> gemini rate-limited -> tries opus -> succeeds with wrong model

After:
[cron job: model=gemini] -> runWithModelFallback(fallbacksOverride=[])
  -> candidates: [gemini]
  -> gemini rate-limited -> no more candidates -> error (correct)

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22+
• Model/provider: Any multi-provider setup (e.g. qwen>gemini>codex)
• Integration/channel (if any): Web UI cron editor

Steps

1. Configure an agent with a default model (e.g. anthropic/claude-opus-4-6)
2. Create a cron job, click "Advanced", select a different model (e.g. google/gemini-2.0-flash)
3. Run the cron job

Expected

• The cron job executes using google/gemini-2.0-flash

Actual

• The cron job executes using anthropic/claude-opus-4-6 (the agent default)

Evidence

• Failing test/log before + passing after
  • New test file: src/cron/isolated-agent/run.cron-model-override-forwarding.test.ts (5 tests)
  • All 155 existing isolated-agent tests continue to pass

Human Verification (required)

• Verified scenarios:
  • Cron payload with model override: fallbacksOverride is a defined array
  • Cron payload without model override: fallbacksOverride is undefined (existing behavior preserved)
  • Cron payload with both model and fallbacks: explicit fallbacks array is used
  • Model override is forwarded to runEmbeddedPiAgent via passthrough
• Edge cases checked:
  • Empty payload.model string → treated as no override
  • Payload with fallbacks array → fallbacks used as-is
  • Agent-level fallbacks configured → used when payload model override is present
• What you did not verify: Live multi-provider execution (no access to configured providers)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Cron jobs with model overrides that previously "worked" by silently falling back will now fail with an error if the override model is unavailable.
  • Mitigation: This is the correct behavior — users should see an error when their chosen model is unavailable, not silently get results from a different model. Agent-level fallbacks are still used when configured.

🤖 Generated with Claude Code

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/cron/isolated-agent/run.cron-model-override-forwarding.test.ts (added, +249/-0)
• src/cron/isolated-agent/run.runtime.ts (modified, +1/-0)
• src/cron/isolated-agent/run.test-harness.ts (modified, +16/-0)
• src/cron/isolated-agent/run.ts (modified, +17/-3)

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

• Repository: openclaw/openclaw
• Author: Starhappysh
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/58998

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

• Repository: openclaw/openclaw
• Author: Starhappysh
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/59000

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)