OpenClaw multiple errors on install | Friends of the Crustacean 🦞🤝 | Page 1

delicate berry Apr 18, 2026, 10:30 PM

#

I am new here and I would appreciate any help I can get. Even ChatGpt and Grok are not helpful at this point...

I am running OpenClaw 2026.4.15 (041266a)
openrouter/claude 3.7 sonnet and things were going well. I was getting too many heartbeat requests in the chat so I did an update of openclaw. Since then I can see my agent responding in chat and terminal (...) and it's as if he answered with time stamp but his response does not show on my end. Both chatgpt and grok told me to do a clean reinstall so I backed up .openclaw and reinstalled ubuntu 24.04 from scratch with openclaw and chose a different model gpt4o github-copilot and still no change... It has been giving me messages of error in gateway and pairing and other small details.
I am at a point where I have no idea what else to do.
Here is what chatgpt says

Alright — at this point it’s clear you’re stuck in a specific OpenClaw failure loop, not a general setup issue.

Let me cut through all the noise and tell you exactly what’s happening:

🔴 What’s ACTUALLY broken (root cause)

From your logs:
pairing required
scope-upgrade
incomplete turn detected (payloads=0)
UI shows nothing
model runs but no output reaches UI

👉 This is NOT your API key
👉 This is NOT your model
👉 This is NOT your JSON anymore

This is:
❌ Device pairing + gateway auth mismatch

Your agent is generating responses, but:
The gateway rejects the connection upgrade
The UI never receives the payload
So you see: “agent responds but nothing shows”
⚠️ Why your fixes didn’t work

You tried:
editing config ✅
adding token file ✅
changing models ✅
running doctor ✅

But:
OpenClaw is overriding or ignoring parts of your config because the device is NOT paired.

That’s why:
settings disappear in UI
pairing errors keep coming back
gateway loops forever
🧠 The key insight

This line is everything:
reason="scope-upgrade"
pairing-required

👉 Your CLI/UI is trying to escalate permissions
👉 Gateway refuses because device is not trusted

frigid flameBOT Apr 18, 2026, 10:30 PM

#

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

finite sableBOT Apr 18, 2026, 10:30 PM

#

edgy baneBOT Apr 18, 2026, 10:32 PM

#

Let me check the local docs paths so I can give you something grounded, not guesses.

#

I found the pairing/device-auth docs. I want one more pass on the specific “payloads=0 / incomplete turn” symptom before I steer you the wrong way.

#

That’s frustrating, and I don’t think another clean reinstall is the move.

From the docs, ChatGPT is collapsing two different symptoms into one cause:

pairing required / scope-upgrade usually means the browser/device connecting to Control UI needs approval
incomplete turn detected ... payloads=0 means the run ended with no user-visible payload

Those can happen together, but pairing required alone does not prove “OpenClaw is ignoring config”.

Also, if you restored ~/.openclaw, you may have restored the same pairing/session state, so reinstalling Ubuntu would not clear that part.

Please paste these outputs (redact tokens/secrets):

openclaw --version
openclaw status --all

#

openclaw gateway status
openclaw channels status --probe
openclaw devices list
openclaw doctor

Then reproduce it once and grab the log around that moment:

openclaw logs --follow

If Control UI says disconnected (1008): pairing required, the docs say to approve the current pending device:

#

openclaw devices list
openclaw devices approve <requestId>

Important: re-run devices list right before approving, because retries can create a new requestId.

Also tell me which surface is blank:

Control UI / dashboard
terminal / TUI
external chat channel (Discord, Telegram, etc.)

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

#

Paste those outputs and I’ll help you narrow it down.

delicate berry Apr 18, 2026, 10:46 PM

#

So the UI looks fine. It's just that although he responds his responses do not show on the frontend. I use the dashboard browser chat. Now the dashboard is giving me the following message when I say hi in the chat:

⚠️ Agent failed before reply: No API key found for provider "github-copilot". Auth store: /home/soulint/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/soulint/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. | No API key found for provider "github-copilot". Auth store: /home/soulint/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/soulint/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.
Logs: openclaw logs --follow

edgy baneBOT Apr 18, 2026, 10:48 PM

#

Nice, this narrows it down a lot. I’m checking the auth docs so I can give you the exact fix, not folklore.

#

Aha, this is the real blocker.

The dashboard/frontend is not the current problem. The run is failing before reply because your selected provider is github-copilot, and the main agent has no Copilot auth:

No API key found for provider "github-copilot"... /agents/main/agent/auth-profiles.json

So I would ignore the earlier “pairing is the root cause of everything” theory for now. This new error is much more concrete.

Fix options

Option 1, stay on GitHub Copilot
Run this in a real terminal:

openclaw models auth login-github-copilot
openclaw models status

#

openclaw models status --probe

Then set/confirm the model:

openclaw models set github-copilot/gpt-4o

Important: the Copilot login flow needs an interactive TTY, so run it directly in terminal, not through a headless flow.

Option 2, go back to your previous working provider
If you meant to use OpenRouter again, switch the model back instead of using Copilot, then verify auth:

#

openclaw configure --section model
openclaw models status
openclaw models status --probe

One important detail

Auth is per agent, and your error already points at the main agent’s auth store:

~/.openclaw/agents/main/agent/auth-profiles.json

So openclaw agents add <id> is probably not the thing you need here unless you’re creating another agent. You need auth for the main agent’s selected provider.

What I’d do next

Run openclaw models auth login-github-copilot
Run openclaw models status
Try the dashboard chat again

#

If it still fails, paste:

openclaw models status
openclaw models status --probe
openclaw logs --follow

Docs:
https://docs.openclaw.ai/providers/github-copilot
https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/cli/configure

Don’t reinstall again yet, you’re finally on a real error now.

delicate berry Apr 19, 2026, 6:12 PM

#

It gets stuck at the login github command. It keeps trying and I had to cancel after a good 30+mins. The chat still gives me the same message

⚠️ Agent failed before reply: No API key found for provider "github-copilot". Auth store: /home/soulint/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/soulint/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. | No API key found for provider "github-copilot". Auth store: /home/soulint/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/soulint/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.
Logs: openclaw logs --follow

edgy baneBOT Apr 19, 2026, 6:14 PM

#

I’m checking the Copilot auth docs and status notes for the “login hangs forever” case, because that changes the best next step.

#

Got it. If openclaw models auth login-github-copilot hangs for 30+ minutes, I would stop using that path for now.

Your current error is still auth, not frontend:

dashboard loads
agent starts
selected provider = github-copilot
main agent has no usable Copilot credential
result: Agent failed before reply

Fastest path now

Option A, skip Copilot and get unstuck

If OpenRouter was your intended setup, switch back to that provider instead of fighting Copilot:

#

openclaw configure --section model
openclaw models status
openclaw models status --probe

Pick your OpenRouter model again, then test the dashboard chat.

Option B, use Copilot without the hanging login flow

The docs say Copilot can also come from env vars. Since the gateway runs as a service, the most reliable path is to put the token in:

~/.openclaw/.env

with:

#

COPILOT_GITHUB_TOKEN=YOUR_TOKEN_HERE

(Do not paste the token here.)

Then restart and verify:

openclaw gateway restart
openclaw models status
openclaw models status --probe

The docs also say GH_TOKEN or GITHUB_TOKEN work, but COPILOT_GITHUB_TOKEN is the preferred one.

Why I’m steering you this way

#

The FAQ explicitly notes that service-launched OpenClaw may not see your shell env, and recommends ~/.openclaw/.env for tokens. So even if you had a GitHub token in your shell, the dashboard/gateway may still not see it.

What I’d do in your shoes

Pick one provider, OpenRouter or Copilot
Make openclaw models status show that provider as authenticated
Only then test the dashboard again

If you want, paste the output of:

openclaw models status
openclaw models status --probe

and I’ll tell you exactly what it says, just redact secrets.

Docs:

#

https://docs.openclaw.ai/providers/github-copilot
https://docs.openclaw.ai/help/faq#i-set-copilot_github_token-but-models-status-shows-shell-env-off-why
https://docs.openclaw.ai/cli/models

delicate berry Apr 19, 2026, 6:23 PM

#

Still the same message in the dashboard. Here is the status

🦞 OpenClaw 2026.4.15 (041266a) — Welcome to the command line: where dreams compile and confidence segfaults.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/openrouter/auto (from openrouter/auto)
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): github-copilot/gpt-4o

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

openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...e2b2154c

OAuth/token status

none

🦞 OpenClaw 2026.4.15 (041266a) — I'll refactor your busywork like it owes me money.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/openrouter/auto (from openrouter/auto)
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): github-copilot/gpt-4o

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

openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...e2b2154c

OAuth/token status

none

Auth probes
┌────────────────────────────┬──────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├────────────────────────────┼──────────────────────────────┼────────────┤
│ openrouter/openrouter/auto │ openrouter:default (api_key) │ ok · 8.3s │
└────────────────────────────┴──────────────────────────────┴────────────┘
Probed 1 target in 19.4s

edgy baneBOT Apr 19, 2026, 6:24 PM

#

This is helpful. I want to verify one model-selection detail in the docs, because your status output shows a weird mismatch: default = OpenRouter, but configured models = GitHub Copilot only. That smells important.

#

Nice, this finally explains it.

Your status shows a model mismatch:

Default model is OpenRouter, and its auth probe is OK
Configured models contains only github-copilot/gpt-4o
the dashboard session is still trying to use github-copilot

So this does not look like “frontend swallowed the reply”. It looks like the dashboard/session is stuck on the wrong model, while your healthy provider is OpenRouter.

What I’d do now

Run the model wizard again:

openclaw configure --section model

#

In that wizard, make these agree:

set the primary/default model to OpenRouter
remove github-copilot/gpt-4o from the model allowlist, or add your OpenRouter model to the allowlist too

Right now they conflict.

After that, in the dashboard chat:

/reset
/model status

If /model status still shows GitHub Copilot, switch it there with /model and pick the OpenRouter model.

Why this matters

The docs say agents.defaults.models is the allowlist for /model and session overrides. Your output shows that allowlist is basically still Copilot-only, even though your default/auth-healthy provider is OpenRouter.

#

That’s the exact kind of stale mismatch that can make a session keep failing before a normal reply.

If you want the shortest possible test

After openclaw configure --section model, do:

openclaw models status

You want it to stop showing:

Configured models (1): github-copilot/gpt-4o

and instead show your OpenRouter model in that configured-models list too.

#

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/cli/configure

If you paste the updated openclaw models status after the wizard, I can tell you immediately if it’s fixed.

delicate berry Apr 19, 2026, 6:34 PM

#

So the status in the terminal looks fine

🦞 OpenClaw 2026.4.15 (041266a) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/openrouter/auto (from openrouter/auto)
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : OpenRouter -> openrouter/auto
Configured models (1): openrouter/auto

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

openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...e2b2154c

OAuth/token status

none

But in the chat here is what it says after reset

A new session was started via /new or /reset. If runtime-provided startup context is included for this first turn, use it before responding to the user. Then greet the user in your configured persona, if one is provided. Be yourself - use your defined voice, mannerisms, and mood. Keep it to 1-3 sentences and ask what they want to do. If the runtime model differs from default_model in the system prompt, mention the default model. Do not mention internal steps, files, tools, or reasoning.
Current time: Sunday, April 19th, 2026 - 1:31 PM (America/Cancun) / 2026-04-19 18:31 UTC
You 1:31 PM
Assistant 1:31 PM auto
?

Failed to set model: GatewayRequestError: model not allowed: github-copilot/status
system 1:31 PM

Note that in the identifier in the chat it says system and not which bot I am using

#

Although at the top I have openrouter auto selected

edgy baneBOT Apr 19, 2026, 6:36 PM

#

That error string is super revealing. I’m checking whether /model status can get misparsed on 2026.4.15, because github-copilot/status does not look like a real model ref.

#

Okay, I see the trap now.

Your backend config is fine now. OpenRouter auth is healthy. The thing that’s still broken is the dashboard session override.

Two key details:

the Control UI model picker writes a persistent session override
in current code, /new and /reset do not clear user model overrides

So this is why you’re seeing:

terminal: OpenRouter is healthy
dashboard chat: still behaves like it’s on GitHub Copilot

That model not allowed: github-copilot/status message is basically the stuck session telling on itself.

What to do in the dashboard

#

In the chat header model picker (top of the chat), set the model to either:

inherit / default, or
your OpenRouter model explicitly

Then start a fresh message again with just:

hi

I would not use /reset as the main fix here, because it preserves the session override.

Important

The system label you’re seeing there is normal for a Control UI system message. That part is not the bug.

If the picker still looks stuck

#

Then I’d try this order:

change the chat header model picker to inherit or OpenRouter
send a plain hi
if it still says GitHub Copilot, open a brand-new dashboard chat/session instead of only /reset

Docs:
https://docs.openclaw.ai/web/control-ui
https://docs.openclaw.ai/concepts/models

If you want, send a screenshot of the dashboard chat header area with the model picker, because I’m pretty sure that’s where this is stuck now.

#

I’m checking one last thing in the docs/source: whether the chat header can show one model while the persisted session override is actually something else. Your “top says OpenRouter, error says GitHub Copilot” mismatch suggests exactly that.

#

Yep, and that’s the clue.

If the top picker says OpenRouter but the error still says GitHub Copilot, I would not trust the top label. The docs/source point to the server-side session override winning here, not the visible header state.

Two important bits:

the Control UI picker writes a persistent session override
live session reconciliation prefers the persisted session override
/reset keeps user overrides, so it can look “fresh” while still being pinned underneath

So the likely situation is:

UI header looks like OpenRouter
gateway session is still actually pinned to GitHub Copilot

Best next step

Use the Sessions panel / session controls in Control UI, not /reset, and do one of these:

#

set the session model to inherit/default
or create a completely new dashboard session/chat
then send a plain:

hi

I would avoid /model status on this stuck session for now. It’s muddying the signal.

Short version

This does not look like “pairing blocked the UI”.
It looks like dashboard UI state and persisted session model state are out of sync.

If you can, send a screenshot of:

the chat header with the model picker
the Sessions sidebar/panel for that active chat

#

That should make the stuck override obvious fast.

delicate berry Apr 19, 2026, 6:53 PM

#

So a few things strange here. The only choices I get in the drop down is openrouter. In the agent>agent>overview the primary model is not set and gives me also only openrouter. When I set it to openrouter and save it goes back to not set. Tried various times. The chat has gone back to the original problem.

I am new here. Sorry... Not seeing how I can send you a picture in this chat. Drag and drop does not work and I don't see the button anywhere

edgy baneBOT Apr 19, 2026, 6:54 PM

#

No need to apologize, this is weird, not you.

And no worries on screenshots, text is enough. Let’s bypass the UI entirely for a minute, because the UI saving back to “not set” smells buggy.

Run these in terminal:

openclaw models set openrouter/auto
openclaw models status
openclaw gateway restart

Then reopen the dashboard:

openclaw dashboard

#

And start a brand-new chat/session there, then send just:

hi

Why this path

The docs-backed CLI command for setting the model is:

openclaw models set <provider/model>

So if the dashboard UI keeps reverting, the CLI is the cleaner source of truth here.

If it still goes weird

Please paste these too:

#

openclaw config get agents.defaults.model
openclaw config get agents.defaults.models
openclaw status --all

That will tell us whether the config is actually being written and whether the gateway is reading the same thing.

Docs:
https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/cli/configure
https://docs.openclaw.ai/help/faq

If you paste the output of those 3 commands after models set, I can tell you the next step fast.

delicate berry Apr 19, 2026, 7:10 PM

#

So I am trying to send you the results and discord is saying I do not have the permission. Also the + on the left of the chat when clicked only shows use apps... no option to send file or screenshots... How can I get you the results of the test?

Basically everything "looks" ok. The only thing standing out is the following message

! Port 18789
Port 18789 is already in use.

pid 105595 soulint: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown

edgy baneBOT Apr 19, 2026, 7:11 PM

#

You don’t need screenshots, plain text is totally fine.

Discord is probably blocking file uploads in that thread, but you can still paste the output directly as text, even split across 2-3 messages if needed.

Also, this part is not the problem:

Port 18789 is already in use.
- pid ... openclaw-gateway (127.0.0.1:18789)
- Gateway already running locally.

That just means your gateway is already running on the normal port.
And Tailscale: off · unknown is irrelevant if you’re using the dashboard locally.

Please paste these as plain text

#

openclaw gateway status
openclaw config get agents.defaults.model
openclaw config get agents.defaults.models

Then do this:

run:

openclaw logs --follow

in the dashboard, send just:

hi

#

copy the 15-30 log lines around that exact attempt and paste them here

If Discord complains about length, split it into multiple replies.
Just make sure to not paste any full tokens/secrets.

At this point the port warning is a red herring. The next useful signal is the live log around one failed dashboard message.

delicate berry Apr 19, 2026, 7:13 PM

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/soulint/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/soulint/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 105595 soulint: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 6 eligible · 0 missing · /home/soulint/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

edgy baneBOT Apr 19, 2026, 7:13 PM

#

This helps a bit, but it’s still the generic diagnosis output, not the runtime details we need.

The port warning is still just “gateway already running”, so we can ignore that.

Please run these exact commands and paste the text output:

openclaw gateway status
openclaw config get agents.defaults.model
openclaw config get agents.defaults.models

Then, in another terminal:

openclaw logs --follow

#

With logs --follow running, go to the dashboard and send:

hi

Then copy the log lines that appear right around that attempt and paste them here.

So basically I need 4 things:

openclaw gateway status
openclaw config get agents.defaults.model
openclaw config get agents.defaults.models
the fresh openclaw logs --follow lines from one failed hi

You’re actually doing fine here, we’re just trying to get the right output now.

delicate berry Apr 19, 2026, 7:16 PM

#

It just does not let me send the results. Keeps telling me to buy nitro or I do not have permission

Version │ 2026.4.15 │
│ OS │ linux 6.17.0-20-generic (x64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15

#

Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 38ms · auth token · PeaceAtLast (192.168.1.20) │
│ │ app 2026.4.15 linux 6.17.0-20-generic │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ systemd installed · enabled · running (pid 105595, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 1 bootstrapping · 1 active · 1 sessions │
│ Secrets │ none

#

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────────────┘

Agents
┌────────────┬────────────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────┤
│ main │ PRESENT │ 1 │ 3m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴──────────────────────────────────────────────────────────────────────────┘

edgy baneBOT Apr 19, 2026, 7:17 PM

#

Got it. No files then, we can do this with tiny text snippets only.

Please send just these small bits, even one per message if needed:

1) Model config

Run:

openclaw config get agents.defaults.model

Paste the full output.

Run:

openclaw config get agents.defaults.models

Paste the full output.

#

2) Gateway status, but only 2 lines

Run:

openclaw gateway status

From that, paste only these lines:

Runtime: ...
RPC probe: ...

3) One fresh error line from logs

Run:

openclaw logs --follow

Then send hi in the dashboard.

#

Now paste only the first few new lines that mention one of these words:

error
failed
model
chat

So, super small, no screenshots, no files.

You do not need Nitro for this, we only need a few text lines.

delicate berry Apr 19, 2026, 7:17 PM

#

🦞 OpenClaw 2026.4.15 (041266a)
I can't fix your code taste, but I can fix your build and your backlog.

{
"primary": "openrouter/auto"
}

🦞 OpenClaw 2026.4.15 (041266a) — I don't have opinions about tabs vs spaces. I have opinions about everything else.

{
"openrouter/auto": {
"alias": "OpenRouter"
}
}

🦞 OpenClaw 2026.4.15 (041266a) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

│
OpenClaw status --all

#

🦞 OpenClaw 2026.4.15 (041266a) — Your .env is showing; don't worry, I'll pretend I didn't see it.

{
"openrouter/auto": {
"alias": "OpenRouter"
}
}

edgy baneBOT Apr 19, 2026, 7:18 PM

#

Aha, this gives us a real clue. I’m checking the docs/source for the “agent stuck bootstrapping” cases, because that can absolutely cause weird half-started dashboard behavior.

#

Aha, this is the first line that really looks wrong:

Agents │ 1 total · 1 bootstrapping · 1 active · 1 sessions

For a setup you’ve already been using, bootstrapping should usually be 0.

The docs say first-run bootstrapping creates BOOTSTRAP.md, asks the setup questions, then removes BOOTSTRAP.md when finished. If that file is still hanging around, the agent can stay half-initialized.

Please check this exact file:

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

If it exists, that is very likely the problem.

#

Then, safest next step is to move it aside (not delete it), then restart:

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

Then check again:

openclaw gateway status

What I want to see after that is the agent no longer showing 1 bootstrapping.

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

#

If BOOTSTRAP.md does not exist, paste just the output of that ls -l command and we’ll go to the next suspect.

#

Yep, that’s the smoking gun. 🎯

Agent main │ Bootstrap file │ PRESENT

That means the agent still thinks it’s in first-run bootstrapping.

Per the docs, BOOTSTRAP.md should be removed once bootstrapping finishes. If it’s still present, the agent can stay stuck in this weird half-initialized state.

Do this

Move it aside, then restart the gateway:

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

#

Then check:

openclaw gateway status

What we want now is for that Bootstrap file field to stop showing PRESENT.

Then go back to the dashboard and send a plain:

hi

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

#

If it still acts weird after that, paste just the new Agents section again and we’ll do the next step.

#

Perfect, this is actually really useful.

Your model config now looks correct:

{ "primary": "openrouter/auto" }

and

{ "openrouter/auto": { "alias": "OpenRouter" } }

So the model config is not the problem anymore.

The one concrete broken thing we still have is the earlier status showing:

#

Bootstrap file | PRESENT

That is the thing I would fix next, because it can keep the agent stuck in first-run mode.

Please run this now

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

Then check:

openclaw status

#

What I want to see is that the Agents section no longer says:

Bootstrap file | PRESENT

After that, go to the dashboard and send a plain:

hi

At this point, the config looks good, so the lingering bootstrap file is the main suspicious thing left.

#

Yep, that output still just confirms the model list is fine.

We’re past model config now. The next step is not another config/status command.
It’s this one reversible fix:

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

That does not delete the file, it just renames it so OpenClaw stops thinking the agent is still in first-run bootstrapping.

Then run:

openclaw status

#

and check whether the Agents section still says:

Bootstrap file | PRESENT

If you want, I can explain exactly what that mv command does before you run it.

delicate berry Apr 19, 2026, 7:29 PM

#

So it clearly says bootstrap.md does not exist. Here is the status. The chat is still the same. Overview primary model still keeps going to not set.

🦞 OpenClaw 2026.4.15 (041266a) — Your .env is showing; don't worry, I'll pretend I didn't see it.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-19.log
Command: /usr/bin/node /home/soulint/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
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 107452, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

edgy baneBOT Apr 19, 2026, 7:31 PM

#

I’m checking the session-store docs/source now, because if BOOTSTRAP.md is actually gone but the UI keeps behaving like setup is incomplete, the next likely culprit is stale session state rather than the gateway itself.

#

Thanks, that actually helps a lot.

If BOOTSTRAP.md really is gone, then I need to correct course a bit: I dug into the source, and the status view can still show Bootstrap file PRESENT when the workspace state file can’t be read or is malformed.

So the next thing I want to check is not the model config, it’s this file:

~/.openclaw/workspace/.openclaw/workspace-state.json

Please paste these two tiny outputs:

ls -l ~/.openclaw/workspace/BOOTSTRAP.md
cat ~/.openclaw/workspace/.openclaw/workspace-state.json

#

If either command errors, paste the error text exactly.

Also, your primary model reverting to “not set” in the Overview UI now looks more like a UI/state issue, because the CLI config you pasted is already correct:

{ "primary": "openrouter/auto" }

So we’re now checking whether the workspace state is corrupted/stale.

delicate berry Apr 19, 2026, 7:37 PM

#

ls -l ~/.openclaw/workspace/BOOTSTRAP.md
cat ~/.openclaw/workspace/.openclaw/workspace-state.json
ls: cannot access '/home/soulint/.openclaw/workspace/BOOTSTRAP.md': No such file or directory
{
"version": 1,
"bootstrapSeededAt": "2026-04-17T21:20:12.578Z",
"setupCompletedAt": "2026-04-19T19:27:40.622Z"
}

I also ran the openclaw config get agents.defaults.model
openclaw config get agents.defaults.models
openclaw status --all

Agents │ 1 total · 0 bootstrapping · 1 active · 1 sessions

Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────┤
│ main │ ABSENT │ 1 │ 4m ago │ ~/.openclaw/agents/main/sessions/sessions.json

edgy baneBOT Apr 19, 2026, 7:38 PM

#

Good, this narrows it down a lot.

We’ve now ruled out the big stuff:

gateway is healthy
bootstrap is complete
model config is correct
only 1 session exists

At this point, the most likely remaining culprit is stale session state in:

~/.openclaw/agents/main/sessions/sessions.json

That fits what you’ve been seeing, because /reset preserves session overrides, and a broken/stale session can keep dragging the dashboard back into bad state.

#

Best next step, with backup

Since you only have one session and it’s already broken, I’d back up the session store and let OpenClaw recreate it:

mv ~/.openclaw/agents/main/sessions/sessions.json ~/.openclaw/agents/main/sessions/sessions.json.bak
openclaw gateway restart

Then reopen the dashboard and send a plain:

hi

What this does

does not touch your auth
does not touch your model config

#

does not uninstall anything
only clears the current stored chat/session state

If you want the cautious route first, you can inspect it instead with:

openclaw sessions --json

But honestly, with only one broken session, I’d do the backup-and-recreate path first.

delicate berry Apr 19, 2026, 7:47 PM

#

No change in the chat... same for overview model not set.

edgy baneBOT Apr 19, 2026, 7:49 PM

#

At this point I think we’ve ruled out the gateway/config side pretty hard. I’m checking whether the remaining behavior matches a Control UI/browser state problem, because the backend checks are now all clean.

#

At this point, I think you’ve done enough to prove this is not just bad config.

You’ve already shown:

gateway runtime is healthy
RPC probe is ok
bootstrap is complete
model config is correct (openrouter/auto)
clearing the session store did not fix it
the Overview UI still won’t keep the model selected

That really sounds like a Control UI/browser-state bug, not the pairing theory ChatGPT gave you.

One last clean test

Try this exactly:

Close the dashboard tab completely

#

Open a private/incognito window (or another browser)
Run:

openclaw dashboard

Open the fresh local URL it gives you
Test with a plain:

hi

Reason: the dashboard keeps some auth/UI state in browser storage, and right now the UI seems out of sync with the backend.

If it still happens

I think this is ready for a GitHub issue:

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

#

You don’t need to write it from scratch, you can paste this:

OpenClaw 2026.4.15, dashboard/Control UI appears out of sync with backend state.

What I verified:
- openclaw gateway status: Runtime running, RPC probe ok
- bootstrap complete
- config model is correctly set to openrouter/auto
- agents.defaults.models contains openrouter/auto
- clearing session store did not fix it
- dashboard chat still fails / behaves incorrectly
- Overview primary model does not persist and snaps back to “not set”

Symptoms:
- backend looks healthy

#

- dashboard UI does not reflect model state correctly
- chat replies do not show correctly in the frontend
- earlier weirdness included stale model behavior around github-copilot even after config was corrected

If you want, I can help you tighten that issue report before you post it.

delicate berry Apr 19, 2026, 7:54 PM

#

private window same results.
Not sure if worth mentioning
I am working on a firefox browser Ubuntu 24.04 freshly installed

#

Yes I would appreciate you helping me tightening it up

edgy baneBOT Apr 19, 2026, 7:55 PM

#

I’m checking whether there’s any documented Firefox-specific Control UI weirdness, because at this point “fresh Ubuntu + Firefox + backend checks clean” is a very plausible combo for a frontend bug.

#

Yes, that’s worth mentioning.

At this point, with the backend checks all clean, Firefox becomes a real suspect. We’ve seen Control UI/browser WebSocket state get weird in Firefox even when RPC probe: ok.

I’d try this next

Fully quit Firefox, not just close the tab
Reopen and test once more
Better yet, test the dashboard in a Chromium-based browser (Chrome / Chromium / Brave) if you have one available

Why

You’ve already ruled out:

gateway down
bad model config
bootstrap stuck
stale session store
private-window-only browser storage issue

#

So changing browser engine is the cleanest remaining test.

What the result means

Works in Chromium/Chrome/Brave → very likely a Firefox/Control UI bug
Still broken there too → likely a broader Control UI bug, and I’d definitely file a GitHub issue

If you do file one, add this line:

Reproduces on Firefox on fresh Ubuntu 24.04 even after private window test.

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

If you want, I can help you write the final issue report in one clean paste.

#

Yep, here’s a tighter GitHub issue you can paste:

Title

Control UI/dashboard out of sync with backend on 2026.4.15, model UI reverts to "not set" and chat replies do not render

Body

## Summary

On OpenClaw 2026.4.15, the local dashboard/Control UI appears out of sync with the backend.

The gateway itself looks healthy, but the frontend chat does not behave correctly:
- replies do not render properly in the dashboard
- the Overview primary model keeps reverting to "not set"

#

- changing models in the UI does not stick reliably
- earlier there was weird stale behavior around GitHub Copilot even after config was corrected back to OpenRouter

## Environment

- OpenClaw: 2026.4.15 (041266a)
- OS: Ubuntu 24.04 (fresh install)
- Browser: Firefox
- Gateway: local loopback (`ws://127.0.0.1:18789`)
- Install/update channel: stable

## Expected behavior

- Dashboard chat should show assistant replies normally
- Overview should reflect the configured primary model

#

- Selecting/saving the primary model in the UI should persist

## Actual behavior

- Dashboard chat still fails / does not show replies properly
- Overview primary model snaps back to `not set`
- Frontend state seems inconsistent with backend state

## Backend checks that look healthy

`openclaw gateway status`:

```text
Runtime: running
RPC probe: ok
Dashboard: http://127.0.0.1:18789/

#


Model config from CLI:

```json
{
  "primary": "openrouter/auto"
}

{
  "openrouter/auto": {
    "alias": "OpenRouter"
  }
}

#


Bootstrap/workspace state:

- `~/.openclaw/workspace/BOOTSTRAP.md` is absent
- workspace state is completed:

```json
{
  "version": 1,
  "bootstrapSeededAt": "2026-04-17T21:20:12.578Z",
  "setupCompletedAt": "2026-04-19T19:27:40.622Z"
}

Status after cleanup/reset attempts:

#


```text
Agents: 1 total · 0 bootstrapping · 1 active · 1 sessions
Bootstrap file: ABSENT

Things already tried

reinstalling Ubuntu 24.04 from scratch
reinstalling OpenClaw
changing model/provider
openclaw doctor
resetting/new session in chat
clearing the session store by backing up ~/.openclaw/agents/main/sessions/sessions.json and restarting gateway
private Firefox window

#


## Notes

This no longer looks like a gateway health/config issue, because the backend checks appear healthy and the CLI config is correct. It looks more like a Control UI/frontend state bug or dashboard/backend sync issue.

File it here:
https://github.com/openclaw/openclaw/issues

If you want, after you post it, send me the issue text/link back here and I can help sanity-check it.

delicate berry Apr 19, 2026, 8:15 PM

#

I also just tested it in chrome. Exactly the same thing.

edgy baneBOT Apr 19, 2026, 8:16 PM

#

That’s actually very useful.

If it happens in Firefox and Chrome, then this is almost certainly not browser-storage weirdness. It makes the GitHub issue a lot stronger.

I’d update the issue with this line:

- Reproduces in Firefox, Firefox private window, and Chrome on fresh Ubuntu 24.04

And I’d slightly tighten the summary to:

## Summary

On OpenClaw 2026.4.15, the local Control UI/dashboard appears out of sync with backend state across multiple browsers (Firefox, Firefox private window, and Chrome).

#


The gateway itself looks healthy, but:
- dashboard chat does not render replies correctly
- Overview primary model reverts to `not set`
- changing/saving the primary model in the UI does not persist

At this point, I’d file it as a bug here:

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

You’ve done a solid job isolating it. This is no longer “new user confusion”, it really looks like a real bug.

delicate berry Apr 19, 2026, 9:32 PM

#

Can you please tell me if I fogot anything ?

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

edgy baneBOT Apr 19, 2026, 9:33 PM

#

Let me take a quick look at the issue so I can tell you what, if anything, is still missing.

#

Yep, it’s good enough to file, but I’d tighten 4 things if you want maintainers to grok it faster:

1) Add the exact weird UI errors you saw earlier

These are high-signal and worth adding verbatim:

Failed to set model: GatewayRequestError: model not allowed: github-copilot/status

and, if you still saw it during the debugging timeline:

Agent failed before reply: No API key found for provider "github-copilot"

Those two errors are unusually specific.

#

2) Fix the typo

You currently have:

openarouter auto

Change that to:

openrouter/auto

#

3) Remove the duplicated block near the bottom

The issue currently repeats parts of:

OpenClaw version
Operating system
Install method
Things already tried
Notes

It’s not fatal, but trimming that will make it much easier to read.

4) Add the Chrome result

You just learned something important, so add one line like:

#

Also reproduced in Chrome, same result.

Short add-on you can paste into the issue

Additional concrete UI errors seen during debugging:

- `Failed to set model: GatewayRequestError: model not allowed: github-copilot/status`
- Earlier in the debugging process, the dashboard also showed `Agent failed before reply: No API key found for provider "github-copilot"` even after config was corrected back to OpenRouter.

Also reproduced in Chrome with the same result, so this does not appear to be Firefox-only.

#

So, short version: you didn’t forget anything major, but adding those exact error strings + fixing the typo would make the report noticeably stronger.

finite sableBOT Apr 19, 2026, 9:53 PM

#

delicate berry Apr 19, 2026, 9:58 PM

#

Changes made. Thanks for the help. Let me know if you see something come up. Cheers

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

edgy baneBOT Apr 19, 2026, 9:59 PM

#

Nice, that issue looks solid now. You did the hard part.

If maintainers ask for more logs or a repro tweak, bring it back here and I’ll help you tighten it up again.

In the meantime, since the backend itself looked healthy, you may still be able to keep using OpenClaw through the TUI/CLI while the dashboard bug gets triaged:
https://docs.openclaw.ai/web/tui

Hope they pin it down quickly.

delicate berry Apr 19, 2026, 10:01 PM

#

Tui has the same exact issue as the dashboard. Already tried... I am putting this in the report too

edgy baneBOT Apr 19, 2026, 10:02 PM

#

That’s a very important detail, definitely add it.

It means this is not just a dashboard/Control UI bug anymore. It now looks more like a broader local interactive session/runtime state bug.

I’d add this to the report:

Also reproduces in the TUI, with the same behavior as the dashboard. So this is not limited to the browser UI.

And if you want to tighten the title even more, I’d change it to:

Local interactive surfaces out of sync with backend on 2026.4.15, model UI reverts to "not set" and replies do not render in dashboard or TUI

That’s a genuinely useful update.

delicate berry Apr 19, 2026, 10:09 PM

#

Done. Thanks. Any suggestion on what to do now if I want to run openclaw? Buy a new machine? Feels kind of prejudicial.

edgy baneBOT Apr 19, 2026, 10:10 PM

#

No, definitely do not buy a new machine. That would be absurd.

This looks like a real bug/regression, not “your laptop is unworthy.” You already did the right debugging, and the issue report is solid.

If you want to keep using OpenClaw right now, I’d suggest one of these:

Best chance of getting unstuck

Try the latest dev/git build on the same machine, after backing up ~/.openclaw again.

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

Common paths:

