v2026.4.15 breaks OpenRouter routing - resolves to openai provider instead | Friends of the Crustacean 🦞🤝 | Page 1

frosty anchor Apr 19, 2026, 9:13 PM

#

After updating to v2026.4.15, my agent stopped routing through OpenRouter. Config has openrouter/openai/gpt-5.4 as primary model and OPENROUTER_API_KEY set in env. Logs show gateway loads model correctly but every run resolves to provider=openai and fails with 401. Was working perfectly on v2026.4.12. Anyone else hit this?

celest lagoonBOT Apr 19, 2026, 9:13 PM

#

shell havenBOT Apr 19, 2026, 9:13 PM

#

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

quartz oysterBOT Apr 19, 2026, 9:17 PM

#

Let me verify the docs and source, there’s a decent chance this is a real regression rather than config drift.

#

Yeah, this looks like a real routing-class bug, not just a bad key.

openrouter/openai/gpt-5.4 is an OpenRouter model ref whose model id itself contains /. If that wrapper provider gets dropped from session state, OpenClaw degrades it to:

provider = openai
model = gpt-5.4

…and then it reaches for OPENAI_API_KEY, which matches your 401 exactly.

I found an older changelog entry for basically this exact failure mode: preserving the stored OpenRouter provider for vendor-prefixed model ids so follow-up turns do not route to the direct provider API.

Quickest things to try:

paste openclaw --version
start a fresh session (/new) or explicitly reselect
/model openrouter/openai/gpt-5.4
run:

#

   openclaw models status --probe
   openclaw sessions --json

What I’d check in sessions --json is whether the active row has model: "openai/gpt-5.4" but modelProvider / providerOverride is missing or openai instead of openrouter.

Docs:

If you paste the relevant sessions --json row, I can tell pretty quickly whether this is stale session metadata or a fresh regression in v2026.4.15.

frosty anchor Apr 19, 2026, 9:25 PM

#

Here's my openclaw sessions --json output:
The main session (agent:main:main) now shows modelProvider: openrouter which looks correct. But the three Discord channel sessions all have model: openai/gpt-5.4 with no modelProvider field. I'm still getting empty responses in the webchat. Is the stale Discord session metadata causing the routing issue, or is there something else going on?
json{
"path": "/data/.openclaw/agents/main/sessions/sessions.json",
"count": 4,
"activeMinutes": null,
"sessions": [
{
"key": "agent:main:main",
"updatedAt": 1776633797272,
"ageMs": 1054,
"sessionId": "boot-2026-04-19_20-26-36-406-69276470",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 676,
"outputTokens": 80,
"totalTokens": null,
"totalTokensFresh": false,
"model": "gpt-5.4",
"modelProvider": "openrouter",
"contextTokens": 200000,
"agentId": "main",
"kind": "direct"
},
{
"key": "agent:main:discord:channel:1488195392251101399",
"updatedAt": 1776522207724,
"ageMs": 111590602,
"sessionId": "d5afc0d8-5436-43cb-be56-5e0a2c294b68",
"totalTokens": null,
"totalTokensFresh": false,
"model": "openai/gpt-5.4",
"contextTokens": 200000,
"agentId": "main",
"kind": "group"
},
{
"key": "agent:main:discord:channel:1490227314716311572",
"updatedAt": 1776454405972,
"ageMs": 179392354,
"sessionId": "183b6c07-e586-4f98-840a-1cbf2409798c",
"totalTokens": null,
"totalTokensFresh": false,
"model": "openai/gpt-5.4",
"contextTokens": 200000,
"agentId": "main",
"kind": "group"
},
{
"key": "agent:main:discord:channel:562802830654832720",
"updatedAt": 1776423135217,
"ageMs": 210663109,
"sessionId": "b84589cb-f36e-4afe-9a17-4b1bd8a302b4",
"totalTokens": null,
"totalTokensFresh": false,
"model": "openai/gpt-5.4",
"contextTokens": 200000,
"agentId": "main",
"kind": "group"
}
]
}

quartz oysterBOT Apr 19, 2026, 9:26 PM

#

Yeah, the stale Discord session metadata is enough to explain the Discord-side misrouting.

Why:

