Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: UI/Interface [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#51023•Fetched 2026-04-08 01:05:25
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
0
Author
juxing009juxing009
Participants
ArtyomkunArtyomkunjuxing009juxing009RyceRyce
Timeline (top)
commented ×2labeled ×2referenced ×1

Web UI model selector sends bare model IDs with wrong provider prefix when multiple providers are configured, causing "model not allowed" errors for non-default providers.

Error Message

Observe error: model not allowed: minimax-portal/<model-id> Expected behavior: Selecting a bailian model in the Web UI should switch to that bailian model without error. Actual behavior: Web UI sends bare model ID (e.g., glm-5) to the gateway, which prepends the wrong provider prefix (minimax-portal/) instead of the correct one (bailian/). Error: model not allowed: minimax-portal/glm-5.

Root Cause

Affected users: Web UI users with multiple model providers configured Severity: High — blocks switching to any non-default provider's models via Web UI Frequency: 100% reproducible Consequence: Users must use Telegram or CLI to switch to bailian models; Web UI model selector is broken for non-default providers Additional information: Root cause: resolveModelRefFromString in auth-profiles-DRjqKE3G.js prepends defaultProvider to bare model IDs without checking the model catalog. When defaultProvider is minimax-portal but the model belongs to bailian, the resolved ref becomes minimax-portal/<model> which fails the allowlist check. Workaround: use Telegram to switch models (does not exhibit this bug).

Fix Action

Fix / Workaround

19:17:57 [ws] ⇄ res ✗ sessions.patch 60ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/qwen3-coder-next 19:18:01 [ws] ⇄ res ✗ sessions.patch 73ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/qwen3.5-plus 19:23:08 [ws] ⇄ res ✗ sessions.patch 63ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/kimi-k2.5 19:26:26 [ws] ⇄ res ✗ sessions.patch 58ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/glm-5 Impact and severity:

Affected users: Web UI users with multiple model providers configured Severity: High — blocks switching to any non-default provider's models via Web UI Frequency: 100% reproducible Consequence: Users must use Telegram or CLI to switch to bailian models; Web UI model selector is broken for non-default providers Additional information: Root cause: resolveModelRefFromString in auth-profiles-DRjqKE3G.js prepends defaultProvider to bare model IDs without checking the model catalog. When defaultProvider is minimax-portal but the model belongs to bailian, the resolved ref becomes minimax-portal/<model> which fails the allowlist check. Workaround: use Telegram to switch models (does not exhibit this bug).

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Web UI model selector sends bare model IDs with wrong provider prefix when multiple providers are configured, causing "model not allowed" errors for non-default providers.

Steps to reproduce

Configure two or more model providers (e.g., minimax-portal + bailian) Open OpenClaw Web UI (Control UI) Navigate to Sessions or Chat tab Select a model belonging to the non-default provider (e.g., bailian/glm-5, bailian/qwen3.5-plus) Observe error: model not allowed: minimax-portal/<model-id> Expected behavior: Selecting a bailian model in the Web UI should switch to that bailian model without error.

Actual behavior: Web UI sends bare model ID (e.g., glm-5) to the gateway, which prepends the wrong provider prefix (minimax-portal/) instead of the correct one (bailian/). Error: model not allowed: minimax-portal/glm-5.

OpenClaw version: 2026.3.13 (61d171a)

Operating system: Windows 11

Model: Any bailian model (qwen3.5-plus, glm-5, kimi-k2.5, etc.)

Provider / routing chain:

Expected behavior

minimax-portal/MiniMax-M2.7 (default provider) bailian/qwen3.5-plus bailian/glm-5 bailian/kimi-k2.5 ...

Actual behavior

19:17:57 [ws] ⇄ res ✗ sessions.patch 60ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/qwen3-coder-next 19:18:01 [ws] ⇄ res ✗ sessions.patch 73ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/qwen3.5-plus 19:23:08 [ws] ⇄ res ✗ sessions.patch 63ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/kimi-k2.5 19:26:26 [ws] ⇄ res ✗ sessions.patch 58ms errorCode=INVALID_REQUEST errorMessage=model not allowed: minimax-portal/glm-5 Impact and severity:

Affected users: Web UI users with multiple model providers configured Severity: High — blocks switching to any non-default provider's models via Web UI Frequency: 100% reproducible Consequence: Users must use Telegram or CLI to switch to bailian models; Web UI model selector is broken for non-default providers Additional information: Root cause: resolveModelRefFromString in auth-profiles-DRjqKE3G.js prepends defaultProvider to bare model IDs without checking the model catalog. When defaultProvider is minimax-portal but the model belongs to bailian, the resolved ref becomes minimax-portal/<model> which fails the allowlist check. Workaround: use Telegram to switch models (does not exhibit this bug).

OpenClaw version

OpenClaw 2026.3.13 (61d171a)

Operating system

Windows11

Install method

openclaw gateway

Model

MiniMax-M2.7

Provider / routing chain

https://api.minimaxi.com/anthropic

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

To fix the issue, we need to modify the resolveModelRefFromString function in auth-profiles-DRjqKE3G.js to correctly prepend the provider prefix to bare model IDs.

Here are the steps:

  • Check the model catalog to determine the correct provider for the given model ID
  • Prepend the correct provider prefix to the model ID
  • Return the resolved model reference

Example code:

function resolveModelRefFromString(modelId) {
  // Check the model catalog to determine the correct provider
  const provider = getModelProviderFromCatalog(modelId);
  
  // Prepend the correct provider prefix to the model ID
  const resolvedModelRef = `${provider}/${modelId}`;
  
  return resolvedModelRef;
}

// Helper function to get the model provider from the catalog
function getModelProviderFromCatalog(modelId) {
  // Assume a model catalog object with provider information
  const modelCatalog = {
    'qwen3.5-plus': 'bailian',
    'glm-5': 'bailian',
    'kimi-k

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

minimax-portal/MiniMax-M2.7 (default provider) bailian/qwen3.5-plus bailian/glm-5 bailian/kimi-k2.5 ...

#api#ssr#installation#tensor shape#API routing#API middleware#SSR setup#request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING