openclaw - 💡(How to fix) Fix [Bug]: Spawned subagent with explicit model can fail before first attempt with LiveSessionModelSwitchError [1 participants]

Title: [Bug]: Spawned subagent with explicit model can fail before first attempt with LiveSessionModelSwitchError

Bug type: Behavior bug (incorrect output/state without crash) Beta release blocker: No

Summary A spawned runtime="subagent" run with an explicit model (openai-codex/gpt-5.4) failed immediately with LiveSessionModelSwitchError instead of running the child session or surfacing a provider/model error.

Steps to reproduce

1. Start a normal OpenClaw session on 2026.3.28.
2. From that session, call sessions_spawn with runtime: "subagent", mode: "run", and model: "openai-codex/gpt-5.4".
3. Wait for the child run to complete.
4. Observe that the child returns a completion event with status: failed and no model output.

Expected behavior A spawned subagent should run as its own session. With an explicit model, it should either:

• execute on that model successfully, or
• surface the underlying provider/model failure for that child session. It should not fail with a live-session model-switch error before the child produces any model output.

Actual behavior The spawned child failed immediately and the only surfaced error was:

LiveSessionModelSwitchError: Live session model switch requested: openai-codex/gpt-5.4

No child model output was produced, and no provider-level rate-limit/quota error was surfaced in the child completion event.

OpenClaw version 2026.3.28 (f9b1079)

Operating system macOS Darwin 25.3.0 arm64

Install method npm global

Model openai-codex/gpt-5.4

Provider / routing chain openclaw -> openai-codex (ChatGPT Plus OAuth path)

Additional provider/model setup details

• The parent session was running on openai/gpt-5.4 via API key when the subagent was spawned.
• The child run was explicitly requested with model: "openai-codex/gpt-5.4".
• The observed failure happened on a one-shot spawned subagent (runtime: "subagent", mode: "run"), not on a reused existing child session.

Logs, screenshots, and evidence

Child completion error:
LiveSessionModelSwitchError: Live session model switch requested: openai-codex/gpt-5.4

Observed child result:
(no output)

Local source inspection on current main shows a matching error path in src/agents/pi-embedded-runner/run.ts:

const nextSelection = shouldTrackPersistedLiveSelection
  ? resolvePersistedLiveSelection()
  : null;
if (hasDifferentLiveSessionModelSelection(resolveCurrentLiveSelection(), nextSelection)) {
  throw new LiveSessionModelSwitchError(nextSelection);
}

And src/agents/live-model-switch.ts defines the error and persisted-selection lookup:

export class LiveSessionModelSwitchError extends Error {
  constructor(selection: LiveSessionModelSelection) {
    super(`Live session model switch requested: ${selection.provider}/${selection.model}`);
  }
}

Impact and severity Affected: users spawning subagents with an explicit model selection Severity: High (blocks the spawned run entirely) Frequency: Observed on the reproduced run described above Consequence: child tasks fail before first model attempt and can surface a session/model-switch error instead of the underlying provider/model failure

Additional information

• Related reports that appear adjacent in symptom area: #20002, #28925, #49491, #10375.
• A separate contemporaneous direct Codex surface reported a ChatGPT Plus usage cap, but that provider error did not appear in the child completion event here.
• Based on source inspection, one code path worth checking is whether newly spawned child sessions with explicit model selection are being enrolled in persisted live-session model tracking too early, or are reading a persisted session-store selection that does not belong to the freshly spawned child state.
• Possible fix to evaluate: when a spawned subagent has an explicit model, do not throw LiveSessionModelSwitchError unless the child session has first established its own persisted session-store entry; alternatively, have resolveLiveSessionModelSelection() return null when no persisted entry exists instead of synthesizing a default selection.