agent:main:main looks healthy: modelProvider: "openrouter", model: "gpt-5.4"
the Discord sessions do not have modelProvider
when OpenClaw only has model: "openai/gpt-5.4", it parses that as direct provider=openai, not openrouter

So those Discord channel sessions can absolutely still force the wrong route.

What it does not explain cleanly is webchat, because your main/direct session already looks like OpenRouter. So I think you may have two things:

stale Discord session metadata, and
a separate webchat issue, or webchat is using a different session than you think

What I’d do next:

#

In each affected Discord thread/channel, run:
- /new
  or
- /model openrouter/openai/gpt-5.4
Send one message in webchat, then immediately run:
```
openclaw sessions --json
```
and check which row got the new updatedAt.

If webchat updates agent:main:main, then the OpenRouter routing there is probably fine, and the “empty response” is a separate webchat/rendering problem.

If you want, paste:

exact openclaw --version
the updated sessions --json after one webchat message
a short openclaw logs --follow snippet for that webchat turn

#

That should narrow it down pretty fast.

frosty anchor Apr 19, 2026, 9:29 PM

#

After clearing the session overrides, I now see two distinct issues in the logs:

Older boot session runs still routing to provider=openai with 401 (stale metadata)
Newer runs at 17:01+ show payloads=0 stopReason=stop with no auth error — these appear to be reaching OpenRouter but returning empty content

openclaw --version: 2026.4.15 (041266a)
The models status --probe shows openrouter/openai/gpt-5.4 probing ok · 7.3s so auth is fine. Why would a successful OpenRouter call return payloads=0?

quartz oysterBOT Apr 19, 2026, 9:35 PM

#

I found the routing side already. Now I’m tracing the empty-result side so I can say whether that’s upstream empty text vs OpenClaw swallowing it.

#

I found a pretty likely lead: newer OpenClaw has a specific OpenRouter streaming fix for replies where the visible text comes inside reasoning_details.response.output_text / reasoning_details.response.text. If you’re on 2026.4.15, that could explain “successful call, zero payloads”. Let me confirm it against the v2026.4.15 code.

#

Yeah, I think you’ve got two separate issues, not one:

Old sessions still have stale provider metadata, so they degrade to provider=openai and hit 401.
New runs are probably hitting a real 2026.4.15 OpenRouter stream parsing gap.

Why payloads=0 stopReason=stop can happen even when OpenRouter auth is fine:

models status --probe proves auth + reachability, not that OpenClaw turned the streamed response into visible text.
In v2026.4.15, the OpenRouter completions parser only treated reasoning_details of type reasoning.text as hidden thinking.
It did not yet surface OpenRouter-visible reply text carried as:
- reasoning_details[].type = "response.output_text"
- reasoning_details[].type = "response.text"

So if OpenRouter returned the answer in one of those fields, OpenClaw could successfully finish the run with stopReason=stop but still end up with no user-visible payloads.

That lines up with later changelog fixes I found, especially:

#

OpenRouter/streaming: treat reasoning_details.response.output_text and reasoning_details.response.text as visible assistant output...
OpenRouter/Qwen3: parse reasoning_details stream deltas as thinking content without skipping same-chunk tool calls...

One more important detail: the empty-response retry guard in this area is only auto-enabled for provider=openai / openai-codex, not openrouter, so on 2026.4.15 this lane can just quietly end as payloads=0.

What I’d do

For the old provider=openai runs: use a fresh session (/new / reset that thread session).
For the empty OpenRouter runs: update past 2026.4.15, ideally latest.
If you want a smoking gun before upgrading, capture a raw streamed chunk and check for reasoning_details containing response.output_text or response.text.

So short version: auth is probably fine, and payloads=0 is very likely OpenClaw not promoting the returned OpenRouter text into a visible payload in 2026.4.15.

frosty anchor Apr 19, 2026, 9:42 PM

#

you say to update past 2026.4.15 but there isnt an update past that yet is there?

quartz oysterBOT Apr 19, 2026, 9:43 PM

#

Let me check the repo tags so I don’t make you chase a ghost version.

#

Yeah, good catch, I overstated that.

There is no newer stable tag than v2026.4.15 that I can confirm right now. What I do see in the repo is:

v2026.4.19-beta.2
v2026.4.19-beta.1

So the more accurate advice is:

if you want stable, your practical workaround is probably roll back to v2026.4.12
if you’re okay testing, try v2026.4.19-beta.2
if you stay on 2026.4.15, the stale-session provider=openai issue can be mitigated with fresh sessions, but the payloads=0 stopReason=stop path may just be an unfixed regression in that stable

So yes, I think this is basically:

bug/regression in 2026.4.15 stable
fix exists later in beta/main

#

not fully fixed in a newer stable release yet

If you can reproduce it in a fresh session on 2026.4.15, I’d file it here with the two symptoms split out:

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

If you want, I can help you write the exact issue text so it’s easy for maintainers to verify.

frosty anchor Apr 19, 2026, 9:46 PM

#

how do I access the v2026.4.1-beta.2 from my openclaw running on a vps

#

oops meantv2026.4.19-beta.2

quartz oysterBOT Apr 19, 2026, 9:47 PM

#

I think you mean v2026.4.19-beta.2, not v2026.4.1-beta.2, let me verify the install path so I don’t hand you a fake command.

#

Assuming you mean v2026.4.19-beta.2, the easiest path on a VPS is:

openclaw update --tag 2026.4.19-beta.2

Then verify:

openclaw --version

A couple gotchas:

use the version without the leading v
openclaw update normally restarts the gateway for you
if you just want the beta lane instead of one exact beta, use:

#

openclaw update --channel beta

If you’re not sure how that VPS install was done, check first:

openclaw update status

Why that matters:

package install (npm/pnpm) → --tag 2026.4.19-beta.2 works
git/source install → --tag is ignored, so use openclaw update --channel beta instead

Docs:

https://docs.openclaw.ai/install/updating

#

https://docs.openclaw.ai/install/development-channels

If you want, paste the output of openclaw update status and I’ll tell you the exact command for your VPS setup.

#

Yep, then this is the one:

openclaw update --tag 2026.4.19-beta.2
openclaw --version

No leading v in the command.

If openclaw update status shows it’s a git/source install instead of package install, use:

openclaw update --channel beta

and then check:

#

openclaw --version

If you hit anything weird on the VPS after that, paste openclaw update status and openclaw --version and I’ll help decode it.

frosty anchor Apr 19, 2026, 9:55 PM

#

i cant paste screenshots here?

quartz oysterBOT Apr 19, 2026, 9:56 PM

#

No worries, you don’t need screenshots for this one.

Text is actually better. Please paste these as code blocks:

openclaw update status
openclaw --version

and if the beta install failed, also:

openclaw update --tag 2026.4.19-beta.2 --dry-run

Wrap the output like this:

#

```text
paste output here
```

That’ll be much easier to debug than a screenshot.

frosty anchor Apr 19, 2026, 9:57 PM

#

ok I am seeing v2026.4.19-beta.2 in openclaw interface but its looks like it wipe all my bot files away like the soul.md and others?

quartz oysterBOT Apr 19, 2026, 10:02 PM

#

That usually means it switched workspaces, not that it deleted your files.

Your SOUL.md, AGENTS.md, USER.md, etc. live in the agent workspace, and docs say the active one is controlled by agents.defaults.workspace. Current default is usually:

~/.openclaw/workspace

Older installs often used:

~/openclaw

So I’d check these first on the VPS:

#

grep -n "workspace" ~/.openclaw/openclaw.json || true
ls -la ~/.openclaw/workspace
ls -la ~/openclaw

If your files are sitting in ~/openclaw but the beta is now using ~/.openclaw/workspace, that would explain the “wiped” feeling.

A couple important bits:

don’t run openclaw setup yet, that can recreate defaults and muddy the picture
openclaw doctor also warns about extra workspace dirs
docs explicitly call out that keeping both ~/openclaw and ~/.openclaw/workspace around can cause confusing drift

Docs:

#

If you paste the output of those 3 commands, I can tell you exactly which workspace it’s using and how to point it back.

frosty anchor Apr 19, 2026, 10:09 PM

#

