#Shit keep hanging and ghosting me.

1 messages · Page 1 of 1 (latest)

barren crown
#

this thing keeps hanging me. errors suggest gateway just killes itself not even 5 seconds after activating. is this a new update bug? it was fine before

lime heronBOT
#

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

barren crown
#

newver have i ever in my life seen so many diferent alterations of the openclaw banner

young pollen
#

disable the bonjour plugin from the command line

#

see if that get you back up and running, worked for me and others this morning.

barren crown
#

well i managed to get a half fix

#

its still not working

velvet orioleBOT
#

nice, progress at least 🦐

If the half-fix was disabling Bonjour, that’s a legit workaround:

openclaw plugins disable bonjour
openclaw gateway restart

That only disables LAN auto-discovery/mDNS — it shouldn’t break the gateway itself.

For the remaining half, paste:

openclaw --version
openclaw gateway status
#

okay, then don’t keep chasing Bonjour — if the gateway still exits after a few seconds, we need the actual crash line.

Please paste this output:

openclaw --version
which openclaw
openclaw gateway status --deep
openclaw config get meta.lastTouchedVersion
openclaw status --all

Then start it and catch the crash log:

openclaw logs --follow
#

If openclaw logs can’t connect because the gateway dies too fast, use:

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

This could be a split install / service using an older openclaw than your shell, especially after an update. The which openclaw + meta.lastTouchedVersion bits will tell us that.

Docs: https://docs.openclaw.ai/gateway/troubleshooting

barren crown
#

last touched version command not found

velvet orioleBOT
#

That one is optional — don’t get stuck there.

The exact command was:

openclaw config get meta.lastTouchedVersion

If openclaw config itself says command not found, that’s a useful clue: your CLI is probably old / wrong binary. Run these and paste the output:

openclaw --version
which openclaw
openclaw config --help
openclaw gateway status --deep
barren crown
#

test@test-VirtualBox:~$ openclaw gateway status --deep

🦞 OpenClaw 2026.4.24 (cbcfdf6)
I keep secrets like a vault... unless you print them in debug logs again.



Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/test/.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 5373, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
test@test-VirtualBox:~$ grep -n "lastTouchedVersion" ~/.openclaw/openclaw.json
4: "lastTouchedVersion": "2026.4.24"
test@test-VirtualBox:~$

#

test@test-VirtualBox:~$ openclaw --version
OpenClaw 2026.4.24 (cbcfdf6)
test@test-VirtualBox:~$ which openclaw
/home/test/.npm-global/bin/openclaw
test@test-VirtualBox:~$ openclaw config --help

🦞 OpenClaw 2026.4.24 (cbcfdf6)
I've read more man pages than any human should—so you don't have to.

Usage: openclaw config [options] [command]

Non-interactive config helpers (get/set/unset/file/schema/validate). Run without
subcommand for guided setup.

Options:
-h, --help Display help for command
--section <section> Configuration sections for guided setup (repeatable). Use
with no subcommand. (default: [])

Commands:
file Print the active config file path
get Get a config value by dot path
schema Print the JSON schema for openclaw.json
set Set config values by path (value mode, ref/provider
builder mode, or batch JSON mode).
Examples:
openclaw config set gateway.port 19001 --strict-json
openclaw config set channels.discord.token --ref-provider
default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set secrets.providers.vault
--provider-source file --provider-path
/etc/openclaw/secrets.json --provider-mode json
openclaw config set --batch-file ./config-set.batch.json
--dry-run
unset Remove a config value by dot path
validate Validate the current config against the schema without
starting the gateway

Docs: docs.openclaw.ai/cli/config

velvet orioleBOT
#

Good news: that output says the gateway is not dying now.

It’s running, reachable, and versions match:

  • OpenClaw: 2026.4.24
  • Runtime: running
  • Connectivity probe: ok
  • Listening only on 127.0.0.1:18789

So the current problem is probably one of these:

  1. You’re opening it from outside the VM — it’s bound to loopback inside VirtualBox, so your host/phone can’t reach it.
  2. Gateway is up but channels/agent replies are failing — different layer than gateway startup.

If you’re trying to use the dashboard from your host machine, either open it inside the VM:

#
http://127.0.0.1:18789/

or expose it deliberately, e.g.:

openclaw config set gateway.bind lan
openclaw gateway restart

Then make sure VirtualBox forwards/allows port 18789. Keep auth enabled when using lan.

If the dashboard opens but messages are ghosting, paste:

#
openclaw status --all
openclaw channels status --probe
openclaw logs --limit 200 --plain
#

Yep, CLI/install looks sane. The earlier lastTouchedVersion issue was just command/path weirdness — your config stamp matches 2026.4.24.

Next split is:

A) Dashboard from inside the VM:
Use:

http://127.0.0.1:18789/

B) Dashboard from your host machine / phone:
Loopback won’t work from outside VirtualBox. You’ll need gateway.bind lan + VirtualBox port forwarding/firewall.

C) Gateway is up but messages/agent are ghosting:
Paste these:

#
openclaw status --all
openclaw channels status --probe
openclaw logs --limit 200 --plain

Right now this does not look like the gateway is killing itself anymore — it’s running and probeable.

barren crown
#

Error: Agent "main" no longer exists in configuration

from the onboard openclaw control

hardy drift
#

wow it work openclaw plugins disable bonjour

barren crown
#

it didnt for me. i have edited the config json so maybe i did something wrong there

#

i tried unstalling or installing, and doctor but it all keeps hanging

velvet orioleBOT
#

Ahh, that’s the real issue.

Control is trying to talk to a stale session owned by agent:main, but your config currently doesn’t define an agent called main.

Run:

openclaw agents list --bindings
openclaw config get agents.list

If you did not intentionally set up multiple agents, easiest reset is:

openclaw config unset agents.list
openclaw gateway restart
#

That restores the implicit default main agent.

If you did intentionally create another agent, don’t unset it — instead start a new chat/session in Control for the configured agent, or clear the Control UI site data for 127.0.0.1:18789 so it stops reopening the old agent:main session.

Docs: https://docs.openclaw.ai/concepts/multi-agent

#

Nice — that confirms Bonjour/mDNS was the startup blocker for at least that setup.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person. 🦐

#

Very possible. The error points at agents.list: Control has an old agent:main... session, but your config may no longer define main.

First run the safe checks:

openclaw config validate
openclaw agents list --bindings
openclaw config get agents.list --json

If you’re not intentionally doing multi-agent, fix is usually:

openclaw config unset agents.list
openclaw gateway restart
#

That puts OpenClaw back to the default implicit main agent.

If you are doing multi-agent, make sure one entry is actually id: "main" or clear Control UI site data / start a new session for the agent that exists.

Don’t paste the whole config if it has tokens — just the agents.list output is enough. Docs: https://docs.openclaw.ai/concepts/multi-agent

#

Yeah, stop reinstalling for a sec — if the config is bad, reinstall/doctor can just keep tripping over the same state.

Do this in order:

openclaw backup create
timeout --foreground 20s openclaw config validate
timeout --foreground 20s openclaw agents list --bindings
timeout --foreground 20s openclaw config get agents.list --json

If agents.list exists and doesn’t include "id": "main", that explains the Control error. If you don’t need multi-agent:

openclaw config unset agents.list
openclaw gateway restart
#

If commands hang, grab service logs directly:

systemctl --user status openclaw-gateway --no-pager
journalctl --user -u openclaw-gateway -n 120 --no-pager
tail -n 200 /tmp/openclaw/openclaw-2026-04-27.log

Paste the config validate result and agents.list output — but don’t paste tokens/secrets.
Docs: https://docs.openclaw.ai/cli/config

barren crown
#

test@test-VirtualBox:~$ config validate
Command 'config' not found, did you mean:
command 'fconfig' from deb redboot-tools (0.7build4)
command 'vconfig' from deb vlan (2.0.5ubuntu5)
command 'iconfig' from deb ipmiutil (3.1.9-3)
command 'mconfig' from deb mono-devel (6.8.0.105+dfsg-3.5ubuntu1)
command 'cconfig' from deb xrootd-server (5.6.4-1)
command 'kconfig' from deb kconfig-frontends (4.11.0.1+dfsg-6)
command 'kconfig' from deb kconfig-frontends-nox (4.11.0.1+dfsg-6)
Try: sudo apt install <deb name>

velvet orioleBOT
#

Tiny typo in my shorthand — every one of those needs the openclaw prefix.

Run exactly:

openclaw config validate
openclaw agents list --bindings
openclaw config get agents.list --json

Not config validate by itself.

barren crown
#

test@test-VirtualBox:~$ openclaw agents list --bindings

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Gateway online—please keep hands, feet, and appendages inside the shell at all times.

12:15:36 [plugins] acpx staging bundled runtime deps (1 missing, 33 install specs): acpx@0.5.3
12:15:40 [plugins] acpx installed bundled runtime deps in 4089ms: acpx@0.5.3
12:15:44 [plugins] amazon-bedrock staging bundled runtime deps (3 missing, 33 install specs): @aws-sdk/client-bedrock-runtime@3.1034.0, @aws-sdk/client-bedrock@3.1034.0, @aws-sdk/credential-provider-node@3.972.34
12:15:48 [plugins] amazon-bedrock installed bundled runtime deps in 4010ms: @aws-sdk/client-bedrock-runtime@3.1034.0, @aws-sdk/client-bedrock@3.1034.0, @aws-sdk/credential-provider-node@3.972.34
12:15:52 [plugins] amazon-bedrock-mantle staging bundled runtime deps (3 missing, 33 install specs): @anthropic-ai/sdk@0.90.0, @aws/bedrock-token-generator@^1.1.0, @mariozechner/pi-ai@0.70.2... [[[[Different plugin installations]]]]]Agents:

  • research-assistant (default) (Research Assistant)
    Workspace: ~/.openclaw/workspace
    Agent dir: ~/.openclaw/agents/research-assistant/agent
    Model: openrouter/google/gemini-3-flash-preview
    Routing rules: 0
    Routing: default (no explicit rules)
    Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
    Channel status reflects local config/creds. For live health: openclaw channels status --probe.
    test@test-VirtualBox:~$ openclaw config get agents.list --json
    [
    {
    "id": "research-assistant",
    "name": "Research Assistant",
    "workspace": "/home/test/.openclaw/workspace",
    "model": "openrouter/google/gemini-3-flash-preview"
    }
    ]
    test@test-VirtualBox:~$
velvet orioleBOT
#

Yep, we found the config problem:

Your only configured agent is:

research-assistant

…but Control is trying to reopen an old session for:

main

Pick one fix:

Option A — keep research-assistant: clear Control UI site data for 127.0.0.1:18789, then open Control again and start a new chat.

#

Option B — make it compatible with old main sessions: run:

openclaw backup create

openclaw config set agents.list '[{"id":"main","default":true,"name":"Research Assistant","workspace":"/home/test/.openclaw/workspace","agentDir":"/home/test/.openclaw/agents/research-assistant/agent","model":"openrouter/google/gemini-3-flash-preview"}]' --strict-json --replace

openclaw config validate
openclaw gateway restart

I’d do Option B if you just want it unstuck. It preserves your workspace/model and points main at the existing agent dir.

Those plugin install lines can look like a hang after reinstall, but the actual Control error is the missing main agent.

barren crown
#

Option B output:

test@test-VirtualBox:~$ openclaw backup create

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Your terminal just grew claws—type something and let the bot pinch the busywork.

Error: ENOENT: no such file or directory, lstat '/home/test/.openclaw/plugin-runtime-deps/openclaw-unknown-9e9924d0e53e/.openclaw-npm-cache/_logs/2026-04-27T02_11_34_341Z-debug-0.log'

velvet orioleBOT
#

