What happened?

In a WhatsApp direct session, /new does not clear the session-level model override.

It starts a fresh session ID, but the new session still inherits the old providerOverride / modelOverride, so the chat remains pinned to the previous model instead of falling back to the configured default.

Additionally, the reset notice can show a default: model that does not match the current configured agents.defaults.model.primary.

Repro

Environment:

• OpenClaw 2026.3.24
• channel: WhatsApp direct chat
• configured default model:
  • agents.defaults.model.primary = ollama/minimax-m2.7:cloud

Steps:

1. In WhatsApp direct chat, set a session override:
   • /model gpt
   • or any non-default model such as openai-codex/gpt-5.4
2. Confirm with /status
3. Send /new
4. Send /status again

Expected

After /new (or /reset):

• a fresh session should not keep the previous modelOverride/providerOverride
• the session should resolve to the configured default model from:
  • agents.defaults.model.primary
• the reset banner should show the actual configured default model

Actual

After /new:

• the session still uses the previous override model
• the WhatsApp session key remains the same logical route and the new session entry inherits the previous override
• the reset banner can show a default: model that does not match the current config

Example observed behavior:

• configured default: ollama/minimax-m2.7:cloud
• active override before reset: openai-codex/gpt-5.4
• after /new: still openai-codex/gpt-5.4
• reset notice showed:
  • ✅ New session started · model: openai-codex/gpt-5.4 (default: litellm/gpt-5.3-chat)

Docs expectation

The docs imply reset should start fresh:

• docs/concepts/session.md says /new / /reset start a fresh session ID
• docs/concepts/model-failover.md says session pinning is reused until the session is reset

Code evidence

Installed bundle still preserves the model override on reset:

dist/pi-embedded-BaSvmUpW.js

if (resetTriggered && entry) {
  persistedThinking = entry.thinkingLevel;
  persistedVerbose = entry.verboseLevel;
  persistedReasoning = entry.reasoningLevel;
  persistedTtsAuto = entry.ttsAuto;
  persistedModelOverride = entry.modelOverride;
  persistedProviderOverride = entry.providerOverride;
  ...
}

and later writes it back into the session entry.

So /new is effectively “history fresh” but not “model fresh”.

Related issues

This looks related to prior reports in the same area:

• /new / /reset does not clear session-level model override #27058 /new / /reset does not clear session-level model override
• /model default resolves to 'anthropic/default' instead of resetting to configured default model #13982 /model default resolves to 'anthropic/default' instead of resetting to configured default model
• Session modelOverride persists across gateway restarts, silently overrides config default #51251 Session modelOverride persists across gateway restarts, silently overrides config default

This may be a regression or an incomplete fix in the current reset path.

Suggested fix

• On /new and /reset, do not carry over:
  • modelOverride
  • providerOverride
• Ensure the reset notice default model is resolved from the current live config via the same path used for normal default model resolution (agents.defaults.model.primary)