ls -la ~/.openclaw/workspace
ls -la ~/openclaw
44: "workspace": "/data/.openclaw/workspace",
total 128
drwxr-xr-x 17 node node 4096 Apr 17 15:57 .
drwx------ 15 node node 4096 Apr 19 18:07 ..
drwxr-xr-x 8 node node 4096 Apr 16 03:57 .git
drwxr-xr-x 2 node node 4096 Apr 15 21:20 .openclaw
-rw-r--r-- 1 node node 4349 Apr 17 15:57 AGENTS.md
-rw-r--r-- 1 node node 525 Apr 16 02:44 BOOT.md
-rw-r--r-- 1 node node 1778 Apr 15 21:19 BOOTSTRAP.md
-rw-r--r-- 1 node node 1401 Apr 17 15:49 HEARTBEAT.md
-rw-r--r-- 1 node node 727 Apr 15 21:19 IDENTITY.md
-rw-r--r-- 1 node node 1496 Apr 17 15:14 MEMORY.md
-rw-r--r-- 1 node node 1004 Apr 15 21:36 README.md
-rw-r--r-- 1 node node 8291 Apr 17 15:52 SOUL.md
-rw-r--r-- 1 node node 961 Apr 15 21:19 TOOLS.md
-rw-r--r-- 1 node node 6218 Apr 17 15:48 USER.md
drwxr-xr-x 2 node node 4096 Apr 15 21:36 agents
drwxr-xr-x 2 node node 4096 Apr 15 22:08 config
drwxr-xr-x 2 node node 4096 Apr 15 21:36 credentials
drwxr-xr-x 2 node node 4096 Apr 15 21:36 cron
drwxr-xr-x 2 node node 4096 Apr 15 21:36 identity
drwxr-xr-x 2 node node 4096 Apr 19 17:39 memory
drwxr-xr-x 2 node node 4096 Apr 15 21:36 playbooks
drwxr-xr-x 2 node node 4096 Apr 15 21:36 sessions
drwxr-xr-x 8 node node 4096 Apr 15 21:36 skills
drwxr-xr-x 2 node node 4096 Apr 15 21:20 state
drwxr-xr-x 2 node node 4096 Apr 15 21:36 system
-rw-r--r-- 1 node node 330 Apr 17 06:52 temp_config.json
drwxr-xr-x 3 node node 4096 Apr 17 14:51 trading
drwxr-xr-x 3 node node 4096 Apr 17 15:11 workspace
ls: cannot access '/data/openclaw': No such file or directory
root@a9f72862f797:~#

quartz oysterBOT Apr 19, 2026, 10:10 PM

#

Yeah, good news, they were not wiped.

Your active workspace is set to:

/data/.openclaw/workspace

and that directory clearly still has:

AGENTS.md
SOUL.md
USER.md
IDENTITY.md
TOOLS.md

So this looks more like the UI/session got weird, not file loss.

#

One thing I do see that’s suspicious:

BOOTSTRAP.md is still present

Docs say BOOTSTRAP.md is a one-time first-run file and should be removed after bootstrap. We’ve seen leftover BOOTSTRAP.md keep agents acting like they’re in first-run mode, which can feel like they “forgot” their workspace.

Safest next step:

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

Then refresh the UI and check again.

So at this point I’d treat it as two separate things:

#

workspace files are still there
agent/session state is weird, and that stale BOOTSTRAP.md is a likely culprit

Docs:

https://docs.openclaw.ai/concepts/agent-workspace

If you want, after restart paste what the agent does next, and I’ll help separate the workspace weirdness from the original OpenRouter routing bug.

frosty anchor Apr 19, 2026, 10:20 PM

#

openclaw gateway restart
Config warnings:\n- plugins: plugin: blocked plugin candidate: suspicious ownership (/data/.openclaw/extensions/oxylabs-ai-studio-openclaw, uid=1000, expected uid=0 or root)

🦞 OpenClaw 2026.4.19-beta.2 (dc3df91) — I've survived more breaking changes than your last three relationships.

│
◇ Config warnings ───────────────────────────────────────────────────────────────────────╮
│ │
│ - plugins: plugin: blocked plugin candidate: suspicious ownership │
│ (/data/.openclaw/extensions/oxylabs-ai-studio-openclaw, uid=1000, expected uid=0 or │
│ root) │
│ │
├─────────────────────────────────────────────────────────────────────────────────────────╯
18:19:33 [restart] lsof failed during initial stale-pid scan for port 18789: ENOENT
Gateway service disabled.
Start with: openclaw gateway install
Start with: openclaw gateway
Start with: systemctl --user start openclaw-gateway.service
Start with: systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
Start with: If you're in a container, run the gateway in the foreground instead of openclaw gateway.
root@a9f72862f797:~#

