OpenClaw Control UI not replying. | Friends of the Crustacean 🦞🤝 | Page 1

wintry oasis Apr 13, 2026, 2:34 PM

#

I was trying to connect my laptop to openclaw via tailscale. Now its not replying. A blank message appears when i message anything.

ashen remnantBOT Apr 13, 2026, 2:34 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

tired shaleBOT Apr 13, 2026, 2:34 PM

#

sweet helmBOT Apr 13, 2026, 2:37 PM

#

First, can you paste openclaw --version?

This smells like the Control UI got switched onto the wrong Tailscale URL/auth path. Plain http://<tailscale-ip>:18789 can be flaky here because the browser is not in a secure context.

Run these on the gateway host:

openclaw status
openclaw gateway status
openclaw models status
openclaw logs --follow

Most likely fix:

openclaw gateway --tailscale serve

#

Then open the Serve HTTPS URL:

https://<magicdns>/

Also check:

If this is a new browser/device, approve it:

openclaw devices list
openclaw devices approve <requestId>

If the UI asks for auth, paste the token/password in Overview → Gateway Access.
Quick sanity test: on the gateway machine itself, open http://127.0.0.1:18789/ or run openclaw dashboard. If local works but Tailscale does not, the problem is definitely the remote Tailscale path.

Paste:

openclaw --version

#

whether you're opening http://<tailscale-ip>:18789 or https://<magicdns>/
the log lines right after you send a message

Docs: https://docs.openclaw.ai/help/faq https://docs.openclaw.ai/web/control-ui https://docs.openclaw.ai/gateway/tailscale https://docs.openclaw.ai/gateway/troubleshooting#dashboard-control-ui-connectivity

wintry oasis Apr 13, 2026, 3:05 PM

#

OS │ linux 6.18.7-76061807-generic (x64) · node 22.22.2 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ serve · pop-os.taild2117f.ts.net · https://pop-os.taild2117f.ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.12 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 31ms · │
│ │ auth token · pop-os (192.168.1.34) app 2026.4.12 linux 6.18.7- │
│ │ 76061807-generic │
│ Gateway self │ pop-os (192.168.1.34) app 2026.4.12 linux 6.18.7-76061807-generic │
│ Gateway service │ systemd installed · enabled · running (pid 77904, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 · 1 bootstrap file present · sessions 4 · default main active │
│ │ 37m ago │
│ Memory │ 0 files · 0 chunks · dirty · sources memory · plugin memory-core · │
│ │ vector ready · fts ready · cache on (0) │
│ Plugin compatibility │ none │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Tasks │ none │
│ Heartbeat │ 6h (main) │
│ Sessions │ 4 active · default MiniMax-M2.7 (200k ctx) · ~/.openclaw/agents/ │
│ │ main/sessions/sessions.json

sweet helmBOT Apr 13, 2026, 3:06 PM

#

Nice, this helps a lot.

Your Tailscale Serve path looks up, so I don’t think the network side is the main problem now. The next suspects are the agent/model run itself, or a stuck bootstrap state.

A couple things stand out:

Gateway is reachable and serving fine.
Tailscale Serve is active at https://pop-os.taild2117f.ts.net.
1 bootstrap file present is a little suspicious. If onboarding already finished, BOOTSTRAP.md normally should be gone.

Please run these next, they’re read-only:

openclaw models status
ls -l ~/.openclaw/workspace/BOOTSTRAP.md
openclaw logs --follow

#

Then, while openclaw logs --follow is running, send one test message from the Control UI and paste the log lines that appear right after.

Also, one quick yes/no check:

Does chat fail only on the Tailscale URL
https://pop-os.taild2117f.ts.net
or does it also fail on local
http://127.0.0.1:18789/

If it fails on both, it’s probably agent/model-side.
If local works but Tailscale fails, then we can zoom back in on browser/auth/device handling.

Relevant docs: https://docs.openclaw.ai/help/faq https://docs.openclaw.ai/gateway/troubleshooting#dashboard-control-ui-connectivity https://docs.openclaw.ai/start/bootstrapping

wintry oasis Apr 13, 2026, 3:07 PM

#

leave tailscale. im not getting replies from my openclaw even on my own p

sweet helmBOT Apr 13, 2026, 3:07 PM

#

Yep, agreed, if it also fails locally then Tailscale is probably a red herring.

At that point the usual meaning of a blank assistant bubble is, “the UI sent the message, but the agent run died before any text came back.”

Please run these on the box:

openclaw models status
ls -l ~/.openclaw/workspace/BOOTSTRAP.md
openclaw logs --follow

Then, while openclaw logs --follow is running, send one local test message and paste the new log lines.

Why these:

models status checks whether your default model is actually usable.
BOOTSTRAP.md still being present can be a bad sign if onboarding already finished.

#

the log tail should show the real failure immediately.

If you want, also tell me whether the UI shows tokens staying at 0 after you send. That’s a strong hint the agent never started.

wintry oasis Apr 13, 2026, 3:08 PM

#

🦞 OpenClaw 2026.4.12 (1c0672b)
Open source means you can see exactly how I judge your config.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : minimax-portal/MiniMax-M2.7
Fallbacks (0) : -
Image model : google/gemini-3-flash-preview
Image fallbacks (0): -
Aliases (2) : minimax-m2.7 -> minimax-portal/MiniMax-M2.7, gemini-flash -> google/gemini-3-flash-preview
Configured models (2): minimax-portal/MiniMax-M2.7, google/gemini-3-flash-preview

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): minimax-portal (1)

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyCl...9RzwmTtc
minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