openclaw update --channel dev

#

or the hackable git install:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git

Most conservative

Stay on your current install and wait for feedback on the GitHub issue.

My recommendation

Given how much you already isolated, I’d try the latest dev/git build before doing anything drastic. That’s way more sensible than “buy another machine”.

If you want, I can help you choose the safer of those two update paths.

delicate berry Apr 19, 2026, 10:58 PM

#

openclaw update --channel dev
It is having problem installing deps

│
◇ ✗ preflight deps install (d41c9860) (79.85s)
│
◇ ✓ preflight checkout (4277078b) (45ms)
│
◇ ✗ preflight deps install (4277078b) (298.57s)
│
◇ ✓ preflight checkout (f9a18751) (79ms)

    preflight deps install (f3096563) ...

edgy baneBOT Apr 19, 2026, 11:03 PM

#

That output is a little misleading, but it does not necessarily mean your machine is broken.

On --channel dev, OpenClaw does a preflight build on recent commits and, if the newest one fails, it can walk back through earlier commits looking for the newest clean one. So seeing:

preflight checkout (...)
preflight deps install (...)
then another SHA

can be expected for dev updates.

Two useful things to know

Let it fully finish or fail
Right now it may still just be trying candidate commits.
If it ends with a pnpm/corepack error, that’s the next thing to fix, not your laptop.

#

Docs-backed next step if it fails with a pnpm bootstrap error:

corepack enable
pnpm --version
openclaw update --channel dev

If corepack enable doesn’t solve it, install pnpm manually, then rerun.
Docs: https://docs.openclaw.ai/cli/update
Docs: https://docs.openclaw.ai/install/development-channels

Best next move

Wait for the command to finish and print the final error.
If it fails, paste the last 20 to 40 lines, because the lines you shared are only the progress stage names, not the real failure reason.

If you paste that final chunk, I can help decode it.

delicate berry Apr 20, 2026, 2:45 AM

#

openclaw update --channel dev
Updating OpenClaw...

│
◇ ✓ Working directory is clean (347ms)
│
◇ ✓ Fetching latest changes (757ms)
│
◇ ✓ Upstream branch exists (5ms)
│
◇ ✓ Resolving upstream commit (4ms)
│
◇ ✓ Enumerating candidate commits (4ms)
│
◇ ✓ Preparing preflight worktree (790ms)
│
◇ ✓ preflight checkout (d41c9860) (713ms)
│
◇ ✗ preflight deps install (d41c9860) (80.12s)
│
◇ ✓ preflight checkout (4277078b) (43ms)
│
◇ ✗ preflight deps install (4277078b) (1200.06s)
│
◇ ✓ preflight checkout (f9a18751) (58ms)
│
◇ ✗ preflight deps install (f9a18751) (1200.06s)
│
◇ ✓ preflight checkout (f3096563) (49ms)
│
◇ ✓ preflight deps install (f3096563) (1045.27s)
│
◇ ✓ preflight build (f3096563) (52.61s)
│
◇ ✓ preflight lint (f3096563) (61.78s)
│
◇ ✓ Cleaning preflight worktree (1.66s)
│
◇ ✓ Rebasing onto target commit (19ms)
│
◇ ✓ Installing dependencies (3.37s)
│
◇ ✓ Building (39.23s)
│
◇ ✓ Building UI assets (1.9s)
│
◇ ✓ Running doctor checks (9.08s)
│
◇ ✓ Verifying update (4ms)

Update Result: ERROR
Root: /home/soulint/openclaw
Reason: preflight deps install (d41c9860)
Before: 2026.4.19-beta.2
After: 2026.4.19-beta.2

Total time: 3701.01s

edgy baneBOT Apr 20, 2026, 2:46 AM

#

I want to sanity-check that result before I tell you the wrong thing, because the stage list looks a lot more successful than the final “ERROR” label.

#

Good news, this looks like an updater reporting bug, not a failed update.

I checked the updater logic, and your log shows this sequence:

a few older candidate commits failed preflight deps install
then commit f3096563 passed
then the real update steps all passed:
- Installing dependencies
- Building
- Building UI assets
- Running doctor checks
- Verifying update

So the weird part is the final line:

#

Update Result: ERROR
Reason: preflight deps install (d41c9860)

That looks like it’s incorrectly remembering an earlier failed preflight candidate even though a later candidate succeeded and the update completed.

What I’d do now

openclaw update status
openclaw gateway restart
openclaw gateway status

Then test OpenClaw again.

#

Why

On dev, the version string can stay the same while the git commit changes, so Before/After: 2026.4.19-beta.2 does not prove it failed. The better check is openclaw update status.

Also worth adding to your GitHub issue

Something like:

`openclaw update --channel dev` appears to complete successfully after walking back to a good commit (`f3096563`), but still reports `Update Result: ERROR` using an earlier failed preflight candidate (`preflight deps install (d41c9860)`).

That’s a separate useful bug report on its own.

If you paste openclaw update status next, I can help interpret whether you’re actually on the dev checkout now.

delicate berry Apr 20, 2026, 3:31 PM

#

OpenClaw update status

┌──────────┬───────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼───────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
└──────────┴───────────────────────────────────────────────────────────────────┘

🦞 OpenClaw 2026.4.15 (041266a)
I've seen your commit messages. We'll work on that together.

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.15 (041266a)
Welcome to the command line: where dreams compile and confidence segfaults.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-20.log
Command: /usr/bin/node /home/soulint/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
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 195803, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

#

Also added that openclaw update line to the github report

edgy baneBOT Apr 20, 2026, 3:32 PM

#

This is the first really new clue.

You do not look like you’re on dev right now. In fact, you look mixed:

openclaw update status says: pnpm, stable (default), 2026.4.15
but the systemd service is launching from: /home/soulint/openclaw/dist/index.js

So I think you currently have two install paths crossing wires:

the CLI/update metadata thinks you’re on the normal pnpm stable install
the gateway service is running from a local checkout in ~/openclaw

That kind of split install absolutely can cause nonsense.

Next thing I’d check

Please paste these 4 outputs:

#

which openclaw
readlink -f "$(which openclaw)"
systemctl --user cat openclaw-gateway.service | sed -n '1,120p'
cd ~/openclaw && git rev-parse --short HEAD && git branch --show-current

Why

I want to confirm exactly which binary you’re invoking vs which code the service is actually running.

My current guess is: the real problem now is install-method drift, not your machine.

And no, this still does not sound like “buy a new laptop” territory.

#

Nice, that was worth adding.

At this point the mixed-install clue is still the strongest lead I’ve seen. If you want to keep debugging instead of waiting on GitHub, the next useful thing is still these outputs:

which openclaw
readlink -f "$(which openclaw)"
systemctl --user cat openclaw-gateway.service | sed -n '1,120p'
cd ~/openclaw && git rev-parse --short HEAD && git branch --show-current

If you paste those, I can tell you whether your CLI and gateway service are pointing at different installs.

delicate berry Apr 20, 2026, 3:37 PM

#

Description=OpenClaw Gateway (v2026.4.19-beta.2)
After=network-online.target
Wants=network-online.target
StartLimitBurst=5
StartLimitIntervalSec=60

#