quartz oysterBOT Apr 19, 2026, 10:21 PM

#

Yep, that output means openclaw gateway restart did not actually restart your running gateway.

What happened:

you’re in a container / non-systemd environment
openclaw gateway restart tried to use the managed service path
there is no user service installed, so it bailed with Gateway service disabled.

So this part is expected:

If you're in a container, run the gateway in the foreground instead of `openclaw gateway`.

A few important notes:

the oxylabs-ai-studio-openclaw ownership warning is separate

#

lsof failed ... ENOENT is also not the main problem
this means we haven’t actually tested the BOOTSTRAP.md fix yet

Best next step

If this OpenClaw instance normally runs inside that container, either:

restart the container/supervisor that runs it, or
for a quick test, start it directly in the foreground:

openclaw gateway

and keep that shell open.

I would not use openclaw gateway install here unless this is a normal systemd-managed VPS and not a containerized setup.

#

So the real question now is: how is this gateway normally launched?

Docker / docker compose
Coolify / Railway / Fly / etc
manually with openclaw gateway
pm2 / supervisor / something else

Tell me that piece and I can give you the exact restart command.

frosty anchor Apr 19, 2026, 10:24 PM

#

I restarted the docker VPS container...logged into openclaw interface and its still running the bootstrap and acting like I need to set it up: "Hey. I just came online. Who am I? Who are you?

Bootstrap’s still not complete because I need your input for the identity part first. Give me my name, creature, vibe, and emoji — or just say “pick for me” and I’ll set a solid default and keep going."

quartz oysterBOT Apr 19, 2026, 10:25 PM

#

I’m checking the bootstrap logic, because this sounds like either the file is still present or the session store still thinks the workspace is unbootstrapped.

#

That message means OpenClaw still thinks bootstrap is pending for the workspace that session is using.

Given the current code/docs, that usually means one of two things:

BOOTSTRAP.md still exists in the active workspace, or
the UI is attached to a different agent/workspace than the one we inspected

Can you run these two and paste them?

ls -l /data/.openclaw/workspace/BOOTSTRAP*
openclaw status

Why I’m asking:

if /data/.openclaw/workspace/BOOTSTRAP.md still exists, it will keep triggering that first-run prompt

#

if it’s already gone and only BOOTSTRAP.md.bak exists, then the UI is probably landing on another workspace/agent

If BOOTSTRAP.md is still there, move it aside exactly:

mv /data/.openclaw/workspace/BOOTSTRAP.md /data/.openclaw/workspace/BOOTSTRAP.md.bak

then restart the container again.

So yeah, this is looking like a separate bootstrap/workspace issue, not the original OpenRouter routing bug.

frosty anchor Apr 19, 2026, 10:31 PM

#

Item │ Value │
├──────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ OS │ linux 6.8.0-107-generic (x64) · node 22.22.2 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (config) │
│ Update │ pnpm · npm latest 2026.4.15 (local newer) │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 35ms · auth token · a9f72862f797 (172.16.1.2) app 2026.4.19-beta.2 linux 6.8.0-107-generic │
│ Gateway self │ a9f72862f797 (172.16.1.2) app 2026.4.19-beta.2 linux 6.8.0-107-generic │
│ Gateway service │ systemd not installed │
│ Node service │ systemd not installed │
│ Agents │ 1 · no bootstrap files · sessions 4 · default main active 7m ago │
│ Memory │ 6 files · 25 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 │ 30m (main) │
│ Sessions │ 4 active · default openai/gpt-5.4 (200k ctx) · ~/.openclaw/agents/main/sessions/sessions.json

quartz oysterBOT Apr 19, 2026, 10:32 PM

#

That’s actually a really useful clue.

openclaw status says:

Agents: 1 · no bootstrap files

So the workspace is no longer bootstrapping. Good news.

That means the “who am I?” prompt is almost certainly coming from a stale session, not from your current workspace state. And you’ve got:

Sessions: 4 active

So I’d stop poking the workspace now and do this instead:

#

Start a brand-new session in the UI, don’t continue the old one
(or type /new if you’re in the chat box)
See whether the fresh session still shows the bootstrap prompt
Then test the OpenRouter routing again in that fresh session

