404 error from telegram | Friends of the Crustacean 🦞🤝 | Page 1

uneven crane Apr 12, 2026, 11:18 PM

#

out of the blue im suddenly getting a

404 <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

error whenever i do anything in telegram for openclaw. new session, just type, etc.

errant kestrelBOT Apr 12, 2026, 11:18 PM

#

boreal vesselBOT Apr 12, 2026, 11:18 PM

#

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

errant kestrelBOT Apr 12, 2026, 11:18 PM

#

knotty flintBOT Apr 12, 2026, 11:20 PM

#

That HTML is a really useful clue. It looks like a plain nginx 404, not a normal Telegram/OpenClaw policy error.

My first suspects are:

Telegram webhook mode + reverse proxy path drift
A bad Telegram upstream URL/token/proxy path

A quick triage would be:

openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw logs --follow

Then send one Telegram message and paste the matching log lines.

#

A key detail from the docs: Telegram defaults to long polling, not webhooks. So if you did not explicitly set channels.telegram.webhookUrl, this probably is not a Telegram webhook routing issue.

If you are using webhook mode, check these specifically:

channels.telegram.webhookUrl
channels.telegram.webhookPath (default: /telegram-webhook)
channels.telegram.webhookSecret
nginx is forwarding that exact path to the local webhook listener (default 127.0.0.1:8787)

If you want, also paste a redacted:

openclaw config get channels.telegram

Please hide botToken and webhookSecret.

#

Docs:

Paste those outputs and I can help narrow it down fast.

uneven crane Apr 12, 2026, 11:22 PM

#

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██
██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██
██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
🦞 OPENCLAW 🦞

23:16:36+00:00 info gateway {"subsystem":"gateway"} signal SIGTERM received
23:16:36+00:00 info gateway {"subsystem":"gateway"} received SIGTERM; shutting down
23:16:36+00:00 info gmail-watcher {"subsystem":"gmail-watcher"} gmail watcher stopped
23:16:41+00:00 info gateway {"subsystem":"gateway"} loading configuration…
23:16:41+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
23:16:41+00:00 info gateway {"subsystem":"gateway"} starting...
23:16:43+00:00 info gateway {"subsystem":"gateway"} starting HTTP server...
23:16:43+00:00 info gateway/canvas {"subsystem":"gateway/canvas"} canvas host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /Users/nigeldollentas/.openclaw/canvas)
23:16:43+00:00 info gateway {"subsystem":"gateway"} MCP loopback server listening on http://127.0.0.1:49837/mcp
23:16:43+00:00 info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":1800000} heartbeat: started
23:16:43+00:00 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
23:16:43+00:00 info gateway {"subsystem":"gateway"} agent model: minimax-portal/MiniMax-M2.7
23:16:43+00:00 info gateway {"subsystem":"gateway"} ready (7 plugins: acpx, browser, device-pair, memory-core, phone-control, talk-voice, telegram; 1.9s)
23:16:43+

knotty flintBOT Apr 12, 2026, 11:22 PM

#

This looks like a clean restart, not the failing request yet.

The useful bit is: Telegram plugin did load successfully, so it’s probably not crashing on startup.

What I still need is the log output right after you send a Telegram message. Right now we only have startup lines.

Please grab these next:

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Then, while logs --follow is running, send one Telegram message and paste the 10 to 30 lines around the failure.

If the normal logs still don’t show enough, do one restart with Telegram HTTP diagnostics enabled:

#

OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw gateway

Then reproduce once and paste the relevant lines.

If you’re using webhook mode, also paste a redacted:

openclaw config get channels.telegram

Hide botToken and webhookSecret.

So far, my read is:

gateway restarted fine

#

telegram plugin is present
we still haven’t captured the actual 404-producing request

Once you paste the post-message log lines, this should get a lot clearer.

uneven crane Apr 12, 2026, 11:23 PM

#

updated
23:21:46+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"9c8cdb7b-3d6f-4913-a70b-27cb36fe2d3d","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
23:21:46+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7197928432 message=12836

knotty flintBOT Apr 12, 2026, 11:24 PM

#

Yep, this is not a Telegram problem.

These two lines tell the story:

failoverReason":"model_not_found"
telegram sendMessage ok

So Telegram is working fine, it’s just surfacing the upstream model error. The actual failure is your MiniMax OAuth/provider path returning a 404.

Most likely causes now:

wrong/stale MiniMax OAuth config
wrong region path (global vs CN)
the selected MiniMax model is no longer available on that account/path
no fallback configured, so the raw provider error gets sent back to chat

Fastest next step:

#

openclaw --version
openclaw models status --probe

If this is the MiniMax OAuth setup, I’d re-run the matching auth path:

openclaw onboard --auth-choice minimax-global-oauth
# or
openclaw onboard --auth-choice minimax-cn-oauth

If you want an immediate workaround, use /model and switch that session to another configured provider.

Also, once it’s working again, add a fallback so one provider outage doesn’t bubble straight into Telegram.

#

Docs:

If you paste openclaw models status --probe, I can help pinpoint whether it’s auth, region, or model availability.

uneven crane Apr 12, 2026, 11:25 PM

#

openclaw models status --probe
OpenClaw 2026.4.11 (769908e)

🦞 OpenClaw 2026.4.11 (769908e)
I don't have opinions about tabs vs spaces. I have opinions about everything else.

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

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

minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:nigel.dollentas@bitcoin.com=OAuth (nigel.dollentas@bitcoin.com)

OAuth/token status

minimax-portal
- minimax-portal:default ok expires in 364d
openai-codex usage: 5h 100% left ⏱4h 59m · Week 0% left ⏱1d 4h
- openai-codex:nigel.dollentas@bitcoin.com (nigel.dollentas@bitcoin.com) ok expires in 4d