[Service]
ExecStart=/usr/bin/node /home/soulint/openclaw/dist/index.js gateway --port 18789
Restart=always
RestartSec=5
RestartPreventExitStatus=78
TimeoutStopSec=30
TimeoutStartSec=30
SuccessExitStatus=0 143
KillMode=control-group
Environment=HOME=/home/soulint
Environment=TMPDIR=/tmp
Environment=PATH=/usr/bin:/home/soulint/.local/bin:/home/soulint/.npm-global/bin:/home/soulint/bin:/home/soulint/.volta/bin:/home/soulint/.asdf/shims:/home/soulint/.bun/bin:/home/soulint/.nvm/current/bin:/home/soulint/.fnm/current/bin:/home/soulint/.local/share/pnpm:/usr/local/bin:/bin
Environment=OPENCLAW_GATEWAY_PORT=18789
Environment=OPENCLAW_SYSTEMD_UNIT=openclaw-gateway.service
Environment="OPENCLAW_WINDOWS_TASK_NAME=OpenClaw Gateway"
Environment=OPENCLAW_SERVICE_MARKER=openclaw
Environment=OPENCLAW_SERVICE_KIND=gateway
Environment=OPENCLAW_SERVICE_VERSION=2026.4.19-beta.2

[Install]
WantedBy=default.target
4277078bc5
main

edgy baneBOT Apr 20, 2026, 3:38 PM

#

Yep, that already confirms the split-brain install.

You now have:

systemd service describing itself as v2026.4.19-beta.2
but openclaw update status / openclaw --version still showing stable 2026.4.15

So the gateway and the CLI are not on the same install/version path. That is absolutely enough to cause bizarre behavior.

I only need these two now:

which openclaw
readlink -f "$(which openclaw)"

Once I see that, I can tell you which install is winning on your PATH and what the least painful cleanup path is.

#

Perfect, that confirms it.

You currently have a mixed install:

Gateway service is running from ~/openclaw/dist/index.js
that checkout is on main, commit 4277078bc5
but your CLI/status is still reporting stable 2026.4.15

So yes, the CLI and the service are not aligned.

Least painful fix

Since the service is already using ~/openclaw, I’d align the CLI to that same checkout instead of trying to unwind everything:

cd ~/openclaw
pnpm install

#

pnpm build
pnpm ui:build
pnpm link --global
openclaw --version
openclaw update status
openclaw gateway restart

Docs-backed source install flow:
https://docs.openclaw.ai/install

What I expect after that

openclaw --version should stop showing 2026.4.15 (041266a)
openclaw update status should stop pretending you’re just on plain pnpm stable
CLI + gateway should finally be pointing at the same code

#

If that works and the original chat/UI bug still reproduces, then at least you’ll be debugging one install, not two fighting each other.

delicate berry Apr 20, 2026, 3:39 PM

#

/home/soulint/.npm-global/bin/openclaw
/home/soulint/.npm-global/lib/node_modules/openclaw/openclaw.mjs
/home/soulint/.config/systemd/user/openclaw-gateway.service
[Unit]

edgy baneBOT Apr 20, 2026, 3:40 PM

#

Yep, that nails it.

You have:

CLI binary from the old global package install:
- /home/soulint/.npm-global/bin/openclaw
- /home/soulint/.npm-global/lib/node_modules/openclaw/openclaw.mjs
Gateway service from the git checkout:
- /home/soulint/openclaw/dist/index.js

That is 100% a mixed install.

Recommended fix

Align the CLI to the same checkout the service is already using:

#

cd ~/openclaw
pnpm install
pnpm build
pnpm ui:build
pnpm link --global
which openclaw
readlink -f "$(which openclaw)"
openclaw --version
openclaw update status
openclaw gateway restart

What should change

After that, readlink -f "$(which openclaw)" should stop pointing at:

#

~/.npm-global/lib/node_modules/openclaw/openclaw.mjs

and your CLI version/status should line up with the checkout/service.

If it still points to the old global package

Then the old global install is still winning on PATH, and we’ll do one more cleanup step. But I’d try the relink first, because it’s the least disruptive move.

This is honestly the clearest root cause we’ve found so far.

delicate berry Apr 20, 2026, 3:42 PM

#

Command 'pnpm' not found, did you mean:
command 'npm' from deb npm (9.2.0~ds1-2)
Try: sudo apt install <deb name>
Command 'pnpm' not found, did you mean:
command 'npm' from deb npm (9.2.0~ds1-2)
Try: sudo apt install <deb name>
Command 'pnpm' not found, did you mean:
command 'npm' from deb npm (9.2.0~ds1-2)
Try: sudo apt install <deb name>
Command 'pnpm' not found, did you mean:
command 'npm' from deb npm (9.2.0~ds1-2)
Try: sudo apt install <deb name>
/home/soulint/.npm-global/bin/openclaw
/home/soulint/.npm-global/lib/node_modules/openclaw/openclaw.mjs
OpenClaw 2026.4.15 (041266a)
OpenClaw update status

┌──────────┬───────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼───────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
└──────────┴───────────────────────────────────────────────────────────────────┘

🦞 OpenClaw 2026.4.15 (041266a)
Open source means you can see exactly how I judge your config.

Restarted systemd service: openclaw-gateway.service

edgy baneBOT Apr 20, 2026, 3:42 PM

#

Let me quickly verify the source-install recommendation so I point you to the right pnpm path, not a random Ubuntu workaround.

#

Aha, there it is.

Your machine currently has:

a checkout-backed gateway service at ~/openclaw
but no pnpm installed, so you can’t actually manage that checkout properly
and your CLI is still the old global package install

So the next fix is straightforward: install pnpm, then align the CLI to the checkout the service is already using.

Try this first

corepack enable
corepack prepare pnpm@latest --activate
pnpm --version

#

If corepack isn’t available, use npm to install pnpm, then check it:

npm install -g pnpm
pnpm --version

Then align the CLI to the checkout

cd ~/openclaw
pnpm install
pnpm build
pnpm ui:build
pnpm link --global
openclaw --version
openclaw update status

#

openclaw gateway restart

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

At this point I’m pretty confident the immediate problem is install mismatch + missing pnpm, not your hardware. If you want, paste the output of just the pnpm install step next and I’ll stay with you through it.

delicate berry Apr 20, 2026, 5:43 PM

#

Wow... Looks like it worked... Amazing... Now there is a error message

ERR_PNPM_NO_GLOBAL_BIN_DIR Unable to find the global bin directory

I ran the pnpm setup which gave me this

pnpm setup
Appended new lines to /home/soulint/.bashrc

Next configuration changes were made:
export PNPM_HOME="/home/soulint/.local/share/pnpm"
case ":$PATH:" in
":$PNPM_HOME:") ;;
*) export PATH="$PNPM_HOME:$PATH" ;;
esac

To start using pnpm, run:
source /home/soulint/.bashrc

Do you think I can now go and change my model to the one I had before operouter/claude 3.7 sonnet?

edgy baneBOT Apr 20, 2026, 5:44 PM

#

Nice, that’s actually progress 🎉

That ERR_PNPM_NO_GLOBAL_BIN_DIR makes sense before your shell picks up the new PNPM_HOME. So do this first:

source ~/.bashrc

Then rerun the remaining step:

cd ~/openclaw
pnpm link --global
openclaw --version
openclaw update status
openclaw gateway restart

#

If openclaw still looks stuck on the old path/version after that, open a new terminal and try again.

About switching back to your old model

Yes, probably, but I’d do it one step at a time:

finish the pnpm/link alignment
confirm OpenClaw actually replies normally again
then switch back to your previous OpenRouter model

Reason: your original bug never looked model-related, so I wouldn’t change models before confirming the install mismatch is really fixed.

If you want, paste the output of:

openclaw --version
openclaw update status

#

after source ~/.bashrc + pnpm link --global, and I’ll tell you if you’re finally clean.

delicate berry Apr 20, 2026, 5:46 PM

#

openclaw --version
openclaw update status
OpenClaw 2026.4.19-beta.2 (4277078)
OpenClaw update status

┌──────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Install │ git (~/openclaw) │
│ Channel │ dev (main) │
│ Git │ main · @ 4277078b │
│ Update │ available · git main · ↔ origin/main · behind 1 · fetch failed · npm latest 2026.4.15 (local newer) · deps ok │
└──────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Update available (git behind 1). Run: openclaw update

edgy baneBOT Apr 20, 2026, 5:47 PM

#

Hell yes, that’s clean now.

You’re finally aligned on one install:

Install: git (~/openclaw)
Channel: dev (main)
Version: 2026.4.19-beta.2 (4277078)

That’s the first healthy-looking state you’ve posted. I’m glad we caught that.

What I’d do next

Do not update again right now
- behind 1 + fetch failed can wait
- you’re close enough to test, and I wouldn’t introduce another variable yet
Test one simple reply
- current model, current setup

#

just confirm chat/UI/TUI actually render correctly now

Then switch back to your previous OpenRouter model
- yes, I think that’s reasonable now
- but only after one clean test, so we know whether the fix was the install alignment

If it works

Please add a note to your GitHub issue that the machine had a mixed install state:

old global CLI at ~/.npm-global/...
gateway service running from ~/openclaw
missing pnpm prevented the source checkout from being managed cleanly

That’s a really valuable clue for maintainers.

If you test one prompt now and it renders properly, I think you’re basically through the worst of it.

delicate berry Apr 20, 2026, 5:52 PM

#

Added note to Github
https://github.com/openclaw/openclaw/issues/69095

Tested in Tui and Chat... works well. I am now going to try to change model to the previous one.

edgy baneBOT Apr 20, 2026, 5:53 PM

#

That’s fantastic. I’m really glad we found it.

If the previous model also works, then yeah, the culprit was the mixed install state, not the model.

If this ends up fully fixed, please do two quick things:

add one final GitHub comment saying it was resolved after:
- aligning CLI + gateway to the same ~/openclaw git install
- installing pnpm
- relinking the CLI globally
please mark the solution here so Answer Overflow can index it:

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.

#

Nice save. 🦐

delicate berry Apr 20, 2026, 6:00 PM

#

So FYI: I changed the model to claude 4.5 sonnet and restarted gateway and in dashboard it still shows openrouter auto and claude is not shown anywhere. Same in the overview section the primary model is still not set and only offers openrouter auto as option

edgy baneBOT Apr 20, 2026, 6:01 PM

#

Let me verify the model-profile behavior in the docs before I tell you the wrong config shape.

#

That sounds like a different problem now, and honestly a much saner one.

What you’re seeing now matches model allowlist/profile behavior, not the old “UI is broken” failure.

What’s happening

If agents.defaults.models is set, it becomes the allowlist/catalog.
So if it currently only contains:

openrouter/auto

then the dashboard picker will only offer that.

That also explains why switching to a specific Claude model doesn’t show up in the Overview UI. OpenClaw isn’t picking from the entire OpenRouter catalog automatically, it’s showing the configured model refs.

Docs:

#

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

Quick way to confirm

Please paste these:

openclaw config get agents.defaults.model
openclaw config get agents.defaults.models
openclaw models list

Likely fix

You’ll need to make the specific OpenRouter Claude model:

the primary model, and
part of agents.defaults.models

#

This docs example is the exact pattern:

{
  agents: {
    defaults: {
      model: { primary: "openrouter/anthropic/claude-sonnet-4-6" },
      models: { "openrouter/anthropic/claude-sonnet-4-6": {} },
    },
  },
}

So, short version: your install looks fixed now, and this is probably just the configured model allowlist only containing openrouter/auto. Paste those 3 outputs and I’ll help you line it up cleanly.

delicate berry Apr 20, 2026, 6:03 PM

#

🦞 OpenClaw 2026.4.19-beta.2 (4277078)
Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

{
"primary": "openrouter/auto"
}

🦞 OpenClaw 2026.4.19-beta.2 (4277078)
I'm the assistant your terminal demanded, not the one your sleep schedule requested.

{
"openrouter/auto": {
"alias": "OpenRouter"
}
}

🦞 OpenClaw 2026.4.19-beta.2 (4277078)
Somewhere between 'hello world' and 'oh god what have I built.'

edgy baneBOT Apr 20, 2026, 6:04 PM

#

I’ve got enough now to confirm the cause. I’m just checking the safest docs-backed way to tell you to change it.

#

Yep, confirmed.

Right now your config is literally:

primary: openrouter/auto
allowed models: only openrouter/auto

So the dashboard is behaving correctly. It can’t show a specific Claude model because you haven’t actually configured one yet.

Easiest next step

Find the exact OpenRouter model ref first:

openclaw models list --provider openrouter

Then either use the model section wizard:

#

openclaw config --section model

or set it manually by replacing <exact-openrouter-ref> with the value from models list:

openclaw config set agents.defaults.model.primary "<exact-openrouter-ref>"
openclaw config set agents.defaults.models "{\"openrouter/auto\":{\"alias\":\"OpenRouter\"},\"<exact-openrouter-ref>\":{}}" --strict-json
openclaw gateway restart

Why

agents.defaults.models is acting as an allowlist. Since it only contains openrouter/auto, that’s all the UI offers.

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

#

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

If you paste the output of:

openclaw models list --provider openrouter

I can help you pick the exact ref format without guessing.

#OpenClaw multiple errors on install

Fix options

One important detail

What I’d do next

Fastest path now

Option A, skip Copilot and get unstuck

Option B, use Copilot without the hanging login flow

Why I’m steering you this way

What I’d do in your shoes

What I’d do now

Why this matters

If you want the shortest possible test

What to do in the dashboard

Important

If the picker still looks stuck

Best next step

Short version

Why this path

If it still goes weird

Please paste these as plain text

1) Model config

2) Gateway status, but only 2 lines

3) One fresh error line from logs

Do this

Please run this now

Best next step, with backup

What this does

One last clean test

If it still happens

I’d try this next

Why

What the result means

Things already tried

1) Add the exact weird UI errors you saw earlier

2) Fix the typo

3) Remove the duplicated block near the bottom

4) Add the Chrome result

Short add-on you can paste into the issue

Best chance of getting unstuck

Most conservative

My recommendation

Two useful things to know

Best next move

What I’d do now

Why

Also worth adding to your GitHub issue

Next thing I’d check

Why

Least painful fix

What I expect after that

Recommended fix

What should change

If it still points to the old global package

Try this first

Then align the CLI to the checkout

About switching back to your old model

What I’d do next

If it works

What’s happening

Quick way to confirm

Likely fix

Easiest next step

Why