At this point I think the picture is:

bootstrap/workspace is fixed
old session metadata is still stale
that same stale session state may also be part of the original provider=openai problem

So yeah, I think we’ve been chasing session state drift, not wiped files.

If a fresh session still shows bootstrap or still routes to provider=openai, send me that result next. That’ll tell us whether the remaining bug is in session persistence instead of workspace setup.

frosty anchor Apr 19, 2026, 10:34 PM

#

ok /new and my old agent came back

quartz oysterBOT Apr 19, 2026, 10:35 PM

#

Nice, that’s a really good sign.

So we’ve confirmed:

your files/workspace were not wiped
the bootstrap weirdness was a stale session
/new got you back onto the real agent state

Now we can finally test the original bug cleanly.

From this fresh session, try one normal prompt. Then tell me which of these happens:

works normally
still resolves to provider=openai and fails with 401
no auth error, but you get the empty-response case again (payloads=0 / stopReason=stop)

If it works now, I’d call this stale session metadata more than a core routing regression.

#

If it still fails in the fresh session, then we dig into the live session model metadata next.

frosty anchor Apr 19, 2026, 10:37 PM

#

I asked him what model he is currently running on and he responded : Right now I’m running openrouter/openai/gpt-5.4.

quartz oysterBOT Apr 19, 2026, 10:38 PM

#

That’s encouraging, but I wouldn’t treat it as proof yet.

Agents can self-report the configured model ref, while the actual request path can still be different underneath. So this tells us:

the fresh session sees openrouter/openai/gpt-5.4
but we still need to verify the actual provider used on a real run

So the real test now is:

ask one normal question
see whether it answers
if it fails, check whether logs still show provider=openai or something else

If it answers normally in the fresh session, I think the big culprit was stale session state.

If it still fails, paste the next error/log line from that fresh run and we can pin down whether:

routing is still degrading to provider=openai, or

#

the beta fixed routing but there’s still some separate response-parsing issue.

frosty anchor Apr 19, 2026, 10:39 PM

#

a normal question like what?

quartz oysterBOT Apr 19, 2026, 10:39 PM

#

Yep, something boring and text-only. For example:

What is 17 * 23?
Explain in one sentence why the sky looks blue.
Write two sentences about penguins.

The goal is just to test:

does the fresh session return a normal answer
or does it still error / go empty

So I’d use something simple like:

Explain in one sentence why the sky looks blue.

#

If it answers, great. If not, grab the next log/error from that run.

frosty anchor Apr 19, 2026, 10:40 PM

#

Penguins are flightless birds built for the water, with dense bones and strong flippers that make them excellent swimmers. They live mostly in the Southern Hemisphere, where they hunt fish, krill, and squid in cold ocean waters.

quartz oysterBOT Apr 19, 2026, 10:40 PM

#

Nice, that’s the answer I wanted to see.

So at this point the evidence says:

v2026.4.19-beta.2 can answer normally in a fresh session
your workspace/persona files are fine
the bootstrap weirdness was a stale session
the original OpenRouter breakage was very likely stale persisted session metadata, not a universal “beta is broken” problem

My practical takeaway:

keep using the fresh session
if an old thread/session acts weird, use /new
I would not trust the old sessions as evidence anymore

So the clean diagnosis is basically:

#

old session state drift caused the fake bootstrap behavior
old persisted session model metadata likely caused the provider=openai / 401 behavior
fresh session on v2026.4.19-beta.2 looks healthy

If you want, I can help you with one final cleanup pass for the stale sessions, but the important part is: your agent is back. 🎉

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

frosty anchor Apr 19, 2026, 10:41 PM

#

I seem to have lost access to my bot in discord though

quartz oysterBOT Apr 19, 2026, 10:41 PM

#

Let me check the Discord docs before I send you in the wrong direction.

#

Ah, that sounds like a separate Discord-channel issue now.

When you say “lost access”, do you mean:

the bot is offline / gone from the server
it’s online but not replying
slash commands / mentions stopped working
DMs stopped working

Best first check from the VPS:

openclaw status --deep
openclaw gateway status

And if it’s online but silent, trigger one Discord message to it, then run:

#

openclaw logs --follow