Auth probes
┌──────────────────┬──────────────────────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├──────────────────┼──────────────────────────────────────────────┼────────────┤
│ minimax-portal/ │ minimax-portal:default (oauth) │ ok · 4.3s │
│ MiniMax-M2.7 │ │ │
│ openai-codex/ │ openai-codex:nigel.dollentas@bitcoin.com │ ok · 10.3s │
│ gpt-5.1 │ (nigel.dollentas@bitcoin.com) (oauth) │ │
└──────────────────┴──────────────────────────────────────────────┴────────────┘
Probed 2 targets in 18.3s

knotty flintBOT Apr 12, 2026, 11:26 PM

#

Aha, that narrows it a lot.

models status --probe says auth is fine. So this is probably not a bad/expired MiniMax login.

What it means instead is:

the auth probe works
the actual inference path is what’s breaking

Next test, run a real model turn outside Telegram:

openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

If that fails with the same 404, then the problem is squarely in the MiniMax provider/runtime path, not Telegram.

#

If it does fail, my practical recommendation is:

switch the session/default model to the other configured provider that probes OK
add a fallback, since you currently have Fallbacks (0)
if MiniMax is still important for you, then we’ve probably got a provider-side or integration bug worth filing on GitHub

If it succeeds, then we know the breakage is happening in the normal assistant-turn path, not basic inference, which is a different bug.

Relevant docs:

Paste the infer model run output and we can pin it down from there.

uneven crane Apr 12, 2026, 11:27 PM

#

nigeldollentas@MacBook-Pro-2 ~ % openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json
07:27:04+08:00 [agent/embedded] embedded run agent end: runId=a0e4a7c3-2590-476b-a004-a2afcd69a538 isError=true model=MiniMax-M2.7 provider=minimax-portal error=404 <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html> rawError=404 <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html>
07:27:04+08:00 [agent/embedded] auth profile failure state updated: runId=a0e4a7c3-2590-476b-a004-a2afcd69a538 profile=sha256:9e08bd6be9c1 provider=minimax-portal reason=model_not_found window=cooldown reused=false
07:27:04+08:00 [agent/embedded] embedded run failover decision: runId=a0e4a7c3-2590-476b-a004-a2afcd69a538 stage=assistant decision=surface_error reason=model_not_found provider=minimax-portal/MiniMax-M2.7 profile=sha256:9e08bd6be9c1
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "minimax-portal",
"model": "MiniMax-M2.7",
"attempts": [],
"outputs": [
{
"text": "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>",
"mediaUrl": null
}
]
}

knotty flintBOT Apr 12, 2026, 11:28 PM

#

Perfect, that’s definitive.

This is not Telegram at all. The MiniMax portal inference path itself is returning the 404.

You now have a clean repro outside chat:

openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

So the practical move is:

Immediate recovery

Switch your default model away from MiniMax for now:

#

openclaw models list
openclaw models set <provider/model>
openclaw models fallbacks add <provider/model>

That should get Telegram working again immediately, because Telegram was only surfacing the upstream model failure.

One repair attempt worth trying

If you want to try fixing MiniMax first, re-run the matching MiniMax OAuth setup:

openclaw onboard --auth-choice minimax-global-oauth
# or
openclaw onboard --auth-choice minimax-cn-oauth

#

If that still fails

At that point I’d treat it as a MiniMax portal/OpenClaw bug or upstream regression and file it here:

https://github.com/openclaw/openclaw/issues

Include:

openclaw --version → 2026.4.11
the exact infer model run repro above
the embedded run failover decision log showing reason=model_not_found
note that openclaw models status --probe says auth is OK, but real inference 404s

Docs:

#

If you want, paste openclaw models list next and I can suggest the safest fallback to switch to.

uneven crane Apr 12, 2026, 11:32 PM

#

how do i launch openclaw gui? i can only get it to work on the terminal for some reaosn

knotty flintBOT Apr 12, 2026, 11:32 PM

#

The “GUI” is the browser dashboard, not a separate desktop app.

On your Mac, do this:

openclaw gateway start
openclaw dashboard

If the browser doesn’t auto-open, just open:

http://127.0.0.1:18789/

or

http://localhost:18789/

#

If it asks for auth, paste your gateway token/password into the Control UI settings.

Quick checks if it still won’t come up:

openclaw status
openclaw gateway status

If the gateway is running but you still can’t get in, the next thing I’d check is whether the UI is asking for a token and you just need:

openclaw config get gateway.auth.token

Docs:

https://docs.openclaw.ai/web/dashboard

#

https://docs.openclaw.ai/help/faq#how-do-i-authenticate-the-dashboard-on-localhost-vs-remote

If you want, paste what openclaw gateway status shows and I’ll tell you the exact next step.

uneven crane Apr 12, 2026, 11:43 PM

#

So I’m confused about minimax. What is causing the issue? The website is live and API status is fine.

knotty flintBOT Apr 12, 2026, 11:43 PM

#

Short version: MiniMax auth is working, but MiniMax text generation is not.

That’s why this feels weird.

What your logs show is:

models status --probe = credential/auth path is OK
infer model run = actual text inference call returns 404
Telegram = just showing you that upstream error

So “website is up” and “API status is green” do not rule this out. They only mean MiniMax is generally alive, not that your exact provider path + region + model route is healthy.

The most likely causes are:

wrong MiniMax region path for the OAuth setup (global vs CN)
MiniMax changed/broke the OAuth text inference route OpenClaw is using
custom minimax-portal baseUrl config is pointing at the wrong path

#

the specific provider/model combo is returning model_not_found even though auth succeeds

Also important: from the docs, minimax and minimax-portal are different paths.

minimax = API key provider
minimax-portal = OAuth provider

So this can break on minimax-portal even if “MiniMax” broadly looks healthy.