Backup command is hitting a separate bug/race in the plugin npm cache. Skip openclaw backup create and make a tiny manual config backup instead:

cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak-$(date +%Y%m%d-%H%M%S)

Then run the fix:

openclaw config set agents.list '[{"id":"main","default":true,"name":"Research Assistant","workspace":"/home/test/.openclaw/workspace","agentDir":"/home/test/.openclaw/agents/research-assistant/agent","model":"openrouter/google/gemini-3-flash-preview"}]' --strict-json --replace

openclaw config validate
openclaw gateway restart

That backup create ENOENT is worth filing later, but it’s not the main Control error. The main issue is still: Control wants main, config only has research-assistant.

barren crown
#

openclaw tui hung

velvet orioleBOT
#

Don’t use TUI for this fix — it can get stuck trying to attach to the broken/stale session.

Press Ctrl+C in the TUI terminal, open a plain shell, then run:

cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak-$(date +%Y%m%d-%H%M%S)

openclaw config set agents.list '[{"id":"main","default":true,"name":"Research Assistant","workspace":"/home/test/.openclaw/workspace","agentDir":"/home/test/.openclaw/agents/research-assistant/agent","model":"openrouter/google/gemini-3-flash-preview"}]' --strict-json --replace

openclaw config validate
openclaw gateway restart

After that, try Control again.

If you want to test TUI before renaming the agent, use the explicit agent session:

#
openclaw tui --session agent:research-assistant:main
barren crown
#

test@test-VirtualBox:~$ openclaw tui --session agent:research-assistant:main

🦞 OpenClaw 2026.4.24 (cbcfdf6)
I'll refactor your busywork like it owes me money.

hung

velvet orioleBOT
#

Yep — don’t use openclaw tui yet. It’s trying to attach to sessions while your agent config is already in the weird state.

Hit Ctrl+C, then run the actual config repair from a normal shell:

cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak-$(date +%Y%m%d-%H%M%S)

openclaw config set agents.list '[{"id":"main","default":true,"name":"Research Assistant","workspace":"/home/test/.openclaw/workspace","agentDir":"/home/test/.openclaw/agents/research-assistant/agent","model":"openrouter/google/gemini-3-flash-preview"}]' --strict-json --replace

openclaw config validate
openclaw gateway restart

Then open Control again. If that config set command hangs too, paste the last thing it prints.

barren crown
#

where is the config set output

velvet orioleBOT
#

If it succeeded, openclaw config set ... may print very little or nothing useful — the confirmation is the next checks.

Run:

openclaw config get agents.list --json
openclaw config validate
openclaw agents list --bindings

You want agents.list to show "id": "main".

If the config set command is still sitting there and never returned, press Ctrl+C and rerun it with a timeout so we know:

timeout --foreground 30s openclaw config set agents.list '[{"id":"main","default":true,"name":"Research Assistant","workspace":"/home/test/.openclaw/workspace","agentDir":"/home/test/.openclaw/agents/research-assistant/agent","model":"openrouter/google/gemini-3-flash-preview"}]' --strict-json --replace
#
echo "exit=$?"
barren crown
#

test@test-VirtualBox:~$ cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak-$(date +%Y%m%d-%H%M%S)
test@test-VirtualBox:~$ openclaw config set agents.list '[{"id":"main","default":true,"name":"Research Assistant","workspace":"/home/test/.openclaw/workspace","agentDir":"/home/test/.openclaw/agents/research-assistant/agent","model":"openrouter/google/gemini-3-flash-preview"}]' --strict-json --replace

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Your .env is showing; don't worry, I'll pretend I didn't see it.

Config overwrite: /home/test/.openclaw/openclaw.json (sha256 33fadcf3dd8732a64c6d675d2c2d4c287d16ff6c08c52b2626b819338602933d -> ec8ce35905fb4fc0e34af0631ad9f9dd32f64e84747352acac8674cf50e44b1e, backup=/home/test/.openclaw/openclaw.json.bak)
Updated agents.list. Restart the gateway to apply.
test@test-VirtualBox:~$ openclaw config validate

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

Config valid: ~/.openclaw/openclaw.json
test@test-VirtualBox:~$ openclaw gateway restart

🦞 OpenClaw 2026.4.24 (cbcfdf6)
iMessage green bubble energy, but for everyone.

Restarted systemd service: openclaw-gateway.service
test@test-VirtualBox:~$

velvet orioleBOT
#

Perfect — that part is fixed ✅

Now check the gateway came back clean:

openclaw gateway status --deep
openclaw agents list --bindings

Then refresh Control UI. If it still shows the old error, clear site data for 127.0.0.1:18789 or start a new chat/session — the config now has main again, so any remaining issue is likely stale browser/session state.

barren crown
#

test@test-VirtualBox:~$ openclaw gateway status --deep

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Self-hosted, self-updating, self-aware (just kidding... unless?).



Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/test/.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 11494, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

  • pid 11494 test: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    Listening: 127.0.0.1:18789
    Troubles: run openclaw status
    Troubleshooting: https://docs.openclaw.ai/troubleshooting
    test@test-VirtualBox:~$ openclaw agents list --bindings

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Ah, the fruit tree company! 🍎

12:34:42 [plugins] acpx staging bundled runtime deps (1 missing, 33 i[[[[installing dep]]]]

velvet orioleBOT
#

This looks like warm-up / plugin dependency install, not a second gateway conflict.

That “port already in use” line is just PID 11494 — the gateway itself. The important bit is:

Warm-up: launch agents can take a few seconds
Connectivity probe: timeout
[plugins] ... staging bundled runtime deps

So: stop opening TUI / agents list for a minute and let the gateway finish installing deps.

In another terminal, watch the real log:

tail -f /tmp/openclaw/openclaw-2026-04-27.log
#

or:

journalctl --user -u openclaw-gateway -f

If it’s still stuck after ~5 minutes, paste the last 80 lines:

journalctl --user -u openclaw-gateway -n 80 --no-pager
tail -n 80 /tmp/openclaw/openclaw-2026-04-27.log

Don’t run more reinstall/doctor/TUI loops yet — that may be making the plugin install/cache race worse.

barren crown
#

eWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T12:40:32.721+10:00"}
{"0":"{"subsystem":"gateway/ws"}","1":"⇄ res ✓ models.list 220810ms conn=d6dbaa0e…164a id=883c9059…1c31","meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-04-27T02:40:32.727Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/test/.npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy.js:337:14","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T12:40:32.727+10:00"}
{"0":"{"subsystem":"gateway/ws"}","1":"⇄ res ✓ node.list 204270ms conn=d6dbaa0e…164a id=81440f7d…29d1","meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-04-27T02:40:32.815Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/test/.npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy.js:337:14","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T12:40:32.815+10:00"}

velvet orioleBOT
#

Those log lines are actually useful: models.list 220810ms / node.list 204270ms means requests eventually succeeded, but the gateway was blocked for ~3.5 minutes. So this is no longer “gateway died”; it’s “startup/plugin/model warmup is painfully slow or cache is wedged.”

Do this once, no TUI/doctor running:

openclaw gateway stop
mv ~/.openclaw/plugin-runtime-deps ~/.openclaw/plugin-runtime-deps.bak-$(date +%Y%m%d-%H%M%S) 2>/dev/null || true
openclaw gateway start
journalctl --user -u openclaw-gateway -f

Let it sit until plugin installs stop scrolling. Then:

openclaw gateway status --deep
openclaw agents list --bindings
#

The mv is just moving the plugin dependency cache aside, not deleting your config/creds. It should force a clean rebuild of the broken runtime-deps area that already threw that ENOENT earlier.

barren crown
#

by scrolling, does it stop or indicated bygeting user prompot back

velvet orioleBOT
#

If you’re running:

journalctl --user -u openclaw-gateway -f

that command does not return to the prompt by itself. It keeps following logs forever, even when startup is done.

You’re looking for the log spam to go quiet / no more “installing deps” lines for maybe 20–30 seconds.

Then press:

Ctrl+C

to get your prompt back, and run:

#
openclaw gateway status --deep

If it says Connectivity probe: ok, you’re good.

barren crown
#

ins] xai staging bundled runtime deps (3 missing, 28 install specs): @mariozechner/pi-ai@0.70.2, typebox@1.1.31, ws@^8.20.0
Apr 27 12:51:45 test-VirtualBox node[12637]: 2026-04-27T12:51:45.337+10:00 [plugins] xai installed bundled runtime deps in 6758ms: @mariozechner/pi-ai@0.70.2, typebox@1.1.31, ws@^8.20.0
Apr 27 12:53:27 test-VirtualBox node[12637]: 2026-04-27T12:53:27.955+10:00 [ws] ⇄ res ✓ node.list 51ms conn=0704a63a…d07f id=217ddbec…ff50

velvet orioleBOT
#

That looks much healthier.

The important line is:

node.list 51ms

Earlier it was taking ~204,000ms. So the gateway is responding normally now.

Press Ctrl+C to leave journalctl -f, then run:

openclaw gateway status --deep
openclaw agents list --bindings
#

If Connectivity probe: ok, try Control again. If Control still acts weird, refresh hard or clear site data for 127.0.0.1:18789.

barren crown
#

...zilla/readability@^0.6.0, linkedom@^0.18.12
13:08:44 [plugins] xai staging bundled runtime deps (3 missing, 28 install specs): @mariozechner/pi-ai@0.70.2, typebox@1.1.31, ws@^8.20.0
13:08:49 [plugins] xai installed bundled runtime deps in 5410ms: @mariozechner/pi-ai@0.70.2, typebox@1.1.31, ws@^8.20.0
Agents:

  • main (default) (Research Assistant)
    Workspace: ~/.openclaw/workspace
    Agent dir: ~/.openclaw/agents/research-assistant/agent
    Model: openrouter/google/gemini-3-flash-preview
    Routing rules: 0
    Routing: default (no explicit rules)
    Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
    Channel status reflects local config/creds. For live health: openclaw channels status --probe.
velvet orioleBOT
#

Great — the agent config is fixed now:

main (default) (Research Assistant)

So the old Control error should be gone.

Last check:

openclaw gateway status --deep

If that says Connectivity probe: ok, open/refresh Control. If Control still complains, clear browser site data for 127.0.0.1:18789 and reload.

If this finally fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow catches the fix. 🎉

barren crown
#

test@test-VirtualBox:~$ openclaw gateway status --deep

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Your second brain, except this one actually remembers where you left things.



Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/test/.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 12637, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
test@test-VirtualBox:~$

velvet orioleBOT
#

Beautiful — gateway is healthy now 🎉

Connectivity probe: ok
Capability: admin-capable

So the main fixes were:

  1. restored the expected main agent in agents.list
  2. moved aside the wedged plugin-runtime-deps cache and let it rebuild
  3. waited for bundled plugin deps to finish installing

Now open Control at:

#
http://127.0.0.1:18789/

If this solved it, please right-click the solution message → Apps → ✅ Mark Solution so future folks can find it on Answer Overflow.

barren crown
#

can i run tui

velvet orioleBOT
#

Yes — now it’s safe to try.

Run:

openclaw tui

If it hangs again, try the explicit session:

openclaw tui --session agent:main:main

And if it opens but no replies come back, type /status inside TUI first.

barren crown
#

test@test-VirtualBox:~$ openclaw tui

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Powered by open source, sustained by spite and good documentation.

still taking long time

velvet orioleBOT
#

TUI should not take minutes now. Give it ~30s max, then Ctrl+C.

Try a fresh/small load:

openclaw tui --session agent:main:main --history-limit 20

If it still only shows the banner, try terminal env:

TERM=xterm-256color openclaw tui --session agent:main:main --history-limit 20