What I’m trying to separate:

gateway/session/model issue, which looks mostly fixed now
Discord channel auth/config issue, which is a different layer

If you paste openclaw status --deep, I can narrow it down pretty fast.

frosty anchor Apr 19, 2026, 10:59 PM

#

bot is showing online but not answering

quartz oysterBOT Apr 19, 2026, 11:00 PM

#

Got it, that’s actually a useful split.

If the bot is online but silent, the next step is to see whether the Gateway is even receiving the Discord message.

Please do this on the VPS:

openclaw status --deep
openclaw logs --follow

Then, while logs --follow is running, send the bot a simple message in Discord like:

ping

#

What we learn from that:

nothing shows up in logs → Discord inbound delivery / permissions / allowlist problem
message shows up in logs but no reply → OpenClaw got the event, so it’s a routing/session/reply problem instead

If you paste:

the Discord section from openclaw status --deep
and the few log lines right after you ping it

I can usually tell which side is broken pretty quickly.

frosty anchor Apr 19, 2026, 11:06 PM

#

Im having a hard time locating that

quartz oysterBOT Apr 19, 2026, 11:06 PM

#

No worries. Easiest path: just run these exactly inside the VPS/container shell and paste the output here.

First:

openclaw status --deep

You don’t need to find a special section, just paste the whole output.

Then run this and leave it open:

openclaw logs --follow

While that is running, send your bot a Discord message like:

#

ping

Then copy the next few lines that appear.

If openclaw logs --follow doesn’t show anything or errors, use the fallback from the docs:

tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

So basically, I need:

full openclaw status --deep
a few log lines right after you send ping

#

That’ll tell us whether Discord is reaching the gateway at all.

frosty anchor Apr 19, 2026, 11:13 PM

#

when I look in openclaw config it doesnt show discord configured anymore

quartz oysterBOT Apr 19, 2026, 11:13 PM

#

I’m checking the exact Discord config keys so I don’t make this worse.

#

Ah, yeah, that would explain the silence.

Per the docs, Discord auth comes from:

channels.discord.token
or fallback env var DISCORD_BOT_TOKEN for the default account

So on Docker/VPS, the likely problem is:

the new container no longer has DISCORD_BOT_TOKEN, or
the channels.discord block/reference disappeared from config

Please check without pasting the actual token:

printenv DISCORD_BOT_TOKEN | wc -c

#

grep -n '"discord"' ~/.openclaw/openclaw.json || true

What I’m looking for:

if DISCORD_BOT_TOKEN is basically empty, your new container lost the Discord secret
if the env var exists but config lost the reference, re-add it with the documented commands:

openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set channels.discord.enabled true --strict-json

Then restart the container/gateway.

Important: don’t paste the token value here. Just paste:

#

the number from wc -c
the grep output

Docs:

https://docs.openclaw.ai/channels/discord

frosty anchor Apr 19, 2026, 11:17 PM

#

it came back "0"

quartz oysterBOT Apr 19, 2026, 11:18 PM

#

Yep, there’s the problem.

0 means this container currently has no DISCORD_BOT_TOKEN in its environment.

So the new container came up without your Discord bot secret, which is why the bot is online/weird/silent.

What to do

Put DISCORD_BOT_TOKEN back into the Docker env/secrets for this container, then restart it.

If you’re using Docker Compose, it’s usually something like:

environment:
  DISCORD_BOT_TOKEN: ${DISCORD_BOT_TOKEN}

#

or a secret/env-file equivalent.

Then restart the container.

After the env var is back

If your config also lost the env reference, re-add it with the documented command:

openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set channels.discord.enabled true --strict-json

Then restart again.

So the Discord part is much clearer now:

#

OpenRouter/session issue: mostly fixed by fresh session + beta
Discord silence: new container lost DISCORD_BOT_TOKEN

If you want, paste your Docker Compose environment: block with the secret value redacted, and I’ll tell you exactly what line is missing.

frosty anchor Apr 19, 2026, 11:30 PM

#

Ok DISCORD_BOT_TOKEN was missing from the .env file — added it back and restarted and agent is working in discord again

quartz oysterBOT Apr 19, 2026, 11:31 PM

#

Nice, glad we caught it. 🎉

So the final picture looks like:

Old/stale sessions were causing the fake bootstrap/weird state
→ /new fixed that
Discord stopped working because DISCORD_BOT_TOKEN was missing from .env
→ adding it back + restart fixed Discord
Fresh session on v2026.4.19-beta.2 was able to answer normally again

So this ended up being a mix of:

stale session state
missing Discord env var

#

not one single OpenRouter-only failure.

If an old thread acts haunted again, I’d use /new first before trusting the behavior.

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

frosty anchor Apr 19, 2026, 11:32 PM

#

can you give me a recap of each problem we discussed and what the solution was so I can refer to later?

quartz oysterBOT Apr 19, 2026, 11:32 PM

#

Yep, here’s the clean recap.

1) OpenRouter started failing after `v2026.4.15`

Symptom

Runs were resolving to provider=openai and failing with 401
Config was set to openrouter/openai/gpt-5.4

What we found

Old session state looked stale/weird
A fresh session on v2026.4.19-beta.2 was able to answer normally
That suggests the breakage was at least partly stale persisted session metadata, not just “OpenRouter is globally broken”

What fixed it

Update to v2026.4.19-beta.2
Start a fresh session with /new

#

2) It looked like your bot files were wiped (`SOUL.md`, etc.)

Symptom

The agent acted like it had no identity and wanted to bootstrap again

What we found

The workspace was still there at:
- /data/.openclaw/workspace
It still contained:
- AGENTS.md
- SOUL.md
- USER.md
- IDENTITY.md
- TOOLS.md
openclaw status later showed:
- Agents: 1 · no bootstrap files

Conclusion

#

Your files were not deleted
The bootstrap behavior was from a stale old session, not missing workspace files

What fixed it

Start a fresh session with /new

3) The agent worked in Control UI but stopped answering in Discord

Symptom

Bot showed online in Discord but didn’t answer

What we found

Discord no longer appeared configured
Checking the env var showed:
- DISCORD_BOT_TOKEN was missing
printenv DISCORD_BOT_TOKEN | wc -c returned 0

#

What fixed it

Add DISCORD_BOT_TOKEN back to the .env file
Restart the container

4) How to get the beta on the VPS

What we used

openclaw update --tag 2026.4.19-beta.2

Important

Use the version without the leading v

#

Final practical takeaways

If an old session starts acting haunted, try /new first
If Discord goes silent after a deploy/update, check:
- DISCORD_BOT_TOKEN
Your workspace files were fine, this was mostly:
- stale session state
- plus a missing Discord env var

If you want, I can turn this into a shorter “copy/paste note to future me” version too.

frosty anchor Apr 19, 2026, 11:33 PM

#

yes please

quartz oysterBOT Apr 19, 2026, 11:33 PM

#

Sure, here’s the short version:

OpenClaw recap

1. OpenRouter / 401 issue
- Symptom: runs resolved to provider=openai and failed with 401
- Likely cause: stale session metadata after upgrade
- Fix: updated to v2026.4.19-beta.2 and started a fresh session with /new

2. Bot looked “reset” / wanted bootstrap again
- Symptom: agent acted like SOUL.md / identity files were gone
- Reality: workspace files were still present in /data/.openclaw/workspace
- Cause: stale old session, not deleted files
- Fix: /new

#

3. Discord bot online but not answering
- Cause: DISCORD_BOT_TOKEN was missing from .env
- Fix: add DISCORD_BOT_TOKEN back to .env and restart container

4. Beta update command
- openclaw update --tag 2026.4.19-beta.2
- no leading “v”

Main lesson
- If old sessions act weird after an update, try /new first
- If Discord goes silent, check DISCORD_BOT_TOKEN in the container env/.env

Glad we got it sorted.

frosty anchor Apr 19, 2026, 11:42 PM

#

how do we mark this closed now?

#v2026.4.15 breaks OpenRouter routing - resolves to openai provider instead

What I’d do

Best next step

What to do

After the env var is back

1) OpenRouter started failing after v2026.4.15

2) It looked like your bot files were wiped (SOUL.md, etc.)

3) The agent worked in Control UI but stopped answering in Discord

4) How to get the beta on the VPS

Final practical takeaways

1) OpenRouter started failing after `v2026.4.15`

2) It looked like your bot files were wiped (`SOUL.md`, etc.)