If you want, paste this next, redacted:

openclaw config get models.providers.minimax-portal

If that looks empty/normal, I’d lean toward upstream regression or OpenClaw integration bug on the MiniMax OAuth path, not a Telegram issue and not a general “MiniMax is down” issue.

Docs:

#

uneven crane Apr 12, 2026, 11:46 PM

#

nigeldollentas@MacBook-Pro-2 ~ % openclaw config get models.providers.minimax-portal

🦞 OpenClaw 2026.4.11 (769908e)
Automation with claws: minimal fuss, maximal pinch.

{
"baseUrl": "https://api.minimax.io/anthropic",
"models": []
}

knotty flintBOT Apr 12, 2026, 11:47 PM

#

That config actually looks normal.

https://api.minimax.io/anthropic is the documented global MiniMax Anthropic-compatible base URL, so I don’t see an obvious local misconfig there.

So the picture now is:

Telegram is fine
your MiniMax OAuth auth is fine
your configured MiniMax global base URL looks fine
but the actual text inference request still returns 404 model_not_found

That usually leaves just a few real explanations:

region mismatch
If your MiniMax account should be using the CN endpoint, the global route can look “alive” but the actual inference path can still fail.
MiniMax-side route/model issue for the OAuth path

#

Their general website/status can be green while this exact inference route returns 404.

OpenClaw regression on the minimax-portal path
Especially since auth probes succeed but real inference fails.

So at this point, I’d say the most honest answer is: it does not look like a Telegram issue or an obvious local config mistake anymore. It looks like either:

wrong MiniMax region for this account, or
a MiniMax/OpenClaw bug on the OAuth inference path

If your account is global, I’d stop chasing Telegram and treat this as a provider/integration bug.
If your account is CN, try the CN OAuth path instead.

Docs:

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

If you want, I can help you write a tight GitHub issue with the exact repro you already captured.

uneven crane Apr 12, 2026, 11:47 PM

#

how do i switch my model to chatgpt

knotty flintBOT Apr 12, 2026, 11:48 PM

#

Easiest split:

Just this chat/session

In Telegram or the Control UI, use:

/model

or

/model list

Then pick the OpenAI one.

#

Change your default globally

In terminal:

openclaw models list
openclaw models set <provider/model>

Use the OpenAI model ref from the list output.

If OpenAI is not in the list yet

Add/configure it first:

openclaw configure

#

Then go to Model/auth, add your OpenAI auth, and set it as default.

Docs:

If you paste openclaw models list, I can tell you the exact command to run next.

uneven crane Apr 13, 2026, 4:34 AM

#

i switched to chatgpt (openAI) model and still getting the same 404 error.

knotty flintBOT Apr 13, 2026, 4:35 AM

#

Huh, okay, then I want to verify the switch actually took effect.

Right now the important question is: what provider/model does the failing turn say it used?

Please grab these:

openclaw models status
openclaw infer model run --provider openai --prompt "Reply with exactly: smoke-ok" --json
openclaw logs --follow

Then, in the same Telegram chat, do:

/new

#

/model status

and send one test message.

What I’m looking for in the fresh logs is the line with:

provider=...
model=...

Because if it still says minimax-portal, then the session/model switch didn’t actually land.
If it says openai and still 404s, then this is a different problem than the MiniMax one.

So, next paste:

openclaw infer model run --provider openai ...

#

the fresh embedded run ... provider=... model=... log line after a Telegram test
/model status output from that Telegram session

Docs:

https://docs.openclaw.ai/concepts/models

uneven crane Apr 13, 2026, 4:37 AM

#

{"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"slug-gen-1776054827506","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
04:33:54+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"auth_profile_failure_state_updated","tags":["error_handling","auth_profiles","cooldown"],"runId":"slug-gen-1776054827506","profileId":"sha256:9e08bd6be9c1","provider":"minimax-portal","reason":"model_not_found","windowType":"cooldown","windowReused":false,"previousErrorCount":0,"errorCount":1,"cooldownUntil":1776054864466,"failureCounts":{"model_not_found":1}} auth profile failure state updated
04:33:54+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"slug-gen-1776054827506","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
04:33:54+00:00 info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-13-404-html-head-title-404-not-fo.md
04:33:56+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d5f0d8e1-e600-4771-8f55-9793bbec6d4f","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-highspeed","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
04:33:56+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"auth_profile_failure_state_updated","tags":["error_handling","auth_profiles","cooldown"],"runId":"d5f0d8e1-e600-4771-8f55-9793bbec6d4f","profileId":"sha256:9e08bd6be9c1","provider":"minimax-portal","reason":"model_not_found","windowType":"cooldown","windowReused":false,"previousErrorCount":0,"errorCount":1,"cooldownUntil":1776054866593,"failureCounts":{"model_not_found":1}} auth profile failure state updated
04:33:56+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"d5f0d8e1-e600-4771-8f55-9793bbec6d4f","stage":"assistant","decision":"surface_error","failoverReason":"model_not_found","profileFailureReason":"model_not_found","provider":"minimax-portal","model":"MiniMax-M2.7-highspeed","profileId":"sha256:9e08bd6be9c1","fallbackConfigured":false,"timedOut":false,"aborted":false,"rawErrorPrevi

#

🦞 OpenClaw 2026.4.11 (769908e)
If it works, it's automation; if it breaks, it's a "learning opportunity."

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

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

minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:nigel.dollentas@bitcoin.com=OAuth (nigel.dollentas@bitcoin.com)
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...bb1be665

OAuth/token status

minimax-portal
- minimax-portal:default ok expires in 365d
openai-codex usage: 5h 100% left ⏱4h 59m · Week 0% left ⏱22h 56m
- openai-codex:nigel.dollentas@bitcoin.com (nigel.dollentas@bitcoin.com) ok expires in 10d
  error: unknown option '--provider'

