openclaw - 💡(How to fix) Fix [Bug] sessions.patch returns model not allowed for valid model causing fallback to wrong provider [1 comments, 2 participants]

Bug Description

Symptom: In Feishu (both group chat and DM), every reply from the bot shows:

Agent: main | Model: mimo-v2-flash | Provider: xiaomi
⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

Key behavior: Even running /new to start a completely fresh session does NOT resolve the issue — the error persists immediately after.

Critical observation — error only appears in Feishu, nowhere else:

• Control UI (webchat): works perfectly, no errors shown
• Gateway logs: NO corresponding error log entry for this failure
• OpenClaw UI: does not display this error
• Feishu chat: consistently shows xiaomi/mimo-v2-flash + error message on every reply

This makes the bug extremely difficult to diagnose — there is no log trace to inspect, no OpenClaw UI indicator, and no stack trace. The failure is only visible inside the Feishu message bubble itself.

All Actions Taken (ALL FAILED TO RESOLVE THE ISSUE)

1. Checked ~/.openclaw/agents/main/agent.json — file does not exist; agent config is not stored here.

2. Checked ~/.openclaw/agents/main/agent/models.json — only contains provider definitions; no model selection or routing logic.

3. Found actual config in ~/.openclaw/openclaw.json — main agent correctly set to minimax-portal/MiniMax-M2.7-highspeed in agents.list.

4. Searched trajectory files for xiaomi references — found agent/embedded subsystem was calling xiaomi/mimo-v2.5-pro during tool-call parsing.

5. Disabled xiaomi plugin via gateway config.patch: set plugins.entries.xiaomi.enabled: false and removed xiaomi from models.providers. Gateway hot-reloaded. Issue persisted.

6. Confirmed Feishu group chat receives no messages in logs — oc_5ddf0c56 had 0 log entries. DM (p2p) worked fine.

7. Discovered root cause in gateway logs — sessions.patch consistently returned model not allowed: minimax-m2.7-highspeed.

8. Investigated models.map as potential fix — Rejected by schema validator with error: models: Unrecognized key: "map".

9. Confirmed minimax-portal models array is empty — models.providers.minimax-portal.models was []. Model definitions only in per-agent config.

10. Removed invalid models.map field, restarted gateway — config reverted.

11. Downgraded OpenClaw to 5.5 — issue persisted.

12. Downgraded OpenClaw to 5.6 — issue persisted.

13. Reinstalled OpenClaw to 5.7 (npm uninstall -g openclaw @openclaw/feishu && npm install -g [email protected] @openclaw/[email protected]) — issue persisted.

14. Checked channel-level config — no per-channel model override in channels.feishu. groupPolicy: open, dmPolicy: open, allowFrom: ["*"]. Config is correct.

15. Checked Feishu event subscriptions and permissions — confirmed im.message.receive_v1 subscribed, required permissions (im:message, im:chat, im:message.group_at_msg:readonly) granted.

16. Checked channels.feishu.groupAllowFrom — empty array (no restrictions). Correct.

Root Cause Summary

1. minimax-portal provider in openclaw.json's models.providers has models: [] — no models registered globally.

2. Model definitions only exist in per-agent config (~/.openclaw/agents/main/agent/models.json).

3. sessions.patch validates model aliases against global models.providers. Since minimax-portal has no global models, minimax-m2.7-highspeed is rejected as "model not allowed".

4. Failed model switch → session falls back to wrong provider (xiaomi) → every Feishu reply shows xiaomi error.

5. /new (fresh session) does NOT fix it — issue is in Feishu session initialization/routing, not stale session state.

6. Control UI works because it either bypasses the same validation path or uses a different session context.

7. Issue persists across ALL of: 5.5, 5.6, 5.7 — and after full npm reinstall.

8. Error only visible in Feishu — Control UI shows no error, gateway logs have no corresponding entry, making diagnosis impossible through normal debugging means.

Environment

• OpenClaw: 2026.5.7 (fresh reinstall, also reproduced on 5.5 and 5.6)
• Platform: macOS
• Channel: Feishu (group chat and DM both affected)
• Model configured: minimax-portal/MiniMax-M2.7-highspeed
• Control UI: works normally with no errors
• OpenClaw gateway logs: no error entry for this failure
• Feishu: every reply shows xiaomi model + error

Expected vs Actual Behavior

Expected: A fresh session (/new) in Feishu should start clean with the configured MiniMax model, just like Control UI does. Any errors should be visible in gateway logs and/or OpenClaw UI.

Actual: Even /new produces the same xiaomi/mimo-v2-flash error on every reply in Feishu, while Control UI remains unaffected. The error does not appear in OpenClaw UI or gateway logs — only in the Feishu message itself — making this bug nearly impossible to debug through conventional means.

Questions

1. Why does this error only appear in Feishu and nowhere else (no gateway log, no OpenClaw UI)?
2. Why does /new (fresh session) not resolve the Feishu error — is session state or config shared across new Feishu sessions?
3. Why does the same agent+model config work in Control UI but fail in Feishu — is there a different routing path?
4. Where should model aliases be registered so sessions.patch accepts minimax-m2.7-highspeed?
5. Should failed model switches gracefully fall back to the previous valid model rather than an arbitrary provider?
6. Since this issue persists across 5.5, 5.6, and 5.7, is this a known design limitation?