minimax-portal
- minimax-portal:default ok expires in 359d

sweet helmBOT Apr 13, 2026, 3:09 PM

#

Nice, that rules out the obvious auth problem.

Your model auth looks healthy:

minimax-portal/MiniMax-M2.7 is configured
OAuth is present
token expiry looks fine

So this is probably not “bad API key / missing model auth”.

The next 2 things I still want are:

ls -l ~/.openclaw/workspace/BOOTSTRAP.md
openclaw logs --follow

Then, while openclaw logs --follow is running, send one test message and paste the new log lines.

#

Why I’m asking:

if BOOTSTRAP.md is still there after setup, that can cause weird stuck behavior
the log tail should show whether the run is crashing before it can stream a reply

If you’re looking at the UI while testing, also tell me whether the token count stays at 0 after you send. That’s a useful clue.

wintry oasis Apr 13, 2026, 3:10 PM

#

-rw-rw-r-- 1 thz0001 thz0001 1471 Apr 6 23:03 /home/thz0001/.openclaw/workspace/BOOTSTRAP.md

sweet helmBOT Apr 13, 2026, 3:10 PM

#

Aha, that’s very likely it.

If onboarding/bootstrap is already finished, BOOTSTRAP.md should not still be there. A leftover BOOTSTRAP.md can keep the agent stuck in first-run/bootstrap mode and cause the kind of no-reply behavior you’re seeing.

If you’ve already completed setup, I’d try this:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then test the Control UI again locally.

If you never actually finished the bootstrap ritual, then don’t move it yet, finish that flow first instead.

Docs: https://docs.openclaw.ai/start/bootstrapping

#

If it still blank-replies after that, paste the fresh openclaw logs --follow output right after one test message.

wintry oasis Apr 13, 2026, 3:13 PM

#

15:11:50+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"71db0b9f-aa66-445b-8d76-25ab676c4d24","isError":true,"error":"404 <html>\r\n<head><title>404 Not Found</title></head>\r\n<body>\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>","failoverReason":"model_not_found","model":"MiniMax-M2.7","provider":"minimax-portal","rawErrorPreview":"404 <html>\r\n<head><title>404 Not Found</title></head>\r\n<body>\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>","rawErrorHash":"sha256:671f307a1bce","providerRuntimeFailureKind":"unknown"} embedded run agent end
15:11:50+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"auth_profile_failure_state_updated","tags":["error_handling","auth_profiles","cooldown"],"runId":"71db0b9f-aa66-445b-8d76-25ab676c4d24","profileId":"sha256:9e08bd6be9c1","provider":"minimax-portal","reason":"model_not_found","windowType":"cooldown","windowReused":false,"previousErrorCount":0,"errorCount":1,"cooldownUntil":1776093140754,"failureCounts":{"model_not_found":1}} auth profile failur state updated
15:11:50+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"71db0b9f-aa66-445b-8d76-25ab676c4d24","stage":"assistant","decision":"surface_error","failoverReason":"model_not_found","profileFailureReason":"model_not_found","provider":"minimax-portal","model":"MiniMax-M2.7","profileId":"sha256:9e08bd6be9c1","fallbackConfigured":false,"timedOut":false,"aborted":false,"rawErrorPreview":"404 <html>\r\n<head><title>404 Not Found</title></head>\r\n<body>\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>","rawErrorHash":"sha256:671f307a1bce","providerRuntimeFailureKind":"unknown"}