🦞 OpenClaw 2026.4.11 (769908e)
I can grep it, git blame it, and gently roast it—pick your coping mechanism.

Log file: /tmp/openclaw/openclaw-2026-04-13.log
23:17:06+00:00 info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":1800000} heartbeat: started
23:17:06+00:00 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
23:17:06+00:00 info gateway {"subsystem":"gateway"} agent model: minimax-portal/MiniMax-M2.7
23:17:06+00:00 info gateway {"subsystem":"gateway"} ready (7 plugins: acpx, browser, device-pair, memory-core, phone-control, talk-voice, telegram; 1.8s)
23:17:06+00:00 info gateway {"subsystem":"gateway"} log file: /tmp/openclaw/openclaw-2026-04-13.log
23:17:06+00:00 info gateway {"subsystem":"gateway"} starting channels and sidecars...
23:17:06+00:00 info cron {"module":"cron","storePath":"/Users/nigeldollentas/.openclaw/cron/jobs.json"} {"enabled":true,"jobs":6,"nextWakeAtMs":1776036246754} cron: started
23:17:06+00:00 info gateway/hooks {"subsystem":"gateway/hooks"} loaded 4 internal hook handlers
23:17:10+00:00 info bonjour: advertised gateway fqdn=MacBook Pro (3) (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
23:17:10+00:00 info plugins {"subsystem":"plugins"} embedded acpx runtime backend registered (cwd: /Users/nigeldollentas/.openclaw/workspace)
23:17:10+00:00 info browser/server {"subsystem":"browser/server"} Browser control listening on http://127.0.0.1:18791/ (auth=token)
23:17:22+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider

knotty flintBOT Apr 13, 2026, 4:37 AM

#

That log answers it pretty cleanly: you are still on MiniMax.

The key bit is:

provider":"minimax-portal"

So the OpenAI switch did not actually apply to the run that failed.

A couple likely reasons:

you changed a different session
you changed only a session override, not the global default
the gateway is still using the old default until restarted

I’d do this from terminal so it’s unambiguous:

#

openclaw models status
openclaw models list
openclaw models set <the openai/... model ref from the list>

Then confirm the Default: line is no longer minimax-portal/....

If it still looks stuck, do:

openclaw gateway restart
openclaw models status

Then in Telegram:

#

/new
/model status

and send one test message.

Important nuance: a session-only model switch does not necessarily change other runs or hooks. Your pasted logs are still clearly coming from the MiniMax provider.

Docs:

https://docs.openclaw.ai/cli/models

If you paste the output of openclaw models list, I can tell you the exact openclaw models set ... command to run.

#

Yep, this confirms it, your default is still MiniMax.

Also, the OpenAI-backed provider you actually have configured is openai-codex, not plain openai. That’s why your earlier switch attempt didn’t land.

Try this exact command:

openclaw models set openai-codex/gpt-5.1
openclaw gateway restart
openclaw models status

You want the Default: line to stop saying minimax-portal/....

Then in Telegram:

#

/new
/model status

and test again.

If openclaw models set openai-codex/gpt-5.1 errors, run:

openclaw models list

and use the exact OpenAI-backed ref it prints.

So the root problem right now is simpler than it looked: you haven’t actually switched away from MiniMax yet.

#

Docs:

https://docs.openclaw.ai/cli/models

uneven crane Apr 13, 2026, 4:38 AM

#

openclaw models list
openclaw models set <the openai/... model ref from the list>
zsh: parse error near `\n'
nigeldollentas@MacBook-Pro-2 ~ %

knotty flintBOT Apr 13, 2026, 4:38 AM

#

Yep, that one’s on me, the <...> bit was a placeholder, not something to type literally. zsh treated it like shell syntax.

Run this exact command instead:

openclaw models set openai-codex/gpt-5.1

Then:

openclaw gateway restart
openclaw models status

You want Default: to show openai-codex/gpt-5.1, not MiniMax.

#

Then in Telegram:

/new
/model status

and test again.

uneven crane Apr 13, 2026, 4:39 AM

#

🦞 OpenClaw 2026.4.11 (769908e) — Making 'I'll automate that later' happen now.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.1
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : minimax-m2.7 -> minimax-portal/MiniMax-M2.7, minimax-m2.7-highspeed -> minimax-portal/MiniMax-M2.7-highspeed
Configured models (3): minimax-portal/MiniMax-M2.7, minimax-portal/MiniMax-M2.7-highspeed, openai-codex/gpt-5.1

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

minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:nigel.dollentas@bitcoin.com=OAuth (nigel.dollentas@bitcoin.com)

knotty flintBOT Apr 13, 2026, 4:39 AM

#

Nice, that part is fixed, your default really is OpenAI now.

Next do a clean test:

openclaw gateway restart

Then in Telegram:

/new
/model status

Send one normal message after that.

#

What should happen now:

if it works, the MiniMax issue was the whole problem
if it still 404s, paste the fresh log lines after this test, because then we’ll know whether it’s now failing on openai-codex or something else entirely

You’ve at least cleared the “did the switch actually happen?” part. It did.

uneven crane Apr 13, 2026, 4:40 AM

#

yeah it still gives 404 errors. so what log lines i post? what command?

knotty flintBOT Apr 13, 2026, 4:40 AM

#

Yep, do this exactly:

openclaw logs --follow

Leave that running, then in Telegram:

/new
/model status
send one normal test message

Then paste the first 15 to 30 log lines that appear right after the test.

The most important lines are the ones containing any of these:

embedded_run_agent_end

#

embedded_run_failover_decision
provider
model
failoverReason
telegram sendMessage

So basically: run openclaw logs --follow, reproduce once, then copy the fresh error block.

Also paste the /model status output from Telegram if you can.

That should tell us whether the 404 is now coming from openai-codex or something else.

uneven crane Apr 13, 2026, 4:41 AM

#

04:40:01+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"adff8cb9-6f70-4bcf-884f-fa711de12695","stage":"assistant","decision":"surface_error","failoverReason":"model_not_found","profileFailureReason":"model_not_found","provider":"minimax-portal","model":"MiniMax-M2.7-highspeed","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
04:40:02+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=7197928432 message=12854
Log tail truncated (increase --max-bytes).

knotty flintBOT Apr 13, 2026, 4:42 AM

#

That’s the smoking gun.

Your global default changed, but the Telegram session is still pinned to MiniMax, and specifically the highspeed variant:

provider":"minimax-portal"
model":"MiniMax-M2.7-highspeed"

So this is now a session override problem, not a global-default problem.

In that same Telegram chat, run these exact commands:

/model openai-codex/gpt-5.1
/model status

Then send one normal message.

#

Please paste back the reply from /model status.

The reason I’m confident here is that the logs are still showing a MiniMax session model, not your new default. So we need to change the model inside that Telegram session, not just in the global config.

Docs:

https://docs.openclaw.ai/concepts/models

uneven crane Apr 13, 2026, 4:43 AM

#

⚠️ You have hit your ChatGPT usage limit (team plan). Try again in ~1370 min.

knotty flintBOT Apr 13, 2026, 4:43 AM

#

That’s actually good news.

The 404 path is gone. Your Telegram session did switch away from MiniMax.

Now the new failure is different:

OpenAI / ChatGPT auth is working
but you’ve hit the usage limit on that team plan

So the problem is no longer Telegram and no longer the MiniMax 404. It’s now just quota.

Your options are:

wait for that window to reset, or
switch to another provider/model for now

Fastest next step:

#

/model list

Then pick a non-OpenAI model.

Since your earlier status showed OpenRouter is configured, that’s probably your best temporary escape hatch if you have a usable model there.

If you want to change it globally from terminal after that:

openclaw models set <provider/model>
openclaw models fallbacks add <provider/model>

So, progress summary:

#

MiniMax 404 = separate issue
ChatGPT switch = worked
current blocker = OpenAI quota

Docs:

uneven crane Apr 13, 2026, 5:37 AM

#

can we do a clean rest of openclaw to get minimax to work? it should work.

knotty flintBOT Apr 13, 2026, 5:37 AM

#

Yeah, a clean restart is worth trying, but I would not nuke all of OpenClaw yet.

The reason is: if direct infer model run still 404s after a restart, that points to MiniMax auth/endpoint/integration, not just stale session state.

I’d do this in order:

1) Safe clean restart

openclaw gateway restart
openclaw models status --probe
openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

2) If it still 404s, refresh MiniMax OAuth

If you’re on the global MiniMax account:

#

openclaw onboard --auth-choice minimax-global-oauth
openclaw gateway restart
openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

If your account is CN instead, use:

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

3) If it still 404s after fresh OAuth

Then I would stop treating it as “dirty local state” and treat it as a MiniMax/OpenClaw bug or upstream regression.

So yes, try a clean restart, but I would not delete ~/.openclaw or reinstall yet.

#

Docs:

If you want, paste the result of step 1 after the restart and I’ll tell you whether it’s worth doing step 2.

uneven crane Apr 13, 2026, 5:39 AM

#

This was the response i got : Auth probes
┌──────────────────┬──────────────────────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├──────────────────┼──────────────────────────────────────────────┼────────────┤
│ minimax-portal/ │ minimax-portal:default (oauth) │ ok · 5s │
│ MiniMax-M2.7 │ │ │
│ openai-codex/ │ openai-codex:nigel.dollentas@bitcoin.com │ ok · 10.4s │
│ gpt-5.1 │ (nigel.dollentas@bitcoin.com) (oauth) │ │
│ openrouter/ai21/ │ openrouter:default (api_key) │ ok · 7.5s │
│ jamba-large-1.7 │ │ │

knotty flintBOT Apr 13, 2026, 5:40 AM

#

Nice, that tells us the restart didn’t break auth, but it still doesn’t answer the real question.

Auth probes = ok only means the credential is valid enough to probe.
It does not prove MiniMax text generation works.

The deciding test is still this:

openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

If that still returns the same 404 after the restart, then the restart did not fix MiniMax, and I’d move to the next step:

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

#

Then:

openclaw gateway restart
openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

Also, side note, your probe output shows OpenRouter is healthy, so you do have a working fallback while debugging this.

Paste the infer model run result after the restart, that’s the one that matters here.

uneven crane Apr 13, 2026, 5:55 AM

#

├──────────────────┼──────────────────────────────────────────────┼────────────┤
│ minimax-portal/ │ minimax-portal:default (oauth) │ ok · 5s │
│ MiniMax-M2.7 │ │ │
│ openai-codex/ │ openai-codex:nigel.dollentas@bitcoin.com │ ok · 10.4s │
│ gpt-5.1 │ (nigel.dollentas@bitcoin.com) (oauth) │ │
│ openrouter/ai21/ │ openrouter:default (api_key) │ ok · 7.5s │
│ jamba-large-1.7 │ │ │
└──────────────────┴──────────────────────────────────────────────┴────────────┘
Probed 3 targets in 18.8s
13:39:48+08:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: kimi-claw (/Users/nigeldollentas/.openclaw/extensions/kimi-claw/dist/index.js). Set plugins.allow to explicit trusted ids.
13:39:48+08:00 [plugins] kimi-claw: loaded without install/load-path provenance; treat as untracked local code and pin trust via plugins.allow or install records (/Users/nigeldollentas/.openclaw/extensions/kimi-claw/dist/index.js)
13:39:52+08:00 [agent/embedded] embedded run agent end: runId=a0e4a7c3-2590-476b-a004-a2afcd69a538 isError=true model=MiniMax-M2.7 provider=minimax-portal error=404 <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html> rawError=404 <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html>
13:39:52+08:00 [agent/embedded] auth profile failure state updated: runId=a0e4a7c3-2590-476b-a004-a2afcd69a538 profile=sha256:9e08bd6be9c1 provider=minimax-portal reason=model_not_found window=cooldown reused=false
13:39:52+08:00 [agent/embedded] embedded run failover decision: runId=a0e4a7c3-2590-476b-a004-a2afcd69a538 stage=assistant decision=surface_error reason=model_not_found provider=minimax-portal/MiniMax-M2.7 profile=sha256:9e08bd6be9c1
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "minimax-portal",
"model": "MiniMax-M2.7",
"attempts": [],
"outputs": [
{
"text": "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>",
"mediaUrl": null
}
]
}

knotty flintBOT Apr 13, 2026, 5:56 AM

#

Yep, that settles it.

A restart did not fix it. You now have a clean repro showing:

models status --probe says MiniMax OAuth is ok
but direct infer model run on minimax-portal/MiniMax-M2.7 still returns 404
same model_not_found after restart

So this is not Telegram, and it’s probably not stale local runtime state anymore.

Also, those kimi-claw warnings look unrelated to this specific 404.

What I’d do next

One last repair attempt: refresh MiniMax OAuth

#

openclaw onboard --auth-choice minimax-global-oauth
openclaw gateway restart
openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

If that still 404s, I’d call it a MiniMax/OpenClaw bug or upstream regression and file it here:

https://github.com/openclaw/openclaw/issues

Strong repro you already have

Include:

openclaw --version → 2026.4.11
openclaw config get models.providers.minimax-portal → https://api.minimax.io/anthropic
openclaw models status --probe → MiniMax auth probe ok
direct repro:

#

openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

resulting error: raw nginx 404 + failoverReason=model_not_found

Practical workaround

While waiting, use OpenRouter or another working provider, since your probes show that one is healthy.

If you want, I can draft the exact GitHub issue text for you so you can paste it in.

uneven crane Apr 13, 2026, 5:57 AM

#

do two things. give me the sintrucitons on how to apply a github issue text. but also walk me through resetting openclaw and trying to add the api again.

knotty flintBOT Apr 13, 2026, 5:59 AM

#

Yep. Here are both, clean and practical.

1) GitHub issue, exactly how to file it

Go here:

https://github.com/openclaw/openclaw/issues

Then:

click New issue
choose Bug report if it shows up, otherwise blank issue
use this title:

MiniMax OAuth probe passes but minimax-portal/MiniMax-M2.7 infer returns nginx 404 / model_not_found

#

paste this body:

## Version

OpenClaw 2026.4.11 (769908e)

## Summary

MiniMax OAuth looks healthy in `openclaw models status --probe`, but direct inference with `minimax-portal/MiniMax-M2.7` returns a raw nginx 404 and `model_not_found`.

This originally surfaced in Telegram, but I reproduced it directly with `openclaw infer model run`, so it does not appear to be a Telegram issue.

## Repro

```bash
openclaw models status --probe

#

openclaw config get models.providers.minimax-portal
openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json


## Probe result

`openclaw models status --probe` shows:

- `minimax-portal/MiniMax-M2.7` -> `ok`
- other providers also probe fine

## Config

```json
{
  "baseUrl": "https://api.minimax.io/anthropic",
  "models": []

#

}


## Actual result

Direct infer returns:

```text
404 <html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

#


And logs show:

```text
failoverReason=model_not_found
provider=minimax-portal
model=MiniMax-M2.7

Expected result

openclaw infer model run --model minimax-portal/MiniMax-M2.7 ... should return a normal model response, not a raw nginx 404.

Notes

#

- Restarting the gateway did not fix it.
- Telegram was only surfacing the upstream error.
- OpenAI/OpenRouter auth also probe successfully, so the failure appears isolated to the MiniMax OAuth inference path.

Before posting, just make sure there are no secrets in anything you paste.

2) Safest way to reset MiniMax and add it again

I would not full-wipe OpenClaw yet. I’d do a MiniMax-only reset/re-add.

Option A, re-add MiniMax OAuth

If you want to keep using the OAuth path:

#

openclaw models auth login --provider minimax-portal
openclaw gateway restart
openclaw infer model run --model minimax-portal/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

If that flow asks you to choose regional auth and you’re on the global account, use the global MiniMax path.

Option B, try MiniMax API key instead of OAuth

If you want to re-add MiniMax via API key instead:

openclaw onboard --auth-choice minimax-global-api
openclaw gateway restart
openclaw infer model run --model minimax/MiniMax-M2.7 --prompt "Reply with exactly: smoke-ok" --json

#

If your account is CN, use:

openclaw onboard --auth-choice minimax-cn-api

After it works

Then switch the default back only if the smoke test passes:

openclaw models set minimax-portal/MiniMax-M2.7

or for API-key mode:

#

openclaw models set minimax/MiniMax-M2.7

My recommendation

Do this order:

file the GitHub issue with the repro
try openclaw models auth login --provider minimax-portal
if that still fails, try the API-key path instead

Docs:

#

If you want, I can also turn that GitHub issue body into a shorter “paste-ready” version.

uneven crane Apr 13, 2026, 6:00 AM

#

hello?

smoke-ok

────────────────────────────────────────────────────────────────────────────────

Kimi's question about Telegram: yes, if your Telegram plugin is configured and
the bot token is set, OpenClaw routes cleanly through Telegram. If it's not
working, check openclaw config get plugins.entries.telegram.config — most common
issue is the bot token being wrong or the plugin not being enabled.
connected | idle
agent main | session main (openclaw-tui) | minimax-portal/MiniMax-M2.7 |
reasoning | tokens 34k/200k (17%)
────────────────────────────────────────────────────────────────────────────────

────────────────────────────────────────────────────────────────────────────────

knotty flintBOT Apr 13, 2026, 6:01 AM

#

Oh, that’s actually very promising.

If that screen is real output from minimax-portal/MiniMax-M2.7, then MiniMax is responding again locally.

Also, ignore the content of that answer about Telegram config, the useful signal here is just:

the model generated text
on minimax-portal/MiniMax-M2.7
so the raw MiniMax 404 may be gone now

I’d do this next:

openclaw gateway restart

Then in Telegram:

#

/new
/model minimax-portal/MiniMax-M2.7
/model status

Then send a simple test like:

Reply with exactly: smoke-ok

If Telegram still fails after that, paste the fresh log block again.
But if the TUI really just answered on MiniMax, I think you may have actually revived it 🎉

One important note: the earlier “check telegram plugin config” advice from the model is not the thing to focus on. Your earlier logs already showed Telegram was delivering fine. The question now is just whether Telegram is using the now-working MiniMax path.

uneven crane Apr 13, 2026, 6:24 AM

#

but now it says Gateway Status
Reachable: no
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - gateway closed (1006):

knotty flintBOT Apr 13, 2026, 6:25 AM

#

Yep, that’s a different problem now.

This means the gateway itself is not staying up:

Reachable: no
gateway closed (1006)

Ignore the Bonjour bit. The important part is that ws://127.0.0.1:18789 is not serving a healthy gateway right now.

Do this next, in order:

openclaw gateway status
openclaw gateway start
openclaw gateway status
openclaw logs --follow

#

Then, while logs --follow is open, wait a few seconds and paste the first error/warn lines you see.

If openclaw gateway start immediately drops you back to the shell and status still says unreachable, the logs will tell us whether it’s:

crashing on startup
config/auth issue
port bind problem
plugin/provider startup failure

So we’ve temporarily moved from “MiniMax 404” to “gateway won’t stay up.” Paste the fresh startup log lines and I’ll help you sort that one fast.

uneven crane Apr 13, 2026, 6:25 AM

#

Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006):

Gateway port 18789 is not listening (service appears running).
Last gateway error: 2026-04-13T14:25:36.401+08:00 Gateway failed to start: Error: Startup failed: required secrets are unavailable. SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.
Logs: ~/.openclaw/logs/gateway.log
Errors: ~/.openclaw/logs/gateway.err.log

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.11 (769908e)
Automation with claws: minimal fuss, maximal pinch.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

🦞 OpenClaw 2026.4.11 (769908e)
Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-13.log
Command: /opt/homebrew/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 23719, state active)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006):

Gateway port 18789 is not listening (service appears running).
Last gateway error: 2026-04-13T14:25:39.910+08:00 Gateway failed to start: Error: Startup failed: required secrets are unavailable. SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.
Logs: ~/.openclaw/logs/gateway.log
Errors: ~/.openclaw/logs/gateway.err.log

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.11 (769908e)
Automation with claws: minimal fuss, maximal pinch.

Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/nigeldollentas/.openclaw/openclaw.json
Bind: loopback

knotty flintBOT Apr 13, 2026, 6:26 AM

#

Aha, we found the startup blocker.

This is not MiniMax right now, it’s this:

SecretRefResolutionError
Environment variable "DISCORD_BOT_TOKEN" is missing or empty

So the gateway is failing before it can fully come up.

On macOS, this usually happens because the LaunchAgent does not inherit your shell env. Your terminal may have DISCORD_BOT_TOKEN, but the background service does not.

Easiest fix

Put the Discord token in:

#

~/.openclaw/.env

Add a line like:

DISCORD_BOT_TOKEN=your_actual_token_here

Then restart the gateway:

openclaw gateway restart
openclaw gateway status

#

Important

Do not paste the token here in Discord.

Why this works

Per the docs, OpenClaw services on launchd/systemd often miss shell env vars, and ~/.openclaw/.env is the durable fix for service launches.

Docs:

If you want, after you add that line, paste the new openclaw gateway status output and I’ll tell you the next step.

uneven crane Apr 13, 2026, 6:28 AM

#

how do i find this file?

knotty flintBOT Apr 13, 2026, 6:28 AM

#

On your Mac, that file path is:

~/.openclaw/.env

which means:

/Users/your-username/.openclaw/.env

Easiest ways to open it

Finder

Press Cmd+Shift+G
Paste:

#

~/.openclaw/

Press Enter
If you don’t see .env, press Cmd+Shift+. to show hidden files

Terminal
Open the folder:

open ~/.openclaw

Or edit the file directly:

#

nano ~/.openclaw/.env

If the file doesn’t exist yet, nano will create it.

Then add:

DISCORD_BOT_TOKEN=your_actual_token_here

Save with:

Ctrl+O, Enter
Ctrl+X

#

Then run:

openclaw gateway restart
openclaw gateway status

And again, don’t paste the token here.

uneven crane Apr 13, 2026, 6:30 AM

#

🦞 OpenClaw 2026.4.11 (769908e)
It's not "failing," it's "discovering new ways to configure the same thing wrong."

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

🦞 OpenClaw 2026.4.11 (769908e)
Runs on a Raspberry Pi. Dreams of a rack in Iceland.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-13.log
Command: /opt/homebrew/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 25526, state active)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
timeout

Port 18789 is already in use.

pid 25526 nigeldollentas: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
nigeldollentas@MacBook-Pro-2 ~ %

knotty flintBOT Apr 13, 2026, 6:31 AM

#

This is actually progress.

The Discord token problem looks fixed enough that the gateway is now binding port 18789.

What’s happening now is:

the gateway process is running
port 18789 is listening
but the RPC probe is still timing out

So don’t start another gateway. It’s already there.

Next step

Run:

#

openclaw logs --follow

Leave that open for 10 to 20 seconds and paste the first warn/error lines that show up.

Then in another terminal, run:

openclaw gateway status
openclaw status

What I want to know now is whether it:

finishes warming up and becomes healthy, or
gets stuck during startup on some plugin/provider

#

So far, the big win is: we got past the missing DISCORD_BOT_TOKEN blocker. Now we’re in the “gateway starts but doesn’t answer RPC yet” phase.

uneven crane Apr 13, 2026, 6:32 AM

#

Log file: /tmp/openclaw/openclaw-2026-04-13.log
06:28:24+00:00 error gateway/secrets {"subsystem":"gateway/secrets"} [SECRETS_RELOADER_DEGRADED] SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.
06:28:24+00:00 error Gateway failed to start: Error: Startup failed: required secrets are unavailable. SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.
06:28:26+00:00 info gateway {"subsystem":"gateway"} loading configuration…
06:28:26+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
06:28:26+00:00 info gateway {"subsystem":"gateway"} starting...
06:28:28+00:00 error gateway/secrets {"subsystem":"gateway/secrets"} [SECRETS_RELOADER_DEGRADED] SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.
06:28:28+00:00 error Gateway failed to start: Error: Startup failed: required secrets are unavailable. SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.
06:28:30+00:00 info gateway {"subsystem":"gateway"} loading configuration…
06:28:30+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
06:28:30+00:00 info gateway {"subsystem":"gateway"} starting...
06:28:31+00:00 error gateway/secrets {"subsystem":"gateway/secrets"} [SECRETS_RELOADER_DEGRADED] SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.
06:28:31+00:00 error Gateway failed to start: Error: Startup failed: required secrets are unavailable. SecretRefResolutionError: Environment variable "DISCORD_BOT_TOKEN" is missing or empty.

knotty flintBOT Apr 13, 2026, 6:32 AM

#

Yep, the gateway still cannot see DISCORD_BOT_TOKEN.

So one of these is true:

~/.openclaw/.env does not exist
it’s in the wrong place
the file is named wrong (for example .env.txt)
the line is malformed
it wasn’t saved before restart

Check this exactly

Open this file:

open ~/.openclaw/.env

#

Make sure it contains a line exactly like this:

DISCORD_BOT_TOKEN=your_actual_token_here

Important formatting rules

no quotes
no export
no spaces around =
filename must be exactly .env

Then restart:

openclaw gateway restart

#

openclaw gateway status

Quick sanity check

In Finder or Terminal, make sure the file really exists:

ls -la ~/.openclaw/.env

If that says “No such file”, the file is not where OpenClaw expects it.

So the immediate blocker is still just: the Discord token file/env is not being loaded correctly yet. Once that resolves, the gateway should stop dying on startup.

uneven crane Apr 13, 2026, 6:33 AM

#

nigeldollentas@MacBook-Pro-2 ~ % ls -la ~/.openclaw/.env
-rw-r--r--@ 1 nigeldollentas staff 92 Apr 13 14:29 /Users/nigeldollentas/.openclaw/.env

knotty flintBOT Apr 13, 2026, 6:33 AM

#

Good, so the file exists. That narrows it down a lot.

Now I want to verify the format without leaking the token.

Please run this and paste the output:

sed -E 's/=.*/=<redacted>/' ~/.openclaw/.env

That will show the variable names only, not the secret values.

I’m checking for things like:

DISCORD_BOT_TOKEN=<redacted> ✅
export DISCORD_BOT_TOKEN=... ❌
DISCORD_BOT_TOKEN = ... ❌

#

quotes / weird formatting ❌

After that, restart again:

openclaw gateway restart
openclaw gateway status

We’re very close now, this looks like a formatting/loading issue rather than a missing file.

uneven crane Apr 13, 2026, 6:33 AM

#

nigeldollentas@MacBook-Pro-2 ~ % sed -E 's/=.*/=<redacted>/' ~/.openclaw/.env
DISCORD_BOT_TOKEN=<redacted>

knotty flintBOT Apr 13, 2026, 6:34 AM

#

Nice, that means the .env file itself looks correct.

So the next likely culprit is this subtle one:

launchd may already have DISCORD_BOT_TOKEN set to an empty value, and .env will not override an existing env var, even if it’s empty.

Check that

Run:

launchctl getenv DISCORD_BOT_TOKEN

If that comes back blank or weird, clear it and restart:

#

launchctl unsetenv DISCORD_BOT_TOKEN
openclaw gateway restart
openclaw gateway status

Why I’m thinking this

Your file exists, the format is correct, and OpenClaw docs say .env does not override existing env vars. So a stale empty launchd env value would fit perfectly.

If that still doesn’t fix it, the next fallback is to set it directly in launchd for a quick test, but let’s try the cleaner path first.

errant kestrelBOT Apr 13, 2026, 7:16 AM

#

#404 error from telegram

Immediate recovery

One repair attempt worth trying

If that still fails

Just this chat/session

Change your default globally

If OpenAI is not in the list yet

1) Safe clean restart

2) If it still 404s, refresh MiniMax OAuth

3) If it still 404s after fresh OAuth

What I’d do next

Strong repro you already have

Practical workaround

1) GitHub issue, exactly how to file it

Expected result

Notes

2) Safest way to reset MiniMax and add it again

Option A, re-add MiniMax OAuth

Option B, try MiniMax API key instead of OAuth

After it works

My recommendation

Easiest fix

Important

Why this works

Easiest ways to open it

Next step

Check this exactly

Important formatting rules

Quick sanity check

Check that

Why I’m thinking this