#Shit keep hanging and ghosting me.
1 messages · Page 1 of 1 (latest)
newver have i ever in my life seen so many diferent alterations of the openclaw banner
disable the bonjour plugin from the command line
see if that get you back up and running, worked for me and others this morning.
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
openclaw status --all
and the last crash bit from:
openclaw logs --follow
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.
last touched version command not found
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
Fallback for the version stamp:
grep -n "lastTouchedVersion" ~/.openclaw/openclaw.json
Don’t paste the whole config file, just that grep line if it exists.
Docs: https://docs.openclaw.ai/gateway/troubleshooting
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
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:
- You’re opening it from outside the VM — it’s bound to loopback inside VirtualBox, so your host/phone can’t reach it.
- 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.
Error: Agent "main" no longer exists in configuration
from the onboard openclaw control
wow it work openclaw plugins disable bonjour
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
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.
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
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>
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.
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:~$
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.
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'
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.
openclaw tui hung
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
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
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.
where is the config set output
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=$?"
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:~$
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.
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]]]]
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.
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"}
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.
by scrolling, does it stop or indicated bygeting user prompot back
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.
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
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.
...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.
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. 🎉
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:~$
Beautiful — gateway is healthy now 🎉
Connectivity probe: ok
Capability: admin-capable
So the main fixes were:
- restored the expected
mainagent inagents.list - moved aside the wedged
plugin-runtime-depscache and let it rebuild - 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.
can i run tui
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.
test@test-VirtualBox:~$ openclaw tui
🦞 OpenClaw 2026.4.24 (cbcfdf6)
Powered by open source, sustained by spite and good documentation.
still taking long time
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.
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
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
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
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.
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
─────────────────────────────────────────────────────────────────────────────
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.
is token chars: the token number?
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.
value is two letter
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.
openclaw doctor command prompted to isntall bundle plugin runtime deps again
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.
prompts to archive orphan trascript
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.
test@test-VirtualBox:~$ echo "token chars: ${#TOKEN}
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
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 ?
────────────────────────────────────────────────────────────────────────────────
────────────
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.
does it retain memory and configs?
Yes — the fixes we did should retain your config, workspace, creds, and files.
What changed:
- ✅
~/.openclaw/openclaw.jsonwas backed up first. - ✅
agents.listwas changed so your agent is calledmainagain. - ✅ 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.
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 ?
────────────────────────────────────────────────────────────────────────────────
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.
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"}
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'
taking long time to connect
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'
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
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.
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
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.
token equals openclaw reacted?
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.
unauthorized: too many failed authentication attempts (retry later)
That’s the browser auth lockout from the failed token attempts. Stop trying to connect for a bit or it keeps resetting.
Do this:
- Close the Control UI tab.
- Wait 5 minutes.
- 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.
disconnected (1006): no reason
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.
openclaw contorl opened after running gateway health
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
do i not go and change firefox's token to match in previous instructions?
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.
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
Those lines don’t show the gateway killing itself — they show Control UI successfully connecting:
webchat connected ... v2026.4.24commands.list,chat.history,models.list,node.listall returned ✓- The
closed before connect ... code=1006line 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.
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:~$
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.
where is the first error block
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.
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:~$
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.
wait what am i pasting? there is too big of a response from bnoth
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.
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"}
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:
- Close all Control UI /
127.0.0.1:18789Firefox tabs.
- Restart gateway to clear the in-memory auth limiter:
openclaw gateway restart
- Reopen Control UI.
- 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.
tokes redacted
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.
onboards opened, now what
Good — that means you’re back in the browser flow.
Do this:
- Close any old
127.0.0.1:18789tabs first. - In the onboarding page, choose/connect to the local gateway:
http://127.0.0.1:18789 - If it asks for auth, use Gateway Token — not password.
- 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.
by old, you mean all or retain the current one
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.
i dont get what you want, i am in contro openclaw chat right now
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.
in the terminal or in control
Both, but in this order:
-
Terminal: run
openclaw health --verbose -
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.
ui chat is loading for a long time
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.
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.
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.
◇
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
Runopenclaw doctorfor 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)
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.
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.
it is infact not small
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.
whole thing over wordrestriction by 5k
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
cant upload files
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
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'
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
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
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.
i ran the steps before and including health timeoput
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.
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
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.
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:~$
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.
Docs for that guard: https://docs.openclaw.ai/gateway/troubleshooting
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.
-
Close all Control UI /
127.0.0.1:18789browser tabs. -
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.
◇ 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
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.
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)
Great — manual foreground gateway is healthy/reachable. So the gateway itself is not dead now.
Two things next:
- Keep the foreground gateway terminal open for now.
- In Control UI, reload
http://127.0.0.1:18789/and try a tinyhi.
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.
needgateway token
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
too mynay tries again
Yep — that means the browser is still retrying bad auth and tripping the limiter again.
Do this exactly:
-
Close every OpenClaw/Control UI tab in Firefox:
127.0.0.1:18789localhost:18789
-
In the foreground gateway terminal, press:
Ctrl+C
- Start it again:
OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway --port 18789
- In a second terminal:
openclaw dashboard --no-open
- 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.
im in what do i do now
Nice. Now test the actual assistant path:
- In Control UI chat, send:
hi
- 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
- If
hihangs, paste the model status output — earlier it looked like your default wasopenai/gpt-5.5but your auth was OpenRouter, which would make chat hang/fail.
Don’t close the foreground gateway terminal yet.
it runs so i now run this?
openclaw models status
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.
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:~$
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
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:~$
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
Then try hi in Control UI again.
it works now, can i try tui now?
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.
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
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.
do i not worry about the bonjour not installed?
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:
- Gateway works on
2026.4.23 - Model is now OpenRouter
- TUI connects via
--url ws://127.0.0.1:18789rather than--local
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.
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.
ok it works
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.
can you do cleanup now?
Yep — cleanup order:
- Stop the foreground gateway
In the terminal whereopenclaw gateway --port 18789is running, press:
Ctrl+C
- 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
- 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.
so is it truely fixed now?
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.
🦞 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:~$
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
- Bonjour warning cleaned/ignored
Please don’t update back to 2026.4.24 for now. If you can, file a GitHub issue with the missing dist/* / ERR_MODULE_NOT_FOUND logs: https://github.com/openclaw/openclaw/issues
i noticed memories and other works are not there
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.
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:~$
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.
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
Good news/bad news:
- Sessions still exist:
mainandresearch-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.
so all memory are inaccessible unless i explicitly tell it to acces it
Not exactly.
There are two different things:
-
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. -
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
mainsession.
so now its basically like a new install of openclaw instead of continue from my old openclaw
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-assistantsession: 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.
how can i restore everything back to its original state while keeping the fix
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.
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
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.
replace my toke with the token of openclaw cnboard?
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.
done. so its finally finished?