openclaw - 💡(How to fix) Fix Bug: Control UI (TUI/WebChat) sessions auto-select wrong authProfileOverride (deepseek instead of minimax) at creation

Bug type

Behavior bug (incorrect state without crash)

Summary

Control UI / WebChat (TUI) sessions auto-select the wrong authProfileOverride at session creation. For an agent configured with minimax/MiniMax-M2.7 as its primary model and minimax:global as the expected auth profile, new TUI sessions start with authProfileOverride: "deepseek:default" (source: "auto"), pinning the session to deepseek/deepseek-v4-flash instead of the configured MiniMax. Telegram sessions on the same agent correctly get minimax:global.

This is a variant of the same auth-profile auto-selection bug reported in #62412 and tracked in unmerged PR #62710. That issue covered the rate-limited backup profile variant; this issue covers the "wrong profile from session start" variant.

Environment

• OpenClaw version: 2026.5.19 (a185ca2)
• OS: Linux 6.6.114.1-microsoft-standard-WSL2 (x64)
• Node: v24.15.0
• Gateway mode: local (systemd user service)
• Channel: WebChat / Control UI (TUI sessions)
• Gateway uptime: ~7h at time of observation (fresh session)

Configuration (simplified)

Agent config:

{
  "id": "jordi",
  "model": {
    "primary": "minimax/MiniMax-M2.7",
    "fallbacks": ["ollama/minimax-m2.7:cloud", "ollama/qwen3-coder-next:cloud", "deepseek/deepseek-v4-flash", ...]
  }
}

Auth profiles:

{
  "minimax:global": { "provider": "minimax", "mode": "api_key" },
  "deepseek:default": { "provider": "deepseek", "mode": "api_key" },
  "ollama:default": { "provider": "ollama", "mode": "api_key" }
}

Steps to Reproduce

1. Configure an agent with minimax/MiniMax-M2.7 primary and minimax:global auth profile
2. Open a new WebChat / Control UI (TUI) session with that agent
3. Check sessions.json for the new session's model/auth fields
4. Compare with Telegram sessions for the same agent

Expected Behavior

• New TUI sessions should use the agent's configured primary model (minimax/MiniMax-M2.7)
• The auto-selected auth profile should match — minimax:global, not deepseek:default
• All session types (Telegram, TUI, subagent) should consistently resolve to the same default auth profile for the same agent

Actual Behavior

• New TUI sessions get authProfileOverride: "deepseek:default" (source: "auto") pinned at session creation
• This forces the session onto deepseek/deepseek-v4-flash, overriding the agent's configured primary
• Telegram sessions on the same agent correctly get minimax:global
• Subagent sessions (no auto-override) correctly use the agent config default
• The override source "auto" means the gateway's auto-selection logic is choosing deepseek over minimax for TUI sessions specifically

Evidence

Session-to-Auth-Profile Mapping (sessions.json, agent:jordi)

Session Transcript (sanitized)

The very first event in the affected TUI session's transcript is a model_change to deepseek with no parentId — meaning it was set at session creation, not switched mid-conversation:

{"type":"model_change","parentId":null,
 "provider":"deepseek","modelId":"deepseek-v4-flash"}

Root Cause

The resolveSessionAuthProfileOverride function (or equivalent session-init path) does not consistently resolve to the agent's configured default auth profile when creating new TUI sessions. Unlike Telegram sessions (which correctly get minimax:global), TUI sessions route through a different creation path that picks deepseek:default.

PR #62710 (fix(auth): stop new sessions inheriting auto-selected auth profile overrides) was opened to address the related #62412 but remains unmerged. The fix in that PR addresses the /new//reset cleanup path but may not fully address the root cause of incorrect auto-selection at TUI session creation.

Related Issues

• #62412 — New sessions inherit authProfileOverride from cooldown/rate-limited backup profile (same bug class, closed as superseded by unmerged PR #62710)
• #62710 — Unmerged PR attempting fix for #62412
• #81837 — Dashboard model switch clears authProfileOverride, causing API auth failure
• #51251 — Session modelOverride persists across gateway restarts
• #83731 — Feature request: gateway.routing.persist_auto_fallback config flag