Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On OpenClaw 2026.4.20 (115f05d) in a Feishu-backed main session, sending /model gpt54 returns a success message (已切换到 GPT-5.4 ✅), but the main session does not actually persist the override. Immediately after that, /model status still reports minimax/MiniMax-M2.7, and the stored main-session row in ~/.openclaw/agents/main/sessions/sessions.json shows:

• modelProvider=minimax
• model=MiniMax-M2.7
• liveModelSwitchPending=true
• modelOverrideSource=user

This makes the switch look successful in chat while the session silently remains on the default MiniMax route.

Steps to reproduce

1. Configure aliases including:
   • gpt54 -> openai-codex/gpt-5.4
   • default main agent model primary/fallback currently includes minimax/MiniMax-M2.7
2. Ensure openai-codex/gpt-5.4 itself is actually callable on the host (in my case, direct CLI model runs succeed when the CLI is wrapped with the correct proxy env).
3. Use the existing main session (Feishu delivery context on this host) and send:

   openclaw agent --session-id 370e510f-a483-4967-9c18-a32bdad8f8eb --message "/model gpt54"

4. Observe assistant reply:

   已切换到 GPT-5.4 ✅
   

5. Immediately inspect the stored main session row in ~/.openclaw/agents/main/sessions/sessions.json.
6. Then send:

   openclaw agent --session-id 370e510f-a483-4967-9c18-a32bdad8f8eb --message "/model status"

7. Observe /model status still reports MiniMax instead of GPT-5.4.

Expected behavior

Once /model gpt54 reports success, the main session should persist the override and subsequent turns in that same session should run on openai-codex/gpt-5.4 (or at minimum /model status should report GPT-5.4 until the override is cleared or the model fails and the product explicitly surfaces a fallback state).

Actual behavior

/model gpt54 reports success, but the main session row immediately ends up with:

• modelProvider=minimax
• model=MiniMax-M2.7
• liveModelSwitchPending=true

And /model status reports:

当前模型状态：
- 模型： minimax/MiniMax-M2.7
- 会话： agent:main:main
...
之前切换到 GPT-5.4 的命令似乎未成功持久化，当前仍为 MiniMax-M2.7。

OpenClaw version

2026.4.20 (115f05d)

Operating system

Ubuntu 24.04.4 LTS

Install method

npm global install

Model

Requested session switch target: openai-codex/gpt-5.4 via alias gpt54

Provider / routing chain

openclaw agent --session-id ... -> local gateway -> main session (agent:main:main) -> expected openai-codex/gpt-5.4, actual persisted runtime remains minimax/MiniMax-M2.7

Additional provider/model setup details

Important narrowing evidence from this host:

• Alias list is present and correct:
  • gpt54 -> openai-codex/gpt-5.4
  • gpt53-auth -> openai-codex/gpt-5.3-codex
• Allowed model set includes openai-codex/gpt-5.4
• openai-codex/gpt-5.4 itself is callable successfully on this machine when invoked directly via:

  openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: gpt54-wrapper-ok" --json

  and the result comes back with:
  • provider: openai-codex
  • model: gpt-5.4
• So this does not look like a general auth/provider outage for GPT-5.4 on this host. The failure appears specific to session-level /model persistence on the main session.

Logs, screenshots, and evidence

# 1. Main session accepted the command and claimed success
$ openclaw agent --session-id 370e510f-a483-4967-9c18-a32bdad8f8eb --message "/model gpt54"
已切换到 GPT-5.4 ✅

# 2. Stored main session row immediately after that
sessionId=370e510f-a483-4967-9c18-a32bdad8f8eb
updatedAt=1776825336975
lastChannel=feishu
lastTo=user:ou_b416b3a4bff1d310aa7c9a90a985da86
modelOverrideSource=user
modelProvider=minimax
model=MiniMax-M2.7
liveModelSwitchPending=True

# 3. User-facing status still says MiniMax in the same session
$ openclaw agent --session-id 370e510f-a483-4967-9c18-a32bdad8f8eb --message "/model status"

当前模型状态：
- 模型： minimax/MiniMax-M2.7
- 会话： agent:main:main
...
之前切换到 GPT-5.4 的命令似乎未成功持久化，当前仍为 MiniMax-M2.7。

# 4. Relevant gateway log lines
已切换到 GPT-5.4 ✅

# but stored state still reverts to MiniMax afterwards on the main session row

Additional related local evidence:

• This host previously reproduced auth-related fallback for openai-codex before proxy normalization, but that has since been fixed locally.
• After wrapping the CLI with the proper proxy env, direct openai-codex/gpt-5.4 and openai-codex/gpt-5.3-codex inference both work normally.
• Therefore the /model session persistence failure remained even after the provider itself became healthy.

Impact and severity

Affected users/systems/channels:

• Main-session workflows (Feishu in this case) that rely on /model to switch the active conversation model.

Severity:

• Medium to High. The command returns a misleading success message, but the session stays on the default model.

Frequency:

• Reproduced on this host on 2026.4.20 in the main session.

Consequence:

• Operators believe they switched to GPT-5.4, but subsequent turns still run on MiniMax-M2.7.
• This undermines trust in /model and makes session-level model testing unreliable.

Additional information

This looks closely related to the session-model persistence bug family already discussed in issues like #68472 and #63178, but this report adds a concrete 2026.4.20 reproduction on a main Feishu-backed session where:

• /model gpt54 claims success
• direct GPT-5.4 inference works on the same host
• yet the stored main session row still ends up with MiniMax-M2.7 + liveModelSwitchPending=true

So from this host's perspective, the issue is not just “status text is stale”; the persisted main-session state itself appears wrong after a successful /model acknowledgement.