openclaw - 💡(How to fix) Fix [Bug]: WebChat + New Session displays default model but inherits parent's model override

Bug type

Behavior bug (incorrect output/state without a crash)

Beta release blocker

No

Summary

In Control UI WebChat, + New Session can show Default (<configured default model>) in the model picker while the first message is actually routed through the previously selected parent session's non-default model override.

Steps to reproduce

1. Configure the default model as model A.
2. In an existing WebChat dashboard session, select a different model B and send a message so that session persists a user model override.
3. While that session is selected, click + New Session.
4. Observe that the new session's model picker displays Default (model A).
5. Send the first message without changing the displayed picker selection.
6. Inspect the model used for that run or the new session's trajectory.

Expected behavior

A new session that displays Default (model A) should route its first message to model A, or the UI should visibly show that it will inherit model B before the user sends a message.

Selecting the configured default in the new session should also provide a way to override any inherited parent model choice.

Actual behavior

The new session routes its first message to model B, even though its picker displays Default (model A).

In an observed run on OpenClaw 2026.5.19, the child session's first runtime event and all subsequent events used the parent's non-default model. There was no request to the configured default model and no fallback event.

Environment

• OpenClaw version: 2026.5.19
• UI/channel: Control UI WebChat dashboard
• Install method: npm global
• OS: Linux
• Models: reproduced with configured default openai/gpt-5.5 and parent override qwen/qwen3.6-plus
• Routing: direct configured providers; no proxy/router needed to reproduce

Evidence and apparent cause

Inspection of the installed 2026.5.19 distribution shows:

• The + New Session control calls sessions.create with the currently selected dashboard session as parentSessionKey.
• The newly created child has no direct modelOverride; the picker therefore renders the configured default label.
• The first chat.send does not carry the displayed picker model.
• Runtime stored-model resolution falls back to the parent's persisted override when the child has no direct override.
• When the user chooses a model that equals the configured default, sessions.patch clears direct override fields rather than storing an explicit child-level "use default" selection, so the parent override continues to win.

This creates a user-visible mismatch: the model picker says the next request will use the default model, but effective routing uses the parent model.

Impact and severity

• Affected users: Control UI WebChat users who create a session while viewing a session with a non-default model override.
• Severity: moderate; requests silently run on an unexpected model/provider.
• Frequency: deterministic under the reproduction steps above.
• Consequence: unexpected subscription/quota usage, cost/capability changes, and misleading diagnosis as a provider fallback or outage.

Related issues

• #77440 describes a different default-label mismatch involving per-agent defaults. This report concerns inherited parent session overrides on + New Session.
• #83565 requests per-turn overrides. This bug occurs with existing session creation and picker behavior even without requesting a per-turn override.

Suggested behavior

Any of the following would avoid silent misrouting:

• Create a genuinely independent new session from + New Session, unless inheritance is explicitly requested.
• Represent and display the effective inherited model in the child session picker.
• Support an explicit child-level "use configured default, do not inherit parent override" state.