#

embedded run failover decision

sweet helmBOT Apr 13, 2026, 3:14 PM

#

Yep, we found the real blocker.

It’s not Tailscale now. The run is failing because MiniMax is returning:

provider: minimax-portal
model: MiniMax-M2.7
error: 404 ... model_not_found

So OpenClaw is sending the request, but the selected MiniMax model/route is not being accepted upstream. Because you have no fallbacks configured, that turns into the blank reply.

First check this:

openclaw models list --provider minimax-portal

What I’d expect:

#

if MiniMax-M2.7 is not in that list, your current MiniMax OAuth setup is mismatched
if the command itself errors, same story

Then fix it by redoing MiniMax auth with the correct region:

openclaw onboard --auth-choice minimax-global-oauth

or, if you’re using the China endpoint:

openclaw onboard --auth-choice minimax-cn-oauth

If openclaw models list --provider minimax-portal shows a different working model, you can also switch to one of the exact ids from that list.

#

Also, your leftover BOOTSTRAP.md is still odd, but this MiniMax 404 model_not_found is the immediate reason you’re getting blank replies.

Docs: https://docs.openclaw.ai/providers/minimax https://docs.openclaw.ai/concepts/models

#

Yep, that line is the effect, not the root cause.

In plain English it means:

the primary model call failed
OpenClaw checked whether it could fall back
it couldn’t, because fallbackConfigured:false
so it surfaced the error instead

The important bits from your log are:

failoverReason:"model_not_found"
provider:"minimax-portal"
model:"MiniMax-M2.7"
decision:"surface_error"

So the actual problem is still: MiniMax returned 404 / model_not_found for your selected model, and there was no backup model to try.

#

Next step is still:

openclaw models list --provider minimax-portal

If that doesn’t show MiniMax-M2.7, redo MiniMax onboarding for the correct region or switch to one of the exact models that list shows.

wintry oasis Apr 13, 2026, 3:17 PM

#

openclaw models list --provider minimax-portal

🦞 OpenClaw 2026.4.12 (1c0672b)
Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

Model Input Ctx Local Auth Tags
minimax-portal/MiniMax-M2.7 text 195k no yes default,configured,alias:minimax-m2.7

sweet helmBOT Apr 13, 2026, 3:18 PM

#

That’s helpful. It means OpenClaw’s local model catalog is fine. It knows about minimax-portal/MiniMax-M2.7.

So the problem is narrower now:

local config/catalog: looks OK
live runtime call to MiniMax: still returns 404 model_not_found

In other words, this looks more like a MiniMax portal auth/endpoint mismatch than a missing model entry in OpenClaw.

One more good check before changing anything:

openclaw models status --probe

If MiniMax still looks bad there, I’d re-run MiniMax onboarding with the correct region:

#

openclaw onboard --auth-choice minimax-global-oauth

or, for China:

openclaw onboard --auth-choice minimax-cn-oauth

So, short version: models list tells us “OpenClaw knows the model name,” but your logs tell us “the live MiniMax endpoint is rejecting it.” That’s why chat is blank-replying.

wintry oasis Apr 13, 2026, 3:21 PM

#

◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : minimax-portal/MiniMax-M2.7
Fallbacks (0) : -
Image model : google/gemini-3-flash-preview
Image fallbacks (0): -
Aliases (2) : minimax-m2.7 -> minimax-portal/MiniMax-M2.7, gemini-flash -> google/gemini-3-flash-preview
Configured models (2): minimax-portal/MiniMax-M2.7, google/gemini-3-flash-preview

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): minimax-portal (1)

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyCl...9RzwmTtc
minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

minimax-portal
- minimax-portal:default ok expires in 359d

Auth probes

│ google/gemini-3-flash- │ google:default (api_key) │ ok · 9.9s │
│ preview │ │ │
│ minimax-portal/MiniMax- │ minimax-portal:default │ ok · 5.3s │
│ M2.7 │ (oauth) │ │
│ ollama/- │ ollama:default (api_key) │ no_model · - │
│ │ │ ↳ No model available for probe │

sweet helmBOT Apr 13, 2026, 3:22 PM

#

Oh, that’s actually a really useful clue.

Since models status --probe is OK, but normal chat runs still 404, my best guess now is Fast mode.

Why:

MiniMax docs say Fast mode rewrites MiniMax-M2.7 to MiniMax-M2.7-highspeed on the streaming path.
Your models list --provider minimax-portal only showed MiniMax-M2.7, not MiniMax-M2.7-highspeed.
That would explain the weird combo of:
- probe to MiniMax-M2.7 = OK
- real chat run = 404 model_not_found

Try this first:

/fast off

#

Or disable Fast in the session/UI settings, then send one normal message again.

If that fixes it, we found it. Then the issue is not Tailscale, it’s the session using a MiniMax fast-path model that your current MiniMax portal setup is not serving.

Docs: https://docs.openclaw.ai/providers/minimax https://docs.openclaw.ai/tools/thinking

wintry oasis Apr 13, 2026, 3:23 PM

#

i tell you the last thing it did before it stopped replying.

sweet helmBOT Apr 13, 2026, 3:23 PM

#

Yes please, that’s probably the missing clue.

Paste the exact last thing it did before it broke, ideally:

the last message/command you sent
the last reply it gave
whether that happened in the local UI or the Tailscale URL
if you changed any session toggles right before, like Fast, Reasoning, or model selection

Even a rough “I clicked X, then sent Y” is useful.

wintry oasis Apr 13, 2026, 3:23 PM

#

Tool input

{
"command": "openclaw config get gateway.controlUi 2>&1"
}

#

Tool output

Config path not found: gateway.controlUi

(Command exited with code 1)

#

{
"command": "openclaw config set gateway.controlUi.allowedOrigins "['https://pop-os.taild2117f.ts.net']" 2>&1"
}

sweet helmBOT Apr 13, 2026, 3:24 PM

#

That specific command is pretty harmless. It’s just a read-only config lookup:

openclaw config get gateway.controlUi

So I don’t think that command itself bricked anything.

What still matters more is this combo you already showed:

probe to minimax-portal/MiniMax-M2.7 = ok
real assistant run = 404 model_not_found

That still points me back to session-level runtime state, especially Fast mode or a session override, not the config-get command.

So I’d still try this exact test next:

#

/fast off

Then send one normal message.

If you want, also check the session/UI settings and tell me:

is Fast on?
is there any custom session model override?
does a brand new session behave the same way?

wintry oasis Apr 13, 2026, 3:24 PM

#

Config overwrite: /home/thz0001/.openclaw/openclaw.json (sha256 f84d8e492b5b9a237975711f170a3a1d61527265780b8689c181a93f7e99d2d0 -> 6bb9028d6f6a0dff0a51bb6e1f5738c39ebbe968efde9a84e17421213e73d0c7, backup=/home/thz0001/.openclaw/openclaw.json.bak)
Updated gateway.controlUi.allowedOrigins. Restart the gateway to apply.

sweet helmBOT Apr 13, 2026, 3:24 PM

#

That output is not fatal.

Config path not found: gateway.controlUi just means you don’t have an explicit gateway.controlUi block in ~/.openclaw/openclaw.json. Defaults can still be in effect. That error by itself should not kill all future replies.

So I would not chase that anymore.

The fastest next checks are:

Turn Fast off
```
/fast off
```
Try a brand new session

Why I’m pushing those:

the failed config read is harmless

#

your logs still show the real breakage happening at assistant runtime
a fresh session helps tell us whether this is a stuck session state vs a broader model/runtime problem

If a new session works, the old session got wedged.
If a new session also blank-replies, then we go back to the MiniMax runtime path.

wintry oasis Apr 13, 2026, 3:24 PM

#

Tool input

{
"command": "systemctl --user restart openclaw-gateway 2>&1; echo "done"",
"timeout": 15
} Command aborted by signal SIGTERM

sweet helmBOT Apr 13, 2026, 3:25 PM

#

Ah, that is much more relevant.

If that config set gateway.controlUi.allowedOrigins command actually succeeded, and it only allowed:

https://pop-os.taild2117f.ts.net

then your local browser origin would no longer be allowed. That can absolutely make the local Control UI behave weirdly or stop connecting properly.

First, check the current value:

openclaw config get gateway.controlUi.allowedOrigins

If it only contains the Tailscale origin, change it so it includes all full origins you actually use, for example:

#

openclaw config set gateway.controlUi.allowedOrigins '["https://pop-os.taild2117f.ts.net","http://127.0.0.1:18789","http://localhost:18789"]'

Then restart the gateway:

openclaw gateway restart

One important note, this may explain the UI/connectivity side, but your earlier MiniMax 404 model_not_found is still a separate clue for the assistant runtime side. So if it still blank-replies after fixing allowedOrigins, I’d go right back to trying:

/fast off

Docs: https://docs.openclaw.ai/web/control-ui https://docs.openclaw.ai/gateway/troubleshooting#dashboard-control-ui-connectivity

#

Yep, that explains a lot.

The assistant did rewrite your config, and the output says:

gateway.controlUi.allowedOrigins was updated
the gateway needed a restart
there’s a backup at ~/.openclaw/openclaw.json.bak

If that change only allowed the Tailscale origin, it would easily break the local Control UI origin too.

I’d recover in this order:

openclaw config set gateway.controlUi.allowedOrigins '["https://pop-os.taild2117f.ts.net","http://127.0.0.1:18789","http://localhost:18789"]'
openclaw gateway restart

#

Then test the local UI again.

If the UI connects again but chat still blank-replies, do this next:

/fast off

So I think you may have had two issues layered together:

allowedOrigins got narrowed and needed a restart
MiniMax runtime may still be tripping on the fast-path model

Good news, this is starting to make sense now.

#

That SIGTERM is actually pretty normal here.

If the assistant/tool tried to restart the gateway from inside a gateway-connected session, the session often gets cut off mid-command when the gateway restarts. So:

Command aborted by signal SIGTERM does not automatically mean the restart failed
it can just mean the control session died because the gateway restarted

I’d do this next, from a normal terminal:

openclaw gateway status

If it’s up, reload the UI and test again.

If you want to restart it cleanly yourself, I’d use:

#

openclaw gateway restart

instead of relying on the in-chat tool run.

So the immediate checklist is:

openclaw gateway status
reload local UI
if chat still blank-replies, try /fast off

We’re definitely in “recovering from a bad self-edit/restart” territory now, not just Tailscale weirdness.

wintry oasis Apr 13, 2026, 3:28 PM

#

i did this openclaw config set gateway.controlUi.allowedOrigins '["https://pop-os.taild2117f.ts.net","http://127.0.0.1:18789","http://localhost:18789"]'
openclaw gateway restart but still not working

sweet helmBOT Apr 13, 2026, 3:28 PM

#

Okay, good, that rules out the allowedOrigins fix as the main blocker.

At this point I’d stop changing gateway config. The remaining evidence still points at the MiniMax runtime path, not the Control UI.

Please do these two clean tests:

Start a brand new session
In that new session, make sure Fast is off before sending anything

If chat commands still work, do:

/fast off

Then send a simple hi.

#

Why this matters:

we already fixed the browser-origin side
your earlier logs still showed the assistant run failing at the model layer
a new session clears any weird per-session state/overrides

If the new session also blank-replies, please paste the fresh log lines after the restart, because if it still says model_not_found then the remaining fix is MiniMax-specific, not Control UI-specific.

wintry oasis Apr 13, 2026, 3:34 PM

#

did all this stil not working.

sweet helmBOT Apr 13, 2026, 3:35 PM

#

Got it. Since you already tried the session/UI fixes, I’d stop poking at Tailscale and treat this as a wedged local setup.

My recommendation is this order:

Remove the stale bootstrap file
If setup is already complete, BOOTSTRAP.md should not still be there.

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

If it still fails, re-do MiniMax auth
```
openclaw onboard --auth-choice minimax-global-oauth
```
or, if you use the China endpoint:

#

   openclaw onboard --auth-choice minimax-cn-oauth

If it still fails after both, I’d call it bug territory.
The combo of:
- models status --probe = ok
- normal assistant run = 404 model_not_found
is weird enough that it should be filed here: https://github.com/openclaw/openclaw/issues

If you want, paste the result after step 1 first and I’ll stay with you on it.

wintry oasis Apr 13, 2026, 3:55 PM

#

should i choose minimax/MiniMax-M2.7 or minimax-portal/MiniMax-M2.7 when setting up again? im using global 0auth

sweet helmBOT Apr 13, 2026, 3:56 PM

#

If you’re using global OAuth, choose:

minimax-portal/MiniMax-M2.7

Quick rule:

OAuth → minimax-portal/...
API key → minimax/...

So for minimax-global-oauth, minimax-portal/MiniMax-M2.7 is the right one.

Docs: https://docs.openclaw.ai/providers/minimax

wintry oasis Apr 13, 2026, 3:56 PM

#

selected, it is saying model not found.

sweet helmBOT Apr 13, 2026, 3:57 PM

#

If global OAuth + minimax-portal/MiniMax-M2.7 still says model not found, then I don’t think this is you mis-picking the model anymore.

That combo is the documented correct choice for global OAuth, so if it still fails, I’d treat it as either:

a MiniMax OAuth/runtime bug, or
an upstream MiniMax portal mismatch

Best options now:

If you have a MiniMax API key, switch to the API-key path instead:
```
minimax/MiniMax-M2.7
```
If you only have OAuth, I’d stop burning time on it and file a bug with:
- your version: 2026.4.12
- global OAuth
- models status --probe = ok

#

normal run = 404 model_not_found

Bug reports go here: https://github.com/openclaw/openclaw/issues

If you want, paste the exact new error text from the re-setup too, and I’ll help you write the issue cleanly.

wintry oasis Apr 13, 2026, 3:57 PM

#

i have glm 5.1 api key lets set it up instead and put minimax m2.7 in fallback. if glm fails.

sweet helmBOT Apr 13, 2026, 3:58 PM

#

Yep, that’s a reasonable recovery path.

Since you already have a GLM 5.1 API key, I’d do:

openclaw onboard --non-interactive \
  --auth-choice zai-api-key \
  --zai-api-key "$ZAI_API_KEY"

openclaw models set zai/glm-5.1
openclaw models fallbacks add minimax-portal/MiniMax-M2.7
openclaw gateway restart

Then verify:

#

openclaw models status --probe

One important caveat: MiniMax is still suspicious in your setup right now, so adding it as a fallback is fine, but I would not trust that fallback until probe/runtime both look healthy.

Docs:

wintry oasis Apr 13, 2026, 4:00 PM

#

how does glm 5.1 key usually look. how to identify?

sweet helmBOT Apr 13, 2026, 4:01 PM

#

Usually the docs show a Z.AI / GLM key like:

sk-...

A few practical checks:

it should come from the Z.AI console, not MiniMax
OpenClaw expects it as ZAI_API_KEY
openclaw onboard --auth-choice zai-api-key will auto-detect the endpoint from the key format

So the easiest safe test is:

openclaw onboard --auth-choice zai-api-key

#

or non-interactive:

openclaw onboard --non-interactive --auth-choice zai-api-key --zai-api-key "$ZAI_API_KEY"

Then verify:

openclaw models list --provider zai

Also, don’t paste the full key here. If you want to sanity-check it in chat, only share something like:

sk-abc...xyz

#

Docs: https://docs.openclaw.ai/providers/zai https://docs.openclaw.ai/providers/glm

wintry oasis Apr 13, 2026, 4:05 PM

#

setup the key manually via openclaw onboard and set it as default. setup minimax as fallback and how to check everything and get to work.

sweet helmBOT Apr 13, 2026, 4:05 PM

#

Yep. If you want the cleanest “just get me working” path, I’d do it in this order.

1. Add the GLM key through onboarding

openclaw onboard --auth-choice zai-api-key

Use your Z.AI / GLM API key there. zai-api-key auto-detects the right endpoint.

2. Set GLM as primary

openclaw models set zai/glm-5.1

3. Add MiniMax as fallback

Since you’re using MiniMax global OAuth, use the portal model id:

#

openclaw models fallbacks add minimax-portal/MiniMax-M2.7

4. Restart cleanly

openclaw gateway restart

5. Verify everything

openclaw models status --probe
openclaw status
openclaw gateway status

What you want to see:

#

zai/glm-5.1 → ok
minimax-portal/MiniMax-M2.7 → ideally ok
gateway reachable, no fresh model errors

6. If chat still acts weird, tail logs while sending one test message

openclaw logs --follow

7. Then just test with a fresh session

Send a plain hi.

One caution: MiniMax has been flaky in your setup already, so if GLM works and MiniMax keeps causing weird fallback behavior, I’d temporarily remove the fallback and just run GLM alone first.

Docs:

#

wintry oasis Apr 14, 2026, 9:42 PM

#

Solved

sweet helmBOT Apr 14, 2026, 9:42 PM

#

Nice, glad you got it sorted 🎉

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
That helps Answer Overflow index it for the next person who hits the same mess.

wintry oasis Apr 14, 2026, 9:43 PM

#

Im on android app. How to mark solution?

#OpenClaw Control UI not replying.