If that hangs too, grab logs right after Ctrl+C:

#
openclaw logs --limit 80 --plain

Gateway is healthy, so this is likely TUI/session-history/plugin warmup, not the gateway dying anymore.

barren crown
#

test@test-VirtualBox:~$ openclaw tui

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Powered by open source, sustained by spite and good documentation.

openclaw tui - ws://127.0.0.1:18789 - agent main - session main
connecting | press ctrl+c again to exit
gateway disconnected: device identity required | idle
────────────────────────────────────────────────────────────────────────────────
gateway connect failed: GatewayClientRequestError: device identity required

velvet orioleBOT
#

Yep, TUI is reaching the gateway now — it’s just missing auth/device identity.

Run this, but don’t paste the token here:

openclaw config get gateway.auth.token

Then launch TUI with it:

openclaw tui --session agent:main:main --token "$(openclaw config get gateway.auth.token)"

If your config uses password auth instead, use:

#
openclaw tui --session agent:main:main --password "<your-password>"

Alternative if you just want a local no-gateway TUI:

openclaw tui --local
barren crown
#

test@test-VirtualBox:~$ openclaw tui --session agent:main:main --token "$(openclaw config get gateway.auth.token)"

🦞 OpenClaw 2026.4.24 (cbcfdf6) — The lobster in your shell. 🦞

still stall, is it too many plugins

velvet orioleBOT
#

Maybe, but first try forcing the gateway URL too — TUI may not be applying the token on the implicit connection path.

TOKEN="$(openclaw config get gateway.auth.token)"

openclaw tui \
  --url ws://127.0.0.1:18789 \
  --token "$TOKEN" \
  --session agent:main:main \
  --history-limit 20

Don’t paste the token here.

If it still sits after ~60s, Ctrl+C and check whether it’s plugin boot again:

#
openclaw logs --limit 80 --plain

If the logs show more [plugins] ... staging bundled runtime deps, then yeah — plugin/runtime-deps are still the slowdown. Gateway itself is healthy now; this is TUI/client startup/auth/plugin loading.

barren crown
#

test@test-VirtualBox:~$ openclaw tui --session agent:main:main --token "$(openclaw config get gateway.auth.token)"

🦞 OpenClaw 2026.4.24 (cbcfdf6) — The lobster in your shell. 🦞

openclaw tui - ws://127.0.0.1:18789 - agent main - session main
connecting | idle
gateway disconnected: device identity required | idle
────────────────────────────────────────────────────────────────────────────────
gateway connect failed: GatewayClientRequestError: device identity required
─────────────────────────────────────────────────────────────────────────────

velvet orioleBOT
#

I think the token command is the problem: $(openclaw config get ...) may be capturing the banner text too, so TUI receives a garbage token.

Try this cleaner version:

TOKEN="$(OPENCLAW_HIDE_BANNER=1 OPENCLAW_SUPPRESS_NOTES=1 openclaw config get gateway.auth.token --json | tr -d '"')"
echo "token chars: ${#TOKEN}"

openclaw tui \
  --url ws://127.0.0.1:18789 \
  --token "$TOKEN" \
  --session agent:main:main \
  --history-limit 20

Don’t paste the token value here — just tell me if token chars is 0, huge, or a normal-looking length.

#

If that still says device identity required, run:

openclaw devices list

and paste only whether it shows a pending TUI/operator request.

barren crown
#

is token chars: the token number?

velvet orioleBOT
#

No — don’t paste the token itself.

token chars is just the length of the token, like:

token chars: 64

That’s safe to share because it doesn’t reveal the secret.

So after running:

echo "token chars: ${#TOKEN}"

only tell me the number it prints, not the token value.

barren crown
#

value is two letter

velvet orioleBOT
#

A 2-character token length means that command did not retrieve a real token. It probably returned "" / empty JSON.

Generate one, restart, then retry TUI:

openclaw doctor --generate-gateway-token
openclaw gateway restart

TOKEN="$(OPENCLAW_HIDE_BANNER=1 OPENCLAW_SUPPRESS_NOTES=1 openclaw config get gateway.auth.token --json | tr -d '"')"
echo "token chars: ${#TOKEN}"

openclaw tui \
  --url ws://127.0.0.1:18789 \
  --token "$TOKEN" \
  --session agent:main:main \
  --history-limit 20
#

Again, don’t paste the token. A normal generated token should be much longer than 2 chars.

barren crown
#

openclaw doctor command prompted to isntall bundle plugin runtime deps again

velvet orioleBOT
#

For this moment, say no / cancel to the bundled plugin deps prompt. We’re only trying to fix the missing gateway token, and doctor is wandering into plugin repair again.

Set the token directly instead:

TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw gateway restart

echo "token chars: ${#TOKEN}"

openclaw tui \
  --url ws://127.0.0.1:18789 \
  --token "$TOKEN" \
  --session agent:main:main \
#
  --history-limit 20

Don’t paste the token value. token chars should be 64.

barren crown
#

prompts to archive orphan trascript

velvet orioleBOT
#

Cancel out of doctor entirely for now — don’t answer more repair prompts. Those are side quests.

Press Ctrl+C, then run only these plain commands:

TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw gateway restart

echo "token chars: ${#TOKEN}"

openclaw tui \
  --url ws://127.0.0.1:18789 \
  --token "$TOKEN" \
  --session agent:main:main \
#
  --history-limit 20

The orphan transcript prompt is safe-ish, but not needed for the TUI auth issue.

barren crown
#

test@test-VirtualBox:~$ echo "token chars: ${#TOKEN}

velvet orioleBOT
#

You’re missing the closing quote. Your shell is probably waiting for more input.

Press Ctrl+C, then run exactly:

echo "token chars: ${#TOKEN}"

If that prints 64, continue with:

openclaw tui \
  --url ws://127.0.0.1:18789 \
  --token "$TOKEN" \
  --session agent:main:main \
  --history-limit 20
barren crown
#

est@test-VirtualBox:~$ openclaw tui
--url ws://127.0.0.1:18789
--token "$TOKEN"
--session agent:main:main
--history-limit 20

🦞 OpenClaw 2026.4.24 (cbcfdf6)
We ship features faster than Apple ships calculator updates.

openclaw tui - ws://127.0.0.1:18789 - agent main (Research Assistant) -
session main

history failed: Error: gateway request timeout for chat.history

sessions list failed: Error: gateway request timeout for sessions.list
gateway connected | idle
agent main (Research Assistant) | session main | unknown | tokens ?
────────────────────────────────────────────────────────────────────────────────

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

velvet orioleBOT
#

Good — TUI is authenticated and connected now. The timeout is just history/session listing, not auth.

Try typing a tiny message in TUI:

hi

If it replies, you’re usable and the old history is just slow/bloated.

If sending also stalls, leave TUI with Ctrl+C and run:

openclaw logs --limit 120 --plain
openclaw sessions --all-agents --json
#

But this is real progress: no more device identity required, and it reached gateway connected.

barren crown
#

does it retain memory and configs?

velvet orioleBOT
#

Yes — the fixes we did should retain your config, workspace, creds, and files.

What changed:

  • ~/.openclaw/openclaw.json was backed up first.
  • agents.list was changed so your agent is called main again.
  • ✅ workspace stayed: ~/.openclaw/workspace
  • ✅ agent dir stayed: ~/.openclaw/agents/research-assistant/agent
  • ✅ plugin cache was moved aside/rebuilt; that’s not your memory/config.
  • ⚠️ gateway token was rotated, so Control UI may need the new token.

Old session history was not deleted. If some old chats don’t show, they may still be under:

~/.openclaw/agents/research-assistant/sessions
#

Don’t delete anything there. We can recover/copy sessions later if needed.

barren crown
#

test@test-VirtualBox:~$ openclaw tui
--url ws://127.0.0.1:18789
--token "$TOKEN"
--session agent:main:main
--history-limit 20

🦞 OpenClaw 2026.4.24 (cbcfdf6)
We ship features faster than Apple ships calculator updates.

openclaw tui - ws://127.0.0.1:18789 - agent main (Research Assistant) -
session main

history failed: Error: gateway request timeout for chat.history

sessions list failed: Error: gateway request timeout for sessions.list

hi

gateway disconnected: closed | idle
agent main (Research Assistant) | session main | unknown | tokens ?
────────────────────────────────────────────────────────────────────────────────

velvet orioleBOT
#

We’re past the auth/config issue now. This is a server-side timeout/close after TUI connects.

Don’t change more config yet. After that disconnect, run:

openclaw gateway status --deep
journalctl --user -u openclaw-gateway -n 120 --no-pager
tail -n 120 /tmp/openclaw/openclaw-2026-04-27.log

Paste the last error-ish chunk.

Also: if doctor prompted to archive orphan transcripts, that may be related to history/session timeouts. Once we see logs, we can decide whether to let doctor archive them. For now: gateway auth works; TUI connects; the failure is happening when loading/sending through the session.

barren crown
#

cca9f8b-816f-4e71-987f-8b7393f19c2b","host":"127.0.0.1:18789","origin":"http://127.0.0.1:18789","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0","remoteAddr":"127.0.0.1","remotePort":56796,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:56796->127.0.0.1:18789","authMode":"token","authProvided":"token","authReason":"device_token_mismatch","allowTailscale":false,"peer":"127.0.0.1:56796->127.0.0.1:18789","role":"operator","scopeCount":5,"hasDeviceIdentity":true,"client":"openclaw-control-ui","mode":"webchat","version":"2026.4.24","platform":"Linux x86_64","instanceId":"513b780a-3c17-45b1-9f78-3a93b0aed17c"},"2":"closed before connect conn=64fd4cab-5b49-4c54-8532-6841a84226b6 peer=127.0.0.1:56796->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0 code=4008 reason=connect failed","meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-04-27T03:34:34.417Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/test/.npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy.js:336:51","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:336","fileColumn":"51","fileLine":"336","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:336","method":"logToFile"}},"time":"2026-04-27T13:34:34.418+10:00"}

velvet orioleBOT
#

That log is Control UI, not TUI — and it explains why the browser is still failing:

authReason: device_token_mismatch
client: openclaw-control-ui

Because we rotated the gateway token, Firefox has an old paired device token cached.

Fix Control UI by clearing browser state for the gateway:

Firefox: open http://127.0.0.1:18789, click the lock/site icon → Clear cookies and site data
(or Settings → Privacy → Cookies/Site Data → search 127.0.0.1 → remove)

Then reload and paste the new gateway token into Control if prompted.

For TUI, use a separate terminal and logs right after the TUI disconnect, because the pasted log was browser-side. If TUI still closes, run:

#
journalctl --user -u openclaw-gateway -n 80 --no-pager | grep -iE 'tui|chat.history|sessions.list|closed|error|timeout'
barren crown
#

taking long time to connect

velvet orioleBOT
#

If this is Control UI after clearing Firefox data, give it ~30–60s once. If it’s still spinning, the fastest clean test is:

openclaw gateway status --deep
curl -sS http://127.0.0.1:18789/healthz

Then open a Private Window to:

http://127.0.0.1:18789/

Private window avoids the stale device-token cache completely.

If it still takes forever, paste:

#
journalctl --user -u openclaw-gateway -n 80 --no-pager | grep -iE 'connect|auth|device|control|timeout|error|closed'
barren crown
#

unauthorized: gateway token missing (open the dashboard URL and paste the token in Control UI settings)

tried to connect but cannot, stuck outside of gateway dashboard

velvet orioleBOT
#

You’re not locked out — the UI just needs the token bootstrap.

Run this:

openclaw dashboard --no-open

If it prints a URL with #token=..., copy/open that locally inside the VM. Don’t paste it here.

If it only prints the plain URL, build the token URL manually:

TOKEN="$TOKEN"
echo "http://127.0.0.1:18789/#token=$TOKEN"
#

Open that printed URL in Firefox. The #token=... part is important; it lets Control UI import the token before connecting.

If $TOKEN is gone because you opened a new shell, retrieve it with:

TOKEN="$(OPENCLAW_HIDE_BANNER=1 OPENCLAW_SUPPRESS_NOTES=1 openclaw config get gateway.auth.token --json | tr -d '"')"
echo "token chars: ${#TOKEN}"
echo "http://127.0.0.1:18789/#token=$TOKEN"

Again: don’t paste the token/URL here.

barren crown
#

est@test-VirtualBox:~$ openclaw dashboard --no-open

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Welcome to the command line: where dreams compile and confidence segfaults.

Dashboard URL: http://127.0.0.1:18789/
Token auto-auth included in browser/clipboard URL.
Copy to clipboard unavailable.
Browser launch disabled (--no-open). Use the URL above.

unauthorized: device token mismatch (rotate/reissue device token

velvet orioleBOT
#

The printed URL is hiding the token because it tried clipboard/browser auto-auth, but clipboard isn’t available. Build the URL manually and use a Private Window so Firefox doesn’t reuse the bad device token.

TOKEN="$(OPENCLAW_HIDE_BANNER=1 OPENCLAW_SUPPRESS_NOTES=1 openclaw config get gateway.auth.token --json | tr -d '"')"
echo "token chars: ${#TOKEN}"
echo "http://127.0.0.1:18789/#token=$TOKEN"

Open the printed #token=... URL in a Firefox Private Window.

If normal Firefox still says device token mismatch, clear site data for 127.0.0.1:18789; it has a stale paired-device token from before we rotated gateway auth.

barren crown
#

token equals openclaw reacted?

velvet orioleBOT
#

No — the token should be a long random string, not “openclaw reacted”.

Use this instead; it avoids the banner/tagline contaminating the token:

TOKEN="$(node -e "const fs=require('fs'); const c=fs.readFileSync(process.env.HOME+'/.openclaw/openclaw.json','utf8'); const m=c.match(/token[\"']?\\s*[:=]\\s*[\"']([^\"']+)/); console.log(m?m[1]:'')")"
echo "token chars: ${#TOKEN}"
echo "http://127.0.0.1:18789/#token=$TOKEN"

If token chars is 64, open the printed URL in a Private Window.

Don’t paste the URL here because it contains the token.

barren crown
#

unauthorized: too many failed authentication attempts (retry later)

velvet orioleBOT
#

That’s the browser auth lockout from the failed token attempts. Stop trying to connect for a bit or it keeps resetting.

Do this:

  1. Close the Control UI tab.
  2. Wait 5 minutes.
  3. Reopen in a Private Window using the #token=... URL you generated.

If you don’t want to wait, restarting the gateway should clear the in-memory limiter:

openclaw gateway restart

Then immediately use the correct #token=... URL in a Private Window — don’t open the plain URL first.

barren crown
#

disconnected (1006): no reason

velvet orioleBOT
#

1006 is generic “socket closed without a clean reason” — usually gateway restarted/crashed, browser auth got wedged, or the connection was killed during startup.

Check if gateway is still healthy:

openclaw gateway status --deep
journalctl --user -u openclaw-gateway -n 100 --no-pager

If status says probe ok, try again in a Private Window with the #token=... URL.

If status does not say Connectivity probe: ok, paste the last ~30 lines from journalctl around the disconnect.

barren crown
#

openclaw contorl opened after running gateway health

velvet orioleBOT
#

That sounds like the gateway is at least coming up enough for Control UI, but we still need the crash/hang clue.

Can you paste:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw logs --follow

Let logs --follow run until it hangs/dies, then paste the last ~50 lines. If you’re on 2026.4.24, mention that too — there have been a few weird reports around that update, but the log tail will tell us whether this is version-related or config/runtime.

Docs for the triage ladder: https://docs.openclaw.ai/help/faq

barren crown
#

do i not go and change firefox's token to match in previous instructions?

velvet orioleBOT
#

Yes — if the Control UI is saying auth/token mismatch, update the Control UI token stored in Firefox to match the gateway’s token.

But important distinction:

  • Don’t change the gateway token to match Firefox.
  • Do change Firefox/Control UI’s saved Gateway Token to match the gateway config.
  • If the gateway is truly crashing/killing itself after ~5 seconds, token mismatch is probably a separate symptom, not the crash cause.

Use:

openclaw config get gateway.auth.token

Don’t paste that token here. In Control UI go to Control → Overview → Gateway Access, paste it into Gateway Token, then reconnect. If your auth mode is password, use the Password field instead.

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

barren crown
#

03:59:57+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"handshake":"pending","durationMs":9,"host":"127.0.0.1:18789","origin":"http://127.0.0.1:18789","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0","remoteAddr":"127.0.0.1","remotePort":33616,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:33616->127.0.0.1:18789"} closed before connect conn=538255b2-e881-431b-b8c2-a06f48945cdb peer=127.0.0.1:33616->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0 code=1006 reason=n/a
03:59:57+00:00 info gateway {"subsystem":"gateway"} device pairing auto-approved device=01aa5f567bfc14af8a6665736784e7b2291faf997e2f38b1b4b38548700723fe role=operator
03:59:57+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=898b0a5a-d3ea-45a7-b760-53ce34e9839d remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.24
03:59:57+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=fff960c7-7d03-42b5-a01c-11d89428ce20 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.24
03:59:57+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 328ms conn=fff960c7…ce20 id=5afe90bb…bf8a
03:59:57+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 336ms conn=fff960c7…ce20 id=49efef80…aa13
03:59:57+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ models.list 337ms conn=fff960c7…ce20 id=3d3a6043…45ea
03:59:58+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 586ms conn=fff960c7…ce20 id=aecc88bd…4076
03:59:58+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 588ms conn=fff960c7…ce20 id=0a5e551a…2e64
04:01:46+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 149ms conn=c02dae89…6993 id=20ef49b3…2bd3
Log tail truncated (increase --max-bytes).

few if many lines gotten from --follow

velvet orioleBOT
#

Those lines don’t show the gateway killing itself — they show Control UI successfully connecting:

  • webchat connected ... v2026.4.24
  • commands.list, chat.history, models.list, node.list all returned ✓
  • The closed before connect ... code=1006 line is usually just the browser closing/retrying one WebSocket during page load/reload. Annoying, but not the fatal crash by itself.

Need the earlier/larger log chunk where the gateway actually exits. Try:

openclaw logs --plain --limit 500 --max-bytes 1000000
openclaw gateway status
openclaw status --all
openclaw --version

If it’s installed as a Linux service, also grab:

#
journalctl --user -u openclaw-gateway.service --no-pager -n 200

Paste the first error/fatal block, or the lines right before the service restarts/exits. And yes, since this says v2026.4.24, update/rollback might be relevant — but we need the actual fatal line before calling it an update bug.

barren crown
#

Diagnosis (read-only)

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

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

  • pid 22381 test: 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: 11 eligible · 0 missing · /home/test/.openclaw/workspace
    ✓ Plugin compatibility (none)
    ✓ Channel issues (none)

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


OpenClaw 2026.4.24 (cbcfdf6)
test@test-VirtualBox:~$

velvet orioleBOT
#

That output actually says the gateway is running, not killed:

pid 22381 test: openclaw-gateway (127.0.0.1:18789)
Port 18789 is already in use.

So if you’re running openclaw gateway manually, it may look like it “dies” because another gateway already owns the port.

Do this instead:

openclaw gateway status --deep
openclaw health --verbose
openclaw logs --plain --limit 500 --max-bytes 1000000
#

If you want a clean restart:

openclaw gateway restart

Then re-check:

openclaw gateway status
openclaw health --verbose

You’re on 2026.4.24, and there have been some weird reports around that version, but this specific snippet is just “already running on port 18789,” not the fatal error yet.

barren crown
#

where is the first error block

velvet orioleBOT
#

It would be in the log output, not in that diagnosis report. The report you pasted has no crash block — just:

! Port 18789 is already in use

That usually means “gateway already running.”

To find the first real error block, run:

openclaw logs --plain --limit 1000 --max-bytes 2000000 > /tmp/openclaw-log.txt
grep -nEi "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE" /tmp/openclaw-log.txt | head -20

Then take the first line number it prints and show context around it, e.g. if it says 123:error...:

#
sed -n '110,150p' /tmp/openclaw-log.txt

Also useful:

journalctl --user -u openclaw-gateway.service --no-pager -n 500

Paste the first error/fatal chunk from there.

barren crown
#

test@test-VirtualBox:~$ openclaw logs --plain --limit 1000 --max-bytes 2000000 > /tmp/openclaw-log.txt
grep -nEi "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE" /tmp/openclaw-log.txt | head -20
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/test/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.
test@test-VirtualBox:~$

velvet orioleBOT
#

Ah, that means openclaw logs couldn’t connect to the gateway RPC, so the file you redirected to is probably empty. Use the local file logs / systemd journal instead:

openclaw gateway status --deep
ls -lt /tmp/openclaw/openclaw-*.log 2>/dev/null | head
tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Then search that local tail:

tail -n 1000 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" > /tmp/openclaw-log.txt
grep -nEi "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE|listen" /tmp/openclaw-log.txt | head -20

Also grab the service journal:

#
journalctl --user -u openclaw-gateway.service --no-pager -n 300

Paste openclaw gateway status --deep plus the first error/fatal chunk from either the local log or journal. If status says “port in use” but logs says “gateway not reachable,” that’s the interesting broken/stale process state.

barren crown
#

wait what am i pasting? there is too big of a response from bnoth

velvet orioleBOT
#

Yeah, don’t paste the whole thing — my bad. Paste only these small outputs:

openclaw gateway status --deep

Then run this and paste the output:

LOG="$(ls -t /tmp/openclaw/openclaw-*.log 2>/dev/null | head -1)"
echo "$LOG"
grep -nEi "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE|listen|port" "$LOG" | tail -20

And for systemd, paste only this filtered version:

#
journalctl --user -u openclaw-gateway.service --no-pager -n 500 \
  | grep -Ei "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE|listen|port" \
  | tail -30

That should be small enough and should catch the useful lines.

barren crown
#

test@test-VirtualBox:~$ LOG="$(ls -t /tmp/openclaw/openclaw-*.log 2>/dev/null | head -1)"
echo "$LOG"
grep -nEi "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE|listen|port" "$LOG" | tail -20
/tmp/openclaw/openclaw-2026-04-27.log
784:{"0":"{"subsystem":"gateway/ws"}","1":{"cause":"unauthorized","handshake":"failed","durationMs":25,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"0c1e3eff-6adf-4817-bed1-8c19b5bd50ca","host":"127.0.0.1:18789","origin":"http://127.0.0.1:18789","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0","remoteAddr":"127.0.0.1","remotePort":35098,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:35098->127.0.0.1:18789","authMode":"token","authProvided":"token","authReason":"rate_limited","allowTailscale":false,"peer":"127.0.0.1:35098->127.0.0.1:18789","role":"operator","scopeCount":5,"hasDeviceIdentity":true,"client":"openclaw-control-ui","mode":"webchat","version":"control-ui","platform":"Linux x86_64","instanceId":"77856ff4-a58c-43aa-94e6-daf91930f0e5"},"2":"closed before connect conn=251aaf3f-2106-4680-9b8c-4dbc64ebf5a2 peer=127.0.0.1:35098->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0 code=4008 reason=connect failed","meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-04-27T03:52:36.896Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/test/.npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy.js:336:51","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:336","fileColumn":"51","fileLine":"336","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:336","method":"logToF

#

786:{"0":"{"subsystem":"gateway/ws"}","1":{"cause":"unauthorized","handshake":"failed","durationMs":13,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"dfb3f6f3-2ca0-46bf-aa59-fffa4d2f50a2","host":"127.0.0.1:18789","origin":"http://127.0.0.1:18789","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0","remoteAddr":"127.0.0.1","remotePort":35104,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:35104->127.0.0.1:18789","authMode":"token","authProvided":"token","authReason":"rate_limited","allowTailscale":false,"peer":"127.0.0.1:35104->127.0.0.1:18789","role":"operator","scopeCount":5,"hasDeviceIdentity":true,"client":"openclaw-control-ui","mode":"webchat","version":"control-ui","platform":"Linux x86_64","instanceId":"77856ff4-a58c-43aa-94e6-daf91930f0e5"},"2":"closed before connect conn=3c28330f-b89b-468b-8b38-f53c8aa56926 peer=127.0.0.1:35104->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0 code=4008 reason=connect failed","meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-04-27T03:52:37.597Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/test/.npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy.js:336:51","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:336","fileColumn":"51","fileLine":"336","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:336","method":"logToFile"}},"time":"2026-04-27T13:52:37.597+10:00"}

velvet orioleBOT
#

Yep — that line is the useful error block.

The key part is:

cause: unauthorized
authMode: token
authProvided: token
authReason: rate_limited
code=4008 reason=connect failed

So this is not showing a gateway crash. It means Firefox/Control UI has been trying to connect with bad/stale auth enough times that the gateway is temporarily rate-limiting it.

Do this:

  1. Close all Control UI / 127.0.0.1:18789 Firefox tabs.
#
  1. Restart gateway to clear the in-memory auth limiter:
openclaw gateway restart
  1. Reopen Control UI.
  2. In Control → Overview → Gateway Access, paste the current token from:
openclaw config get gateway.auth.token

Don’t paste the token here.

If Firefox keeps reusing the bad one, clear site data for 127.0.0.1:18789 or try a private window, then enter the token fresh.

#

Yep, same thing again — auth rate-limited, not a crash.

Relevant bits:

authReason: "rate_limited"
code=4008
reason=connect failed

Fix path:

openclaw gateway restart

Then before reopening/refreshing Control UI, close all Firefox tabs for 127.0.0.1:18789.

#

If Firefox keeps looping, clear site data for 127.0.0.1:18789 or use a private window, then paste the fresh token from:

openclaw config get gateway.auth.token

If after that it still fails, paste the new log line — we want to see whether it changes from rate_limited to token_mismatch / pairing required / something else.

barren crown
#

tokes redacted

velvet orioleBOT
#

Right — if openclaw config get gateway.auth.token is redacted, use the dashboard helper instead:

openclaw dashboard

That should open/print the Control UI link with the correct auth flow. If it prints a URL with #token=..., open that exact URL in Firefox.

If it still doesn’t expose the token, generate a new one and restart:

openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
openclaw gateway restart
openclaw dashboard

Then close old Firefox Control UI tabs so they don’t keep retrying with the stale token.

barren crown
#

onboards opened, now what

velvet orioleBOT
#

Good — that means you’re back in the browser flow.

Do this:

  1. Close any old 127.0.0.1:18789 tabs first.
  2. In the onboarding page, choose/connect to the local gateway:
    http://127.0.0.1:18789
    
  3. If it asks for auth, use Gateway Token — not password.
  4. If it asks for device approval, run:
    openclaw devices list
    openclaw devices approve <requestId>
    

If onboarding fully finishes and the dashboard loads, you’re good. Then check:

#
openclaw health --verbose

If it bounces back to onboarding or says disconnected, paste the exact UI error text.

barren crown
#

by old, you mean all or retain the current one

velvet orioleBOT
#

Keep the current onboarding tab open.

Close the other/old OpenClaw tabs — anything else pointing at:

127.0.0.1:18789
localhost:18789

The goal is to stop old tabs from auto-retrying with the stale token while you finish onboarding in the current tab.

barren crown
#

i dont get what you want, i am in contro openclaw chat right now

velvet orioleBOT
#

Ah okay — if you’re already inside Control UI chat, then don’t close that tab. You’re connected.

At this point ignore the old auth/rate-limit stuff unless it disconnects again. Do this one check:

openclaw health --verbose

If that says healthy/ok, you’re done.

If Control UI chat hangs/ghosts when you send a message, paste the last ~30 lines from:

openclaw logs --plain --limit 100 --max-bytes 300000

So: stay in the current Control UI tab, send a tiny test like hi, and see if it replies.

barren crown
#

in the terminal or in control

velvet orioleBOT
#

Both, but in this order:

  1. Terminal: run

    openclaw health --verbose
    
  2. Control UI chat: send a tiny test message like:

    hi
    

If terminal health is OK but Control chat hangs, then we debug the chat/model side next.

barren crown
#

ui chat is loading for a long time

velvet orioleBOT
#

If the UI chat itself is stuck loading, don’t keep refreshing yet — first check whether the gateway/model is actually healthy.

In the terminal, run:

openclaw health --verbose
openclaw models status

If those look OK, send hi in Control UI, wait ~20 seconds, then run:

openclaw logs --plain --limit 150 --max-bytes 400000 \
  | grep -Ei "chat.send|agent|model|auth|error|fatal|timeout|rate|failed|started|completed" \
  | tail -50
#

Paste that filtered output.

Most likely we’ve moved past the token issue and are now debugging either:

  • model auth/provider problem,
  • agent run stuck,
  • or Control UI chat history/session loading weirdness.
barren crown
#

test@test-VirtualBox:~$ openclaw health --verbose

🦞 OpenClaw 2026.4.24 (cbcfdf6)
I can't fix your code taste, but I can fix your build and your backlog.



[openclaw] Failed to start CLI: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/test/.openclaw/openclaw.json
Bind: loopback
at Timeout.<anonymous> (file:///home/test/.npm-global/lib/node_modules/openclaw/dist/call-Gv9tybWD.js:262:9)
at listOnTimeout (node:internal/timers:605:17)
at process.processTimers (node:internal/timers:541:7)
test@test-VirtualBox:~$ openclaw models status

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Runs on a Raspberry Pi. Dreams of a rack in Iceland.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/gpt-5.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

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

  • openrouter effective=models.json:sk-or-v1...77d5f2a0 | models.json=sk-or-v1...77d5f2a0 | source=models.json: ~/.openclaw/agents/main/agent/models.json

Missing auth

est@test-VirtualBox:~$ openclaw logs --plain --limit 150 --max-bytes 400000
| grep -Ei "chat.send|agent|model|auth|error|fatal|timeout|rate|failed|started|completed"
| tail -50
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/test/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.

velvet orioleBOT
#

Okay, now we have the real state: gateway is present on the port, but RPC is timing out. That’s why Control UI chat keeps loading.

Do a clean gateway reset:

# close Control UI browser tabs first
openclaw gateway stop
sleep 3
openclaw gateway start
openclaw gateway status --deep
openclaw health --verbose

If stop hangs/fails or status still says port 18789 is in use, paste only:

#
openclaw gateway status --deep
ps -fp 22381

Also: your model config may be next issue — Default: openai/gpt-5.5 but auth shown is OpenRouter. First we need gateway reachable; then we’ll fix model/default if chat still hangs.

barren crown
#


Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/test/.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 26715, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Gateway port 18789 is not listening (service appears running).
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Restart log: ~/.openclaw/logs/gateway-restart.log

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

🦞 OpenClaw 2026.4.24 (cbcfdf6)
I read logs so you can keep pretending you don't have to.



[openclaw] Failed to start CLI: Error: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/test/.openclaw/openclaw.json
Bind: loopback

Section 2 coming next mesage

#

Possible causes:

  • Gateway not yet ready to accept connections (retry after a moment)
  • TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
  • Gateway crashed or was terminated unexpectedly
    Run openclaw doctor for diagnostics.
    at Object.onClose (file:///home/test/.npm-global/lib/node_modules/openclaw/dist/call-Gv9tybWD.js:257:10)
    at WebSocket.<anonymous> (file:///home/test/.npm-global/lib/node_modules/openclaw/dist/client-kQ1-TM3I.js:2281:23)
    at WebSocket.emit (node:events:508:28)
    at WebSocket.emitClose (/home/test/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:263:12)
    at emitErrorAndClose (/home/test/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:1047:13)
    at ClientRequest.<anonymous> (/home/test/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:886:5)
    at ClientRequest.emit (node:events:508:28)
    at emitErrorEvent (node:_http_client:108:11)
    at Socket.socketErrorListener (node:_http_client:575:5)
    at Socket.emit (node:events:508:28)
velvet orioleBOT
#

Got it — this is the important part:

Runtime: running
Connectivity probe: failed
connect ECONNREFUSED
Gateway port 18789 is not listening (service appears running)

So yeah: not a Firefox token issue now. The service process exists, but the gateway server isn’t actually listening on the port.

Send section 2. The most useful thing will be the journal lines from:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager
#

Especially anything with error, fatal, plugin, npm, ENOTEMPTY, or startup messages.

#

That bit is still the CLI client stack trace, not the gateway’s reason for failing. The gateway reason should be in systemd journal or the file log.

Run this exact filtered command and paste its output:

journalctl --user -u openclaw-gateway.service --no-pager -n 300 \
  | grep -Ei "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE|listen|plugin|npm|ENOTEMPTY|startup|ready" \
  | tail -80

Also paste:

cat ~/.openclaw/logs/gateway-restart.log 2>/dev/null | tail -80

What we know now: the service process starts, but it’s not listening on 18789, so something during gateway startup is wedged/crashing before the server is ready. This could be a 2026.4.24 issue, but the journal will tell us what kind.

barren crown
velvet orioleBOT
#

I tried opening the ShareText link, but it isn’t giving me readable log text from here. (sharetext.io)

Please paste this directly in Discord — it should be small:

journalctl --user -u openclaw-gateway.service --no-pager -n 300 \
  | grep -Ei "error|fatal|uncaught|exception|failed|exited|killed|EADDRINUSE|listen|plugin|npm|ENOTEMPTY|startup|ready" \
  | tail -80

And this too:

cat ~/.openclaw/logs/gateway-restart.log 2>/dev/null | tail -80

We’re looking for why the service is “running” but not listening on 18789.

ShareText is a simple way to share text and code with others for free online with Markdown support.

barren crown
#

it is infact not small

velvet orioleBOT
#

Fair 😅 Let’s make it tiny.

Run these and paste just the output:

journalctl --user -u openclaw-gateway.service --no-pager -n 80

If that’s still huge, use this one-liner instead:

journalctl --user -u openclaw-gateway.service --no-pager -n 300 \
  | grep -i "Cannot find package\|ENOTEMPTY\|EADDRINUSE\|uncaught\|fatal\|failed\|error" \
  | tail -20

And for the restart log:

#
tail -30 ~/.openclaw/logs/gateway-restart.log 2>/dev/null

Also, based on 2026.4.24, if you see anything like plugin runtime deps, npm ENOTEMPTY, or missing package errors, this may match the update regression others have hit.

barren crown
#

whole thing over wordrestriction by 5k

velvet orioleBOT
#

No worries — don’t fight Discord’s limit. Make a tiny file and attach the file instead:

{
  echo "=== gateway status ==="
  openclaw gateway status --deep 2>&1 | head -80

  echo
  echo "=== journal filtered ==="
  journalctl --user -u openclaw-gateway.service --no-pager -n 1000 -o cat \
    | grep -Ei "Cannot find|ERR_|ENOTEMPTY|EADDRINUSE|TypeError|ReferenceError|SyntaxError|Unhandled|uncaught|fatal|Error:" \
    | tail -30 \
    | cut -c1-500

  echo
  echo "=== restart log ==="
#
  tail -80 ~/.openclaw/logs/gateway-restart.log 2>/dev/null | cut -c1-500
} > /tmp/openclaw-debug-small.txt

wc -c /tmp/openclaw-debug-small.txt

Then upload /tmp/openclaw-debug-small.txt here.

If even that’s huge, run:

tail -40 /tmp/openclaw-debug-small.txt
barren crown
#

cant upload files

velvet orioleBOT
#

Gotcha. Then let’s reduce it to one screen.

Run this:

journalctl --user -u openclaw-gateway.service --no-pager -n 1000 -o cat \
  | grep -Ei "Cannot find|ERR_|ENOTEMPTY|EADDRINUSE|TypeError|ReferenceError|SyntaxError|Unhandled|uncaught|fatal|Error:" \
  | tail -10 \
  | cut -c1-300

Paste that output only.

If it prints nothing, run this instead and paste output:

#
tail -80 /tmp/openclaw/openclaw-2026-04-27.log \
  | grep -Ei "Cannot find|ERR_|ENOTEMPTY|EADDRINUSE|TypeError|ReferenceError|SyntaxError|Unhandled|uncaught|fatal|Error:" \
  | tail -10 \
  | cut -c1-300
barren crown
#

test@test-VirtualBox:~$ journalctl --user -u openclaw-gateway.service --no-pager -n 1000 -o cat
| grep -Ei "Cannot find|ERR_|ENOTEMPTY|EADDRINUSE|TypeError|ReferenceError|SyntaxError|Unhandled|uncaught|fatal|Error:"
| tail -10
| cut -c1-300
2026-04-27T11:38:00.948+10:00 [gateway] [plugins] failed to install bundled runtime deps: Error: ENOENT: no such file or directory, scandir '/home/test/.npm-global/lib/node_modules/openclaw/dist' (plugin=phone-control, source=/home/test/.npm-global/lib/node_modules/openclaw/dist/extensions/phone-con
2026-04-27T11:38:00.949+10:00 [gateway] [plugins] failed to install bundled runtime deps: Error: ENOENT: no such file or directory, scandir '/home/test/.npm-global/lib/node_modules/openclaw/dist' (plugin=talk-voice, source=/home/test/.npm-global/lib/node_modules/openclaw/dist/extensions/talk-voice/i
2026-04-27T11:38:01.038+10:00 [health] initial refresh failed: Cannot find module '/home/test/.npm-global/lib/node_modules/openclaw/dist/config-NTLYkTUO.js' imported from /home/test/.npm-global/lib/node_modules/openclaw/dist/health-DpiT_nOq.js
2026-04-27T11:38:01.057+10:00 Gateway failed to start: Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/test/.npm-global/lib/node_modules/openclaw/dist/server-startup-log-B9JxhIZA.js' imported from /home/test/.npm-global/lib/node_modules/openclaw/dist/server.impl-CtLS1ywt.js
Error: Cannot find module '/home/test/.npm-global/lib/node_modules/openclaw/dist/index.js'
Error: Cannot find module '/home/test/.npm-global/lib/node_modules/openclaw/dist/index.js'
throw new ERR_MODULE_NOT_FOUND(
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/test/.npm-global/lib/node_modules/openclaw/dist/unhandled-rejections-Bzjq4Io_.js' imported from /home/test/.npm-global/lib/node_modules/openclaw/dist/index.js
code: 'ERR_MODULE_NOT_FOUND',
url: 'file:///home/test/.npm-global/lib/node_modules/openclaw/dist/unhandled-rejections-Bzjq4Io_.js'

velvet orioleBOT
#

Yep, that’s the real failure. Your OpenClaw install is corrupted/incomplete:

Cannot find module .../openclaw/dist/...
Cannot find module .../openclaw/dist/index.js
Gateway failed to start

So this is not Firefox/token anymore. The gateway can’t start because files are missing from the global npm install.

Run:

openclaw gateway stop
npm i -g openclaw@latest
openclaw gateway install --force
#
openclaw gateway restart
openclaw gateway status --deep

This should not delete your config/state — that lives in ~/.openclaw.

If that still gives missing dist/* files, try the installer recovery path:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --no-onboard
openclaw gateway restart

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

barren crown
#

test@test-VirtualBox:~$ openclaw gateway restart
openclaw gateway status --deep

🦞 OpenClaw 2026.4.24 (cbcfdf6) — The lobster in your shell. 🦞

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.24 (cbcfdf6)
I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.



Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/test/.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 27715, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

  • pid 27715 test: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    Listening: 127.0.0.1:18789
    Troubles: run openclaw status
    Troubleshooting: https://docs.openclaw.ai/troubleshooting
velvet orioleBOT
#

This output means the service is now listening, but the RPC probe is timing out:

Listening: 127.0.0.1:18789
Connectivity probe: failed: timeout

Important: did you run the reinstall step, or only restart?

If you did not run this yet, do it now:

npm i -g openclaw@latest
openclaw gateway install --force
openclaw gateway restart
#

Then wait ~10 seconds and run:

openclaw health --timeout 30000 --verbose

If you did already reinstall, paste this tiny filtered output:

journalctl --user -u openclaw-gateway.service --no-pager -n 500 -o cat \
  | grep -Ei "Cannot find|ERR_MODULE_NOT_FOUND|ENOENT|ENOTEMPTY|TypeError|fatal|Gateway failed|failed to install" \
  | tail -20 \
  | cut -c1-300

The earlier error showed missing dist/* files, so restart alone won’t fix it — the global install needs repair.

barren crown
#

i ran the steps before and including health timeoput

velvet orioleBOT
#

Okay, thanks — then reinstall repaired enough to listen, but gateway is still wedged during startup/RPC.

Paste this filtered output:

journalctl --user -u openclaw-gateway.service --no-pager -n 500 -o cat \
  | grep -Ei "Cannot find|ERR_MODULE_NOT_FOUND|ENOENT|ENOTEMPTY|TypeError|fatal|Gateway failed|failed to install|timeout|health|started|listening" \
  | tail -30 \
  | cut -c1-350

Also run this quick check:

openclaw --version
npm ls -g openclaw --depth=0
#

If the filtered journal still shows missing dist/* after reinstall, the npm package tree is still broken and I’d use the installer recovery path next.

barren crown
#

est@test-VirtualBox:~$ journalctl --user -u openclaw-gateway.service --no-pager -n 500 -o cat
| grep -Ei "Cannot find|ERR_MODULE_NOT_FOUND|ENOENT|ENOTEMPTY|TypeError|fatal|Gateway failed|failed to install|timeout|health|started|listening"
| tail -30
| cut -c1-350
2026-04-27T13:56:33.471+10:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T13:56:33.491+10:00 [heartbeat] started
2026-04-27T13:58:39.318+10:00 [ws] handshake timeout conn=898b0a5a-d3ea-45a7-b760-53ce34e9839d peer=127.0.0.1:57604->127.0.0.1:18789 remote=127.0.0.1
openclaw-gateway.service: Failed with result 'timeout'.
Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.24).
2026-04-27T14:24:15.574+10:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-04-27T14:24:15.908+10:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T14:24:15.944+10:00 [heartbeat] started
2026-04-27T14:27:42.366+10:00 [ws] handshake timeout conn=4a137b92-2615-4553-9400-bf2e58817151 peer=127.0.0.1:45222->127.0.0.1:18789 remote=127.0.0.1
openclaw-gateway.service: Failed with result 'timeout'.
Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.24).
2026-04-27T14:39:12.574+10:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-04-27T14:39:12.938+10:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T14:39:12.961+10:00 [heartbeat] started
openclaw-gateway.service: Failed with result 'timeout'.
Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.24).
2026-04-27T14:52:10.207+10:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-04-27T14:52:10.653+10:00

#

[browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T14:52:10.680+10:00 [heartbeat] started
openclaw-gateway.service: Failed with result 'timeout'.
Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.24).
2026-04-27T14:52:57.190+10:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-04-27T14:52:57.532+10:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T14:52:57.560+10:00 [heartbeat] started
2026-04-27T14:54:06.997+10:00 [gateway] Session delivery recovery failed: Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/test/.npm-global/lib/node_modules/openclaw/dist/server-restart-sentinel-mQedG9j5.js' imported from /home/test/.npm-global/lib/node_modules/openclaw/dist/server.impl-CtLS1ywt.js
Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.24).
Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.24).
2026-04-27T14:55:00.468+10:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-04-27T14:55:00.820+10:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T14:55:00.842+10:00 [heartbeat] started

#

test@test-VirtualBox:~$ openclaw --version
npm ls -g openclaw --depth=0
OpenClaw 2026.4.24 (cbcfdf6)
/home/test/.npm-global/lib
└── openclaw@2026.4.24

velvet orioleBOT
#

That confirms it’s not fixed yet, but it’s a different failure now:

[heartbeat] started
[ws] handshake timeout
openclaw-gateway.service: Failed with result 'timeout'

At this point I’d stop chasing Firefox and roll back from 2026.4.24. This looks like a bad 2026.4.24 startup/runtime state on your install, not normal auth.

Run:

openclaw gateway stop
npm i -g openclaw@2026.4.23
openclaw gateway install --force
#
openclaw gateway restart
openclaw gateway status --deep
openclaw health --timeout 30000 --verbose

That should keep your ~/.openclaw config/state. If 2026.4.23 comes up clean, please file a GitHub issue with the Failed with result 'timeout' / handshake timeout logs: https://github.com/openclaw/openclaw/issues

#

Yep — that line seals it:

ERR_MODULE_NOT_FOUND ... dist/server-restart-sentinel-...

Your installed package is still missing built dist files. I’d stop trying 2026.4.24 and roll back:

openclaw gateway stop
npm i -g openclaw@2026.4.23
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep
openclaw health --timeout 30000 --verbose
#

If npm i -g openclaw@2026.4.23 fails or the missing-module error remains, use the installer recovery:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --version 2026.4.23 --no-onboard
openclaw gateway restart

This should keep your ~/.openclaw data.

#

Yep, that confirms you’re still on the broken 2026.4.24 install.

Run the rollback exactly:

openclaw gateway stop
npm i -g openclaw@2026.4.23
openclaw --version
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

You want openclaw --version to show 2026.4.23 before restarting the gateway.

barren crown
#

est@test-VirtualBox:~$ openclaw gateway stop
npm i -g openclaw@2026.4.23
openclaw --version
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

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

Stopped systemd service: openclaw-gateway.service
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead

added 38 packages, removed 1 package, and changed 430 packages in 44s

85 packages are looking for funding
run npm fund for details
OpenClaw 2026.4.23 (a979721)
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.

🦞 OpenClaw 2026.4.23 (a979721)
Your personal assistant, minus the passive-aggressive calendar reminders.

Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.

◇ Config warnings ────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.bonjour: plugin not found: bonjour (stale config │
│ entry ignored; remove it from plugins config) │
│ │
├──────────────────────────────────────────────────────────────────────╯
Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.

#

Installed systemd service: /home/test/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /home/test/.config/systemd/user/openclaw-gateway.service.bak
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.

🦞 OpenClaw 2026.4.23 (a979721)
I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.

◇ Config warnings ────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.bonjour: plugin not found: bonjour (stale config │
│ entry ignored; remove it from plugins config) │
│ │
├──────────────────────────────────────────────────────────────────────╯
Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
Restarted systemd service: openclaw-gateway.service
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
#

🦞 OpenClaw 2026.4.23 (a979721)
Open source means you can see exactly how I judge your config.

Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.


Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/test/.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 28814, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

  • pid 28814 test: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    Listening: 127.0.0.1:18789
    Troubles: run openclaw status
    Troubleshooting: https://docs.openclaw.ai/troubleshooting
    test@test-VirtualBox:~$
velvet orioleBOT
#

Good — rollback installed correctly:

OpenClaw 2026.4.23

Now you’re hitting the newer-config guard because 2026.4.24 last wrote the config. Since this is an intentional rollback, run the service commands with the one-shot override:

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway install --force
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart
openclaw gateway status --deep
openclaw health --timeout 30000 --verbose

The plugins.entries.bonjour warning is probably harmless/stale config for now.

#

Nice, the service reinstall + restart actually went through. Now check whether it’s alive:

openclaw gateway status --deep
openclaw health --timeout 30000 --verbose

If those are OK, reopen Control UI with:

openclaw dashboard

The newer-config warning can stay for now; we only care whether 2026.4.23 is stable again.

#

Rollback worked, but the gateway is still listening without answering RPC. Let’s isolate it from systemd + Firefox so the real error shows plainly.

  1. Close all Control UI / 127.0.0.1:18789 browser tabs.

  2. In terminal, run the gateway in the foreground:

openclaw gateway stop
sleep 2
ss -ltnp | grep 18789 || true
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway --port 18789

Leave that running for ~30 seconds. If it prints an error, paste the last ~40 lines.

If it just sits there, open a second terminal and run:

#
openclaw health --timeout 30000 --verbose

This will tell us whether systemd is the issue, or the gateway itself is wedged.

barren crown
#

◇ Config warnings ────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.bonjour: plugin not found: bonjour (stale config │
│ entry ignored; remove it from plugins config) │
│ │
├──────────────────────────────────────────────────────────────────────╯


15:03:45 [gateway] loading configuration…
15:03:45 Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
15:03:45 Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
15:03:45 [gateway] resolving authentication…
15:03:45 [gateway] starting...
15:03:48 Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
15:03:49 [gateway] starting HTTP server...
15:03:49 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/test/.openclaw/canvas)
15:03:49 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
15:03:49 [gateway] agent model: openai/gpt-5.5
15:03:49 [gateway] ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 4.0s)
15:03:49 [gateway] log file: /tmp/openclaw/openclaw-2026-04-27.log
15:03:49 [gateway] security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.
15:03:49 [heartbeat] started
15:03:49 [gateway] starting channels and sidecars...
15:03:50 [plugins] embedded acpx runtime backend registered (cwd: /home/test/.openclaw/workspace)
15:03:50 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
15:04:06 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=test-VirtualBox (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
15:04:06 [plugins] embedded acpx runtime backend ready

velvet orioleBOT
#

That log is actually good news: foreground gateway starts cleanly.

Key line:

[gateway] ready ... 

So keep that terminal open — if you close it, this manual gateway stops.

Now open a second terminal and run:

openclaw health --timeout 30000 --verbose

If that works, the gateway itself is okay and the remaining problem is the systemd service / startup path.

#

Also: I see this:

[gateway] agent model: openai/gpt-5.5

Earlier your auth showed OpenRouter, not OpenAI. So after health is fixed, chat may still hang until the default model is changed to one you actually have auth for. First paste the health result.

barren crown
#

test@test-VirtualBox:~$ openclaw health --timeout 30000 --verbose
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.

🦞 OpenClaw 2026.4.23 (a979721)
I'm the reason your shell history looks like a hacker-movie montage.

Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.


Gateway connection:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/test/.openclaw/openclaw.json
Bind: loopback
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/test/.openclaw/agents/main/sessions/sessions.json (1 entries)

  • agent:main:main (18m ago)
velvet orioleBOT
#

Great — manual foreground gateway is healthy/reachable. So the gateway itself is not dead now.

Two things next:

  1. Keep the foreground gateway terminal open for now.
  2. In Control UI, reload http://127.0.0.1:18789/ and try a tiny hi.

If the chat still hangs, the likely next issue is your model mismatch:

gateway model: openai/gpt-5.5
models status showed OpenRouter auth

Run:

#
openclaw models status

If you don’t have OpenAI auth, change the default model to an OpenRouter model you actually use, or add OpenAI auth. Don’t paste API keys.

barren crown
#

needgateway token

velvet orioleBOT
#

Run this in the second terminal:

openclaw dashboard --no-open

If it prints a URL with:

#token=...

copy/open that whole URL in Firefox. Don’t paste the token here.

If it only prints a plain URL and Control still asks for a token, then generate a fresh one:

#
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw doctor --generate-gateway-token

Then stop/restart the foreground gateway so it picks it up:

# in the gateway terminal: Ctrl+C
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway --port 18789

Then run again:

openclaw dashboard --no-open
barren crown
#

too mynay tries again

velvet orioleBOT
#

Yep — that means the browser is still retrying bad auth and tripping the limiter again.

Do this exactly:

  1. Close every OpenClaw/Control UI tab in Firefox:

    • 127.0.0.1:18789
    • localhost:18789
  2. In the foreground gateway terminal, press:

Ctrl+C
  1. Start it again:
#
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway --port 18789
  1. In a second terminal:
openclaw dashboard --no-open
  1. Open the exact full URL it prints, ideally in a private Firefox window.

If you don’t restart the gateway, wait ~5 minutes for the auth limiter to expire — but restarting is faster. Don’t refresh old tabs; they’ll re-trigger the lockout.

barren crown
#

im in what do i do now

velvet orioleBOT
#

Nice. Now test the actual assistant path:

  1. In Control UI chat, send:
hi
  1. If it replies, great — next we fix the service so you don’t need the foreground terminal:
# leave foreground gateway running for now
openclaw models status
  1. If hi hangs, paste the model status output — earlier it looked like your default was openai/gpt-5.5 but your auth was OpenRouter, which would make chat hang/fail.
#

Don’t close the foreground gateway terminal yet.

barren crown
#

it runs so i now run this?
openclaw models status

velvet orioleBOT
#

Yes — run:

openclaw models status

If chat replied successfully, the model is probably okay, but models status will confirm.

After that, we’ll fix the systemd service path so you don’t have to keep the foreground gateway terminal open.

barren crown
#

test@test-VirtualBox:~$ openclaw models status
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.

🦞 OpenClaw 2026.4.23 (a979721) — Ah, the fruit tree company! 🍎

Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
    Config : ~/.openclaw/openclaw.json
    Agent dir : ~/.openclaw/agents/main/agent
    Default : openai/gpt-5.5
    Fallbacks (0) : -
    Image model : -
    Image fallbacks (0): -
    Aliases (0) : -
    Configured models (0): all

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

  • openrouter effective=models.json:sk-or-v1...77d5f2a0 | models.json=sk-or-v1...77d5f2a0 | source=models.json: ~/.openclaw/agents/main/agent/models.json

Missing auth

  • openai Run openclaw models auth login --provider openai, openclaw configure, or set an API key env var.

OAuth/token status

  • none
    test@test-VirtualBox:~$
velvet orioleBOT
#

Yep, that’s the next problem:

Default: openai/gpt-5.5
Missing auth: openai
OpenRouter auth exists

So chat may hang/fail because it’s trying OpenAI without OpenAI auth.

Run:

openclaw models list --provider openrouter --plain | head -50

Pick one exact model from that list, then set it:

#
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw models set <provider/model>

Example shape only:

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw models set openrouter/some/model-id

Then restart the foreground gateway: Ctrl+C, then:

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway --port 18789

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

barren crown
#

test@test-VirtualBox:~$ openclaw models list --provider openrouter --plain | head -50
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
    Config was last written by a newer OpenClaw (2026.4.24); current version is 2026.4.23.
    No models found.
    test@test-VirtualBox:~$
velvet orioleBOT
#

That’s okay — models list only shows configured catalog entries, and yours has none. Since you already have an OpenRouter key, use OpenRouter’s auto route:

OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw models set openrouter/auto
openclaw models status

Then restart the foreground gateway:

Ctrl+C
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway --port 18789
barren crown
#

it works now, can i try tui now?

velvet orioleBOT
#

Yes — go for it. Since your gateway is currently running in the foreground, open a second terminal and run:

openclaw tui --local

If that complains about auth/URL, try:

openclaw tui --url ws://127.0.0.1:18789

But first choice is --local.

After you’re done testing, we should come back and fix the systemd service so you don’t need the foreground gateway terminal.

barren crown
#

test@test-VirtualBox:~$ openclaw tui --local
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config warnings:
  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)

🦞 OpenClaw 2026.4.23 (a979721)
The only open-source project where the mascot could eat the competition.


◇ Config warnings ────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.bonjour: plugin not found: bonjour (stale config │
│ entry ignored; remove it from plugins config) │
│ │
├──────────────────────────────────────────────────────────────────────╯
openclaw tui - local embedded - agent main (Research Assistant) - session main

session agent:main:main

it omes up with this then replicates the consol's responses

velvet orioleBOT
#

That means --local started an embedded local gateway/session, not the foreground gateway you already have. That’s why it feels like it’s echoing/duplicating console behavior.

Exit the TUI (Ctrl+C or q if it responds), then connect it to the running gateway instead:

openclaw tui --url ws://127.0.0.1:18789

If it asks for auth, use:

openclaw dashboard --no-open

and copy the token from the #token=... URL, then run:

#
openclaw tui --url ws://127.0.0.1:18789 --token 'PASTE_TOKEN_HERE'

Don’t paste the token in Discord.

barren crown
#

do i not worry about the bonjour not installed?

velvet orioleBOT
#

No, don’t worry about Bonjour right now. That warning says:

plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored)

So it’s being ignored, not blocking the gateway/chat. Bonjour is just local network discovery/advertising; your local 127.0.0.1:18789 setup doesn’t need it.

Once everything is stable, you can clean that stale config entry later. For now I’d leave it alone and focus on:

  1. Gateway works on 2026.4.23
  2. Model is now OpenRouter
  3. TUI connects via --url ws://127.0.0.1:18789 rather than --local
barren crown
#

test@test-VirtualBox:~$ openclaw tui --url ws://127.0.0.1:18789
Config warnings:

  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)
    Config warnings:
  • plugins.entries.bonjour: plugin not found: bonjour (stale config entry ignored; remove it from plugins config)

🦞 OpenClaw 2026.4.23 (a979721) — Hot reload for config, cold sweat for deploys.


◇ Config warnings ────────────────────────────────────────────────────╮
│ │
│ - plugins.entries.bonjour: plugin not found: bonjour (stale config │
│ entry ignored; remove it from plugins config) │
│ │
├──────────────────────────────────────────────────────────────────────╯
Error: gateway url override requires explicit credentials
Fix: pass --token or --password when using --url.

velvet orioleBOT
#

Yep, expected — --url requires explicit auth.

Run:

openclaw dashboard --no-open

If it prints something like:

http://127.0.0.1:18789/#token=abc123...

copy only the part after #token= and run:

#
openclaw tui --url ws://127.0.0.1:18789 --token 'PASTE_TOKEN_HERE'

Don’t paste the token here.

If dashboard --no-open does not show #token=..., tell me what it prints, but redact any secret-looking value.

barren crown
#

ok it works

velvet orioleBOT
#

Awesome 🎉

Current stable state:

  • Rolled back to 2026.4.23
  • Gateway works in foreground
  • Control UI works
  • TUI works with --url ... --token ...
  • Model fixed to OpenRouter
  • Bonjour warning is harmless for now

One remaining cleanup later: fix systemd so the gateway can run in the background again. For now, keep the foreground gateway terminal open while using it.

barren crown
#

can you do cleanup now?

velvet orioleBOT
#

Yep — cleanup order:

  1. Stop the foreground gateway
    In the terminal where openclaw gateway --port 18789 is running, press:
Ctrl+C
  1. Clean the stale Bonjour entry + refresh config version stamp
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw config unset plugins.entries.bonjour
openclaw config validate
  1. Run gateway as systemd again
#
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway install --force
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart
sleep 5
openclaw gateway status --deep
openclaw health --timeout 30000 --verbose

If status shows Connectivity probe: ok, you’re cleaned up and can use OpenClaw without the foreground terminal.

barren crown
#

so is it truely fixed now?

velvet orioleBOT
#

Almost — it’s functionally fixed while the foreground gateway is running.

It’s truly fixed only after this passes under systemd:

openclaw gateway status --deep
openclaw health --timeout 30000 --verbose

You want to see:

Connectivity probe: ok

or health output without timeout.

#

If you already did the cleanup/systemd restart and those pass, then yes: fixed. If not, you’re currently in “working workaround” mode.

barren crown
#

🦞 OpenClaw 2026.4.23 (a979721)
I run on caffeine, JSON5, and the audacity of "it worked on my machine."

Installed systemd service: /home/test/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /home/test/.config/systemd/user/openclaw-gateway.service.bak

🦞 OpenClaw 2026.4.23 (a979721)
Powered by open source, sustained by spite and good documentation.

Restarted systemd service: openclaw-gateway.service

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



Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/test/.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 30699, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

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

🦞 OpenClaw 2026.4.23 (a979721)
I read logs so you can keep pretending you don't have to.



Gateway connection:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/test/.openclaw/openclaw.json
Bind: loopback
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/test/.openclaw/agents/main/sessions/sessions.json (1 entries)

  • agent:main:main (2m ago)
    test@test-VirtualBox:~$
velvet orioleBOT
#

Yes — now it’s truly fixed

The key line is:

Connectivity probe: ok
Capability: admin-capable

You’re back to a healthy systemd gateway on 2026.4.23.

Final state:

  • Gateway service installed + restarted
  • Port listening
  • RPC probe OK
  • Health works
  • Model moved off broken OpenAI auth path
barren crown
#

i noticed memories and other works are not there

velvet orioleBOT
#

It shouldn’t have been deleted. The rollback/reinstall touches the OpenClaw code install, not your ~/.openclaw state/workspace.

Most likely you’re looking at a different workspace/session/agent now.

Run these and paste only the output paths/counts, not memory contents:

openclaw config get agents.defaults.workspace
find ~/.openclaw -maxdepth 5 \( -name MEMORY.md -o -path "*/memory/*.md" -o -name sessions.json \) -print
ls -la ~/.openclaw/workspace | head -50

Also check the Control UI session picker — if you’re in a fresh main session, old “work” may be in another session rather than gone.

barren crown
#

est@test-VirtualBox:~$ openclaw config get agents.defaults.workspace
find ~/.openclaw -maxdepth 5 ( -name MEMORY.md -o -path "/memory/.md" -o -name sessions.json ) -print
ls -la ~/.openclaw/workspace | head -50

🦞 OpenClaw 2026.4.23 (a979721)
Your .env is showing; don't worry, I'll pretend I didn't see it.

Config path not found: agents.defaults.workspace
/home/test/.openclaw/agents/research-assistant/sessions/sessions.json
/home/test/.openclaw/agents/main/sessions/sessions.json
total 52
drwxrwxr-x 5 test test 4096 Apr 26 14:18 .
drwx------ 15 test test 4096 Apr 27 15:21 ..
-rw-rw-r-- 1 test test 7850 Apr 26 14:09 AGENTS.md
-rw-rw-r-- 1 test test 1531 Apr 26 14:09 BOOTSTRAP.md
drwxrwxr-x 7 test test 4096 Apr 26 14:09 .git
-rw-rw-r-- 1 test test 226 Apr 26 14:09 HEARTBEAT.md
-rw-rw-r-- 1 test test 696 Apr 26 14:09 IDENTITY.md
drwxrwxr-x 2 test test 4096 Apr 26 14:09 .openclaw
-rw-rw-r-- 1 test test 1806 Apr 26 14:09 SOUL.md
drwxrwxr-x 2 test test 4096 Apr 26 14:18 state
-rw-rw-r-- 1 test test 920 Apr 26 14:09 TOOLS.md
-rw-rw-r-- 1 test test 537 Apr 26 14:09 USER.md
test@test-VirtualBox:~$

velvet orioleBOT
#

It doesn’t look deleted — but your check shows no MEMORY.md / memory/*.md in the default workspace, only session stores:

~/.openclaw/agents/research-assistant/sessions/sessions.json
~/.openclaw/agents/main/sessions/sessions.json

So likely your old work is in the research-assistant session/agent, not the current session.

Run:

openclaw sessions --all-agents
openclaw sessions --store ~/.openclaw/agents/research-assistant/sessions/sessions.json

Also search for memory files elsewhere:

#
find ~ -maxdepth 6 \( -name MEMORY.md -o -path "*/memory/*.md" \) -not -path "*/node_modules/*" -print

One more thing: you still have BOOTSTRAP.md in the workspace. If the agent keeps acting like first-run/bootstrap, rename it later:

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

But first check the sessions above.

barren crown
#

test@test-VirtualBox:~$ openclaw sessions --all-agents
openclaw sessions --store ~/.openclaw/agents/research-assistant/sessions/sessions.json

🦞 OpenClaw 2026.4.23 (a979721)
iMessage green bubble energy, but for everyone.

Session stores: 1 (main)
Sessions listed: 1
Agent Kind Key Age Model Tokens (ctx %) Flags
main direct agent:main:main 5m ago gemini-3-flash-preview 7.2k/1049k (1%) system id:98ec73a5-a3b5-4af7-b05a-a6f6ea9d8c24

🦞 OpenClaw 2026.4.23 (a979721) — You had me at 'openclaw gateway start.'

Session store: /home/test/.openclaw/agents/research-assistant/sessions/sessions.json
Sessions listed: 1
Kind Key Age Model Tokens (ctx %) Flags
direct agent:research-a...t:main 3h ago gemini-3-flash-preview 6.6k/1049k (1%) system id:e4eb96ed-209a-43c1-a347-c1ff12690207
test@test-VirtualBox:~$ find ~ -maxdepth 6 ( -name MEMORY.md -o -path "/memory/.md" ) -not -path "/node_modules/" -print

velvet orioleBOT
#

Good news/bad news:

  • Sessions still exist: main and research-assistant
  • Memory markdown files don’t exist anywhere under ~ from that search

So the “old work” is probably in the research-assistant transcript, not memory files.

To open/use that session directly:

openclaw tui --url ws://127.0.0.1:18789 --token 'YOUR_TOKEN' --session agent:research-assistant:main

Or in Control UI, switch sessions/agent to research-assistant if it appears.

For future durable memory, you need to tell it explicitly “write this to memory”, or create a MEMORY.md. Also: if the leftover bootstrap file is confusing things, I’d rename it:

#
mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done
openclaw gateway restart

That won’t restore memory, but it avoids first-run bootstrap weirdness.

barren crown
#

so all memory are inaccessible unless i explicitly tell it to acces it

velvet orioleBOT
#

Not exactly.

There are two different things:

  1. Session history / transcript
    This is accessible when you switch back to that session, e.g. agent:research-assistant:main. That’s where your old work likely is.

  2. Durable memory files (MEMORY.md, memory/*.md)
    Your search found none, so there isn’t a memory-file archive for it to automatically load/search right now.

So it’s not “memory is inaccessible” — it’s more like the work was saved as session history, not durable memory.

For future:

  • Tell it: “write this to memory” for durable notes.
  • Or maintain ~/.openclaw/workspace/MEMORY.md.
  • To resume old work, switch to the old session/agent rather than expecting it in the new main session.
barren crown
#

so now its basically like a new install of openclaw instead of continue from my old openclaw

velvet orioleBOT
#

Not quite — it’s not a new install. Your state is still there:

  • Config: still in ~/.openclaw/openclaw.json
  • Sessions: still in ~/.openclaw/agents/.../sessions/
  • Old research-assistant session: still exists
  • Workspace files: still in ~/.openclaw/workspace

What’s different is you’re currently in the main/default session, which feels fresh. Your previous work appears to be in:

agent:research-assistant:main

So to “continue old OpenClaw,” switch to that session/agent.

Try:

#
openclaw tui --url ws://127.0.0.1:18789 --token 'YOUR_TOKEN' --session agent:research-assistant:main

If you want that to become the default again, we can inspect your agents/bindings next.

barren crown
#

how can i restore everything back to its original state while keeping the fix

velvet orioleBOT
#

Yes — but don’t restore by upgrading back to 2026.4.24. The safe goal is:

  • keep OpenClaw 2026.4.23
  • keep systemd gateway fixed
  • keep OpenRouter model fix
  • restore your old agent/session routing so it feels like before

First, run these read-only checks:

openclaw agents list --bindings
openclaw config get agents.list --json
ls -la ~/.openclaw/agents/research-assistant

Paste that output.

#

Most likely we just need to re-add/reselect research-assistant as a configured agent/default, because its session store still exists:

~/.openclaw/agents/research-assistant/sessions/sessions.json

Do not delete/reinstall anything now. We’re past the scary part. The next step is just reconnecting your old agent/session state cleanly.

barren crown
#

test@test-VirtualBox:~$ openclaw agents list --bindings
openclaw config get agents.list --json
ls -la ~/.openclaw/agents/research-assistant

🦞 OpenClaw 2026.4.23 (a979721)
I don't judge, but your missing API keys are absolutely judging you.

Agents:

  • main (default) (Research Assistant)
    Workspace: ~/.openclaw/workspace
    Agent dir: ~/.openclaw/agents/research-assistant/agent
    Model: openrouter/google/gemini-3-flash-preview
    Routing rules: 0
    Routing: default (no explicit rules)
    Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
    Channel status reflects local config/creds. For live health: openclaw channels status --probe.
    [
    {
    "id": "main",
    "default": true,
    "name": "Research Assistant",
    "workspace": "/home/test/.openclaw/workspace",
    "agentDir": "/home/test/.openclaw/agents/research-assistant/agent",
    "model": "openrouter/google/gemini-3-flash-preview"
    }
    ]
    total 16
    drwxrwxr-x 4 test test 4096 Apr 27 12:12 .
    drwx------ 4 test test 4096 Apr 26 20:12 ..
    drwx------ 2 test test 4096 Apr 27 12:12 agent
    drwxrwxr-x 2 test test 4096 Apr 27 12:24 sessions
velvet orioleBOT
#

This is actually already restored pretty well.

Your configured agent is:

id: main
name: Research Assistant
agentDir: ~/.openclaw/agents/research-assistant/agent
model: openrouter/google/gemini-3-flash-preview

So the old agent brain/auth is connected. The confusing part is there are two session stores:

  • active configured store: ~/.openclaw/agents/research-assistant/sessions
  • leftover/old default store: ~/.openclaw/agents/main/sessions

To continue the old Research Assistant session, use normal main now:

#
openclaw tui --url ws://127.0.0.1:18789 --token 'YOUR_TOKEN' --session main

Do not use agent:research-assistant:main anymore, because your configured agent id is main; only the directory is named research-assistant.

If you want, the only cleanup I’d do is leave ~/.openclaw/agents/main/sessions alone for a few days as backup, then archive/delete later once you’re sure.

barren crown
#

replace my toke with the token of openclaw cnboard?

velvet orioleBOT
#

Yes — use the gateway token from openclaw dashboard --no-open.

Run:

openclaw dashboard --no-open

If it prints:

http://127.0.0.1:18789/#token=abc123...

then use the part after #token= here:

#
openclaw tui --url ws://127.0.0.1:18789 --token 'abc123...' --session main

Don’t paste the token in Discord.

barren crown
#

done. so its finally finished?