Help | Friends of the Crustacean 🦞🤝 | Page 1

hybrid locust Apr 16, 2026, 6:01 PM

#

I have a problem with openclaw onboard install daemon

lofty adderBOT Apr 16, 2026, 6:01 PM

#

ruby groveBOT Apr 16, 2026, 6:02 PM

#

Let me check the FAQ first so I don't make up flags/steps.

#

Can you paste these so I can narrow it down fast?

openclaw --version
openclaw onboard --install-daemon
openclaw gateway status
openclaw status --all

Also tell me:

your OS: macOS, Linux, WSL, or Windows
the exact error message from the daemon install step

A couple quick checks first:

the supported command is openclaw onboard --install-daemon
Node needs to be >= 22
use pnpm/Node for the gateway, not Bun

#

Docs:

Paste the output here and I’ll help you sort it out.

hybrid locust Apr 16, 2026, 6:05 PM

#

Im on the openclaw onboard --install-daemon and in the section of select channel after I select one of the options it gave me an error
Error is : uTypeError: Cannot read properties of undefined (reading 'trim')
u

ruby groveBOT Apr 16, 2026, 6:06 PM

#

I’m checking whether that exact trim crash is already known, because if it is there may be a clean workaround instead of guesswork.

#

That looks like a real OpenClaw bug, not something you did. I found a matching fix in the repo for:

fix(onboard): crash at channel selection on globally installed CLI

Can you paste this first so I can tell you whether the fix should already be in your build?

openclaw --version

Best options right now:

Fast workaround, recommended
Finish onboarding without channel setup:
```
openclaw onboard --install-daemon --skip-channels
```

#

Then configure channels after:

openclaw configure --section channels

Proper fix
Update OpenClaw, then retry:
```
openclaw update
```
If the bug still happens and you are okay testing the newest code:
```
openclaw update --tag main
```

Docs:

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

#

https://docs.openclaw.ai/start/wizard

Paste your openclaw --version output and I’ll tell you which path I’d take.

hybrid locust Apr 16, 2026, 6:08 PM

#

Openclaw 2026.4.14 (323493f)

ruby groveBOT Apr 16, 2026, 6:09 PM

#

Yep, that lines up. 2026.4.14 is older than the fix for this exact channel-selection crash.

I’d do this first:

openclaw update
openclaw onboard --install-daemon

If you want the fastest unblock right now, skip channels during onboarding, then add them after:

openclaw onboard --install-daemon --skip-channels
openclaw configure --section channels

If plain openclaw update still leaves you on a build that crashes, then try the newer code path:

#

openclaw update --tag main

Docs:

You don’t need to start from scratch. Update first, then retry. If you want, paste what openclaw update says and I’ll sanity-check it.

hybrid locust Apr 16, 2026, 6:44 PM

#

It's okay now but it say the gateway not detected gateway closed 1006

ruby groveBOT Apr 16, 2026, 6:45 PM

#

Let me check the docs for that specific 1006 gateway close so I can point you at the right thing instead of guessing.

#

Nice, at least the onboarding crash is gone.

gateway closed (1006) is usually a generic disconnect, not the same as auth/pairing errors like 1008. In practice it often means the gateway is not running, crashed, or the client is pointing at the wrong URL/port.

Try this first:

openclaw gateway restart
openclaw gateway status
openclaw gateway probe

If it still says 1006, paste these:

openclaw status --all

#

openclaw gateway status
openclaw doctor
openclaw logs --follow

Also tell me your OS, macOS, Linux, WSL, or Windows.

What I’m looking for:

Runtime: running
RPC probe: ok

If those are missing, the gateway itself is the problem. If they look good, then it is probably a connection target/auth issue.

Docs:

#

Paste the output here and I’ll help you read it.

hybrid locust Apr 16, 2026, 6:45 PM

#

I'm using Kali Linux

ruby groveBOT Apr 16, 2026, 6:46 PM

#

Kali helps, thanks. I’m checking the Linux daemon docs so I can give you the exact service checks, especially since daemon issues there are often systemd user-service related.

#

That helps. On Kali, onboarding installs a systemd user service, so gateway closed (1006) often means the gateway service is not actually running, or the user session/linger setup is off.

Please run these and paste the output:

openclaw gateway status --deep
systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service -n 50 --no-pager

If you are on SSH or a headless session, also run this once:

sudo loginctl enable-linger "$(whoami)"
systemctl --user restart openclaw-gateway.service

#

Then check again:

openclaw gateway status

One important clue:

if systemctl --user says Failed to connect to bus, tell me that exact message, because that points to a Linux session/systemd issue.

Docs:

Paste the outputs and I’ll help decode them.

hybrid locust Apr 16, 2026, 6:57 PM

#

I tried to send the output but the server said it's spam

ruby groveBOT Apr 16, 2026, 6:57 PM

#

Yeah, Discord does that sometimes. No worries.

Send just these short outputs, or a screenshot of them:

openclaw gateway status
systemctl --user is-active openclaw-gateway.service
systemctl --user is-enabled openclaw-gateway.service

If one of those looks wrong, send only the last few lines:

systemctl --user status openclaw-gateway.service --no-pager | tail -n 10
journalctl --user -u openclaw-gateway.service -n 10 --no-pager

#

If you see this, paste just that single line:

Failed to connect to bus

A screenshot is totally fine too.

hybrid locust Apr 16, 2026, 6:59 PM

#

🦞 OpenClaw 2026.4.14 (323493f) — 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-16.log
Command: /usr/bin/node /usr/local/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 136554, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

ruby groveBOT Apr 16, 2026, 7:00 PM

#

This output actually looks good.

The important bits are:

Runtime: running
RPC probe: ok

So the daemon is working. I’m glad we checked that.

The key line is this:

Loopback-only gateway; only local clients can connect.

That means only the same Kali machine can reach it at:

http://127.0.0.1:18789/

#

So:

If you are opening it on the same Kali machine
- open http://127.0.0.1:18789/ directly, or run:
```
openclaw dashboard
```
If you are trying from another device / browser / VM
- it will fail, because the gateway is bound to 127.0.0.1 only.

At this point, the 1006 is probably a client-side disconnect, not a broken daemon.

Can you tell me where you see the 1006 now?

in the onboarding terminal
in a browser on Kali
or from another device

#

Docs:

hybrid locust Apr 16, 2026, 7:01 PM

#

At first after the installation Health Check failed : gateway closed (1006):

ruby groveBOT Apr 16, 2026, 7:02 PM

#

Got it. I’m checking whether that specific post-install health check failure is a known transient in onboarding, since your gateway is clearly healthy now.

#

Ah, that makes sense.

Since your current status shows:

Runtime: running
RPC probe: ok

the install itself looks successful now. So that earlier:

Health Check failed: gateway closed (1006)

was probably a transient startup timing issue during onboarding, not a broken daemon.

I’d do this now:

#

openclaw health
openclaw status

If those work, you’re basically good to continue. Then open the dashboard locally on Kali:

openclaw dashboard

or open:

http://127.0.0.1:18789/

#

I’d also update when you get a chance, since 2026.4.14 already hit one onboarding bug for you:

openclaw update

If openclaw health fails, paste just that short output.

Docs:

hybrid locust Apr 16, 2026, 7:16 PM

#

Everything is good now but when I go into configure the channels after sent the token it still show the trim error

ruby groveBOT Apr 16, 2026, 7:17 PM

#

I’m going to check whether the same channel metadata bug also affects openclaw configure, because that would explain why onboarding is fine now but channel setup still crashes.

#

Yep, that tracks.

openclaw configure reuses the same channel setup path, and your version, 2026.4.14, is older than the fixes for this metadata/trim crash.

So this is very likely the same upstream bug, just showing up in configure instead of onboarding.

I’d do this next:

openclaw update
openclaw --version
openclaw configure --section channels

If the normal update still leaves you with the same trim error, grab the newer fix directly:

#

openclaw update --tag main
openclaw --version
openclaw configure --section channels

You probably do not need to reinstall from scratch.

Docs:

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

If you want, paste just the new openclaw --version after updating and I’ll sanity-check it.

hybrid locust Apr 16, 2026, 7:36 PM

#

OpenClaw 2026.4.14 (323493f)

ruby groveBOT Apr 16, 2026, 7:37 PM

#

Yep, you’re still on the same build, so the fix has not landed on your machine yet.

Next step:

openclaw update --tag main
openclaw --version
openclaw configure --section channels

If that works, great.
If openclaw update --tag main fails, paste just that short output here.

Docs:

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

hybrid locust Apr 16, 2026, 7:39 PM

#

Updating OpenClaw...

│
◇ ✗ Updating via package manager (197.22s)
npm ERR! npm ERR! path /usr/local/lib/node_modules/openclaw
npm ERR! npm ERR! dest /usr/local/lib/node_modules/.openclaw-aijmTbnc
npm ERR! npm ERR! errno -39
npm ERR! npm ERR! ENOTEMPTY: directory not empty, rename '/usr/local/lib/node_modules/openclaw' -> '/usr/local/lib/node_modules/.openclaw-aijmTbnc'
npm ERR!
npm ERR! npm ERR! A complete log of this run can be found in:
npm ERR! npm ERR! /root/.npm/_logs/2026-04-16T19_37_28_859Z-debug-0.log
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2026-04-16T19_34_31_010Z-debug-0.log
│
◇ ✓ Running doctor checks (30.52s)

Update Result: ERROR
Root: /usr/local/lib/node_modules/openclaw
Reason: global update
Before: 2026.4.14
After: 2026.4.14

Total time: 230.82s
u

ruby groveBOT Apr 16, 2026, 7:39 PM

#

I’m checking the docs for the safest recovery path here, because this looks like the update itself failed, not OpenClaw specifically.

#

That helps. This part is npm failing to replace the global package, not the OpenClaw config itself.

ENOTEMPTY ... rename '/usr/local/lib/node_modules/openclaw'

So I’d try the documented fallback first:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
openclaw --version

If that still leaves you on 2026.4.14, do a manual global reinstall:

npm uninstall -g openclaw
npm i -g openclaw@latest

#

openclaw --version

Then retry:

openclaw configure --section channels

Your config should still live in ~/.openclaw, so this is about replacing the CLI install, not wiping your setup.

Docs:

If you want, paste just the new openclaw --version after that.

opaque adder Apr 16, 2026, 8:14 PM

#

I think 2026.4.14 is the latest version

ruby groveBOT Apr 16, 2026, 8:15 PM

#

Yep, that may be true for stable/latest.

The important distinction here is:

2026.4.14 can still be the latest stable
the trim fix can exist after that on main, but not be released to stable yet

So for Santiago’s case, this would explain why:

openclaw update

stayed on 2026.4.14, but this is the command that would test the newer fix:

#

openclaw update --tag main

If they want to stay on stable, they may need to wait for the next release.
If they want to test the fix now, --tag main is the right path.

Docs:

opaque adder Apr 16, 2026, 8:16 PM

#

Im Santiago but in my computer discord account

ruby groveBOT Apr 16, 2026, 8:16 PM

#

Got it, thanks for clarifying.

Then the situation is:

2026.4.14 is likely the latest stable
the trim fix is likely on main
your normal global update path is currently blocked by that npm ENOTEMPTY error

So I’d skip openclaw update for now and use the installer path that targets main directly:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --version main --no-onboard
openclaw --version
openclaw configure --section channels

That is the cleanest next test.

#

If that still fails, paste just:

the new openclaw --version
and the short installer error, if any

Docs:

opaque adder Apr 16, 2026, 8:27 PM

#

🦞 OpenClaw Installer
curl for conversations.

✓ Detected: linux

Install plan
OS: linux
Install method: npm
Requested version: main
Onboarding: skipped
· Existing OpenClaw installation detected, upgrading

[1/3] Preparing environment
✓ Node.js v22.22.2 found
· Active Node.js: v22.22.2 (/usr/bin/node)
· Active npm: 9.2.0 (/usr/bin/npm)

[2/3] Installing OpenClaw
✓ Git already installed
· Installing OpenClaw (main)
! npm install failed for openclaw@main
Command: env SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm --loglevel error --silent --no-fund --no-audit install -g openclaw@main
Installer log: /tmp/tmp.9rauNW7y4b
! npm install failed; showing last log lines
! npm install failed; retrying
! npm install failed for openclaw@main
Command: env SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm --loglevel error --silent --no-fund --no-audit install -g openclaw@main
Installer log: /tmp/tmp.7w07SCCmXv
! npm install failed; showing last log lines

ruby groveBOT Apr 16, 2026, 8:27 PM

#

Thanks, this still only shows the installer wrapper error. The real clue is in the temp log.

Please send just the last lines of the newest installer log:

tail -n 30 /tmp/tmp.7w07SCCmXv

If that one is gone, try:

tail -n 30 /tmp/tmp.9rauNW7y4b

A screenshot is fine too.

One note, npm 9.2.0 looks a bit old next to Node 22.22.2, so this may still be an npm-side problem, but I want the exact last lines before guessing.

opaque adder Apr 16, 2026, 8:40 PM

#

i did both of the commands and got nothing

ruby groveBOT Apr 16, 2026, 8:41 PM

#

I’m checking the docs for how main is supposed to resolve on npm installs, so I don’t send you down the wrong path.

#

I found a better path in the docs: dev uses a git checkout of main, which avoids the npm package path that keeps failing for you.

#

Okay, let’s stop fighting the npm @main path.

The docs have a better route for this:

openclaw update --channel dev
openclaw --version
openclaw configure --section channels

Why this is better:

--tag main still uses the npm package path
--channel dev switches to a git checkout of main
that should avoid the npm global install path that keeps failing for you

Docs:

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

#

If openclaw update --channel dev fails, paste just that short error and I’ll keep going with you.

opaque adder Apr 16, 2026, 8:51 PM

#

let's start everything from scracth

ruby groveBOT Apr 16, 2026, 8:52 PM

#

Before you wipe it, I want to grab the safest reset path from the docs. There are a couple of levels here, and I’d rather not send you straight to the nuclear option unless we need it.

#

We can, but I want to be honest, a full wipe by itself probably will not fix the trim bug if you end up back on the same 2026.4.14 stable build.

Safest built-in reset options:

Fresh start, keep workspace
```
openclaw onboard --reset
```

True from-scratch reset, including workspace

openclaw onboard --reset --reset-scope full

Full uninstall path

#

   openclaw uninstall

then reinstall

My recommendation: use option 2 if you really want a clean slate, because it is the built-in path and safer than manual deletes.

Just one warning again: if the channel trim crash is a version bug in stable, you may still hit it again after the reset.

Docs:

If you want, I can walk you through the clean-reset path step by step.

river lodge Apr 16, 2026, 9:26 PM

#

hi @opaque adder and @hybrid locust were you able to solve the issue ?

ruby groveBOT Apr 16, 2026, 9:26 PM

#

Not fully yet.

What we narrowed down so far:

the daemon / gateway looks healthy now
the remaining issue is a trim crash during channel setup/configure
they are still on stable 2026.4.14
normal npm update path is also being flaky on that machine

So the likely blocker now is version/update path, not the gateway itself.

The next recommended step was:

openclaw update --channel dev

because that should switch to a git checkout of main and avoid the broken npm path.

#

If that still fails, the fallback was a built-in reset, but I was trying not to send them straight to a wipe unless needed.

opaque adder Apr 18, 2026, 1:06 AM

#

🦞 OpenClaw 2026.4.15 (041266a) — Half butler, half debugger, full crustacean.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
Pending (1)

ruby groveBOT Apr 18, 2026, 1:07 AM

#

That’s a different problem now. Let me pull the exact device-pairing flow so I give you the right fix, not a guess.

#

Nice, this is a different and much simpler issue now.

You’re on 2026.4.15, and the new error is just:

pairing required

The fix is:

openclaw devices list
openclaw devices approve <requestId>

Use the requestId from the pending entry, since your output already shows:

Pending (1)

#

Then retry whatever command you were running.

If you want, paste the short output of openclaw devices list and I’ll point at the exact requestId.

Docs:

opaque adder Apr 18, 2026, 1:08 AM

#

┌──────────────────────────────────────┬───────────────────┬──────────┬─────────────────────────────────────────────────────────────┬────────────┬──────────┬────────┐
│ Request │ Device │ Role │ Scopes │ IP │ Age │ Flags │
├──────────────────────────────────────┼───────────────────┼──────────┼─────────────────────────────────────────────────────────────┼────────────┼──────────┼────────┤
│ 95a33512-c5d6-4825-8bce-0100e621b444 │ e0df6ce9c86c93688 │ operator │ operator.admin, operator.read, operator.write, operator. │ │ just now │ repair │
│ │ 64a7d6dd995b37065 │ │ approvals, operator.pairing, operator.talk.secrets │ │ │ │
│ │ 74d49fd6caacdec2d │ │ │ │ │ │
│ │ c798bceb5e4ab │ │ │ │ │

ruby groveBOT Apr 18, 2026, 1:09 AM

#

Perfect, that’s the one.

Run:

openclaw devices approve 95a33512-c5d6-4825-8bce-0100e621b444

Then retry your command, probably:

openclaw configure --section channels

The repair flag fits a scope-upgrade / re-pair flow, so this looks normal.

If it works after that, please mark the solution so it gets indexed on Answer Overflow:

#

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

opaque adder Apr 18, 2026, 1:09 AM

#

the channels configuration is fixed since I updated it to 2026.4.15

ruby groveBOT Apr 18, 2026, 1:10 AM

#

Nice, glad we caught it. 🎉

So the trim / channel-config crash was a version issue, and updating to 2026.4.15 fixed it.

If the only thing left is the pairing prompt, approve the pending device request once. Otherwise you should be good.

If this solved it, please mark the solution so Answer Overflow can index it:

right-click the solution message → Apps → ✅ Mark Solution

That helps the next person a lot.

opaque adder Apr 18, 2026, 1:11 AM

#

🦞 OpenClaw 2026.4.15 (041266a) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId
u

ruby groveBOT Apr 18, 2026, 1:11 AM

#

That means the old pairing request is stale now.

This part is important: do not reuse the old requestId.
Generate / fetch a fresh one, then approve that exact ID.

Do this:

openclaw devices list
openclaw devices approve <new-requestId>

If openclaw devices list shows nothing pending, then first rerun the command that triggered the error, then immediately run:

openclaw devices list

#

again, and approve the new ID.

This is normal if the client retried and the pairing request rolled to a new requestId.

opaque adder Apr 18, 2026, 1:13 AM

#

how can I get the new requestId?

ruby groveBOT Apr 18, 2026, 1:13 AM

#

You don’t create it manually. OpenClaw creates it when a command hits pairing required.

Do this in order:

Run the command that triggers the pairing error
Then immediately run:
```
openclaw devices list
```
Copy the value from the Request column
Approve it:
```
openclaw devices approve <requestId>
```

So the flow is basically:

#

# trigger the pairing request
openclaw configure --section channels

# then fetch the fresh requestId
openclaw devices list

# then approve it
openclaw devices approve <requestId>

If you want, paste the new devices list output and I’ll point at the exact ID again.

opaque adder Apr 18, 2026, 1:46 AM

#

I tried to start my agent via telegram bot bot it says Agent couldn't generate responed. Please try again.

#

help

ruby groveBOT Apr 18, 2026, 1:48 AM

#

Yep, let’s do this step by step.

Run these two commands back to back and paste only the second output:

openclaw status
openclaw devices list

Why:

openclaw status should trigger a fresh pairing request
openclaw devices list should then show the new requestId

Then I’ll tell you the exact openclaw devices approve ... command to run.

If Discord complains again, a screenshot of the devices list table is fine.

opaque adder Apr 18, 2026, 1:49 AM

#

Iet's okay now but the problem is I can chat with my agent even in tui it doesn't respond me

ruby groveBOT Apr 18, 2026, 1:50 AM

#

I’m checking the no-reply / TUI docs, because “gateway is up but the agent won’t answer” has a pretty specific troubleshooting path.

#

Got it. If the TUI connects but the agent never answers, the next thing to check is usually model/auth, not the gateway.

Please run this exact ladder:

openclaw gateway restart
openclaw status
openclaw models status
openclaw logs --follow

And in the TUI, run:

/status

#

If you are expecting replies back into a chat channel from the TUI, also check:

/deliver on

Please paste only:

anything that looks like error / failed / unauthorized
or a screenshot of the TUI /status

Docs:

opaque adder Apr 18, 2026, 1:53 AM

#

│ Gateway │ local · ws://127.0.0.1:1515 (local loopback) · unreachable (timeout)

ruby groveBOT Apr 18, 2026, 1:53 AM

#

That’s the problem.

Your client is trying to reach:

ws://127.0.0.1:1515

but earlier your gateway was running on:

ws://127.0.0.1:18789

So the TUI is pointed at the wrong port.

Please check the real gateway URL:

#

openclaw gateway status

Then connect the TUI to that exact URL, for example:

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

If your gateway uses token auth, include the token too:

openclaw tui --url ws://127.0.0.1:18789 --token <your-token>

So yes, 1515 is the mismatch here, not the agent itself.

opaque adder Apr 18, 2026, 2:04 AM

#

◇ Control UI ─────────────────────────────────────────────────────────────────────╮
│ │
│ Web UI: http://127.0.0.1:18789/ │
│ Web UI (with token): │
│ http://127.0.0.1:18789/#token=3bc3cd10357a12bfd219cdc88498ae88b7ff8a62fd4b5295 │
│ Gateway WS: ws://127.0.0.1:18789 │
│ Gateway: not detected (gateway closed (1006): ) │
│ Docs: https://docs.openclaw.ai/web/control-ui │
│ │
├──────────────────────────────────────────────────────────────────────────────────╯
│

The gateway not detected again

ruby groveBOT Apr 18, 2026, 2:08 AM

#

Two things here, first one is important:

Please rotate that gateway token now, because it was posted publicly in this thread.
If you can, also delete the message with the tokenized URL.

If you’re using normal token auth, rotate it with:

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

For the actual gateway closed (1006) problem, run:

openclaw gateway restart

#

openclaw gateway status
openclaw logs --follow

That 1006 means the UI reached the URL, but the WebSocket connection to the gateway closed unexpectedly.

Please paste only:

the openclaw gateway status result
the first error line from openclaw logs --follow

Docs:

opaque adder Apr 18, 2026, 2:26 AM

#

It's still doesn't respond me when I hello in the tui

ruby groveBOT Apr 18, 2026, 2:26 AM

#

Understood. At this point we need the health output, otherwise we’re just guessing.

Please send these 3 short things:

openclaw status
openclaw models status

and inside the TUI:

/status

A screenshot is fine.
I only need:

#

the Gateway line
the model/auth line
anything marked error / unavailable / unauthorized

If the TUI won’t answer to hello, it’s usually one of these:

gateway not actually connected
no working model/auth
stuck session / bad current session state

The outputs above will tell us which one.

opaque adder Apr 18, 2026, 2:27 AM

#

🦞 OpenClaw 2026.4.15 (041266a) 🧠 Model: openrouter/arcee-ai/trinity-large-preview:free · 🔑 api-key (openrouter:default) 📚 Context: 0/200k (0%) · 🧹 Compactions: 0 🧵 Session: agent:main:main • updated just now ⚙️ Runtime: direct · Think: off 🪢 Queue: collect (depth 0) connected | idle

ruby groveBOT Apr 18, 2026, 2:27 AM

#

I’ve got the status now. Gateway and model look alive, so I’m checking the TUI behavior itself next, because this is starting to smell like input/session behavior rather than install or auth.

#

This is useful, thank you. Your gateway and model look connected, so we’re past install/auth.

The next 2 likely causes are:

bad/stuck session
provider/model error when the send actually happens

Please try this exact test in the TUI:

/new
hello

Then press Enter to send hello.

At the same time, in another terminal run:

#

openclaw logs --follow

What I want to know:

does the TUI status briefly change from idle to running/streaming?
if not, the message is not being submitted
if yes, paste the first error line from openclaw logs --follow

So the fastest next step is: reset session with /new, send one hello, watch logs.

opaque adder Apr 18, 2026, 2:30 AM

#

Log file: /tmp/openclaw/openclaw-2026-04-17.log
02:09:30+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
02:09:30+00:00 info gateway {"subsystem":"gateway"} starting...
02:09:37+00:00 error (node:1316168) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
02:10:02+00:00 info gateway {"subsystem":"gateway"} starting HTTP server...
02:10:02+00:00 info gateway {"subsystem":"gateway"} signal SIGTERM received
02:10:02+00:00 info gateway {"subsystem":"gateway"} received SIGTERM; shutting down
02:10:02+00:00 info gateway/canvas {"subsystem":"gateway/canvas"} canvas host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /root/.openclaw/canvas)
02:10:02+00:00 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
02:10:02+00:00 info gateway {"subsystem":"gateway"} agent model: openrouter/arcee-ai/trinity-large-preview:free
02:10:02+00:00 info gateway {"subsystem":"gateway"} ready (6 plugins: acpx, browser, device-pair, phone-control, talk-voice, telegram; 32.0s)
02:10:02+00:00 info gateway {"subsystem":"gateway"} log file: /tmp/openclaw/openclaw-2026-04-17.log
02:10:03+00:00 warn gateway {"subsystem":"gateway"} security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.

ruby groveBOT Apr 18, 2026, 2:31 AM

#

This log is actually helpful.

What it shows:

the gateway does start
the punycode warning is not the cause
the allowInsecureAuth warning is also not why the TUI is silent

What it doesn’t show yet is a failed message send.

Let’s bypass the keyboard/input question and force one message from the CLI:

openclaw tui --message "hello"

At the same time, in another terminal:

#

openclaw logs --follow

Then paste the lines that appear right when hello is sent.

So, we’re closer now:

gateway startup looks okay
we still need the send-time error, not the startup log

opaque adder Apr 18, 2026, 2:33 AM

#

02:33:30+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=a6911578-1e87-4fab-8fcc-6352cdeb8b38 sessionId=0c5bb07b-332f-4390-b784-b02a87d57342 stopReason=stop payloads=0 — surfacing error to user

ruby groveBOT Apr 18, 2026, 2:34 AM

#

That’s the first real clue, I’m looking up that exact warning so I can tell you whether this is a session bug or just a bad model/provider response.

#

I found the warning in source. It means the run completed with zero assistant payloads, which is usually a provider/model empty-response problem, not a TUI problem.

#

We found it.

That warning means the model run ended with no actual reply:

payloads=0
stopReason=stop

So this is not a TUI problem anymore.
Your current model/provider is returning an empty turn.

Fastest fix, switch to a different model for this session and retry:

/model openrouter/auto
/new
hello

#

Or outside the TUI:

openclaw models set openrouter/auto

If openrouter/auto isn’t available, run:

/model list

and pick another configured model.

So the root cause now is: that current ...:free model is not producing a usable reply. If switching models fixes it, you’re done.

opaque adder Apr 18, 2026, 2:40 AM

#

yes no reply

ruby groveBOT Apr 18, 2026, 2:40 AM

#

Okay, if openrouter/auto also gives no reply, I want to verify the safest next command before I tell them to reconfigure model auth.

#

Got it, then this is not the TUI.

If openrouter/auto also gives no reply, the problem is now the current OpenRouter/model path.

Fastest next step:

openclaw configure --section model

Then:

pick a different model/provider
reopen the TUI
run:
```
/new
```

#

  hello

If you want to inspect what’s available first:

openclaw models list

So the diagnosis now is:

onboarding: fixed
channels config: fixed
gateway/TUI connection: basically fixed
current model route is returning empty turns

#

If you only have OpenRouter set up right now, re-running the Model section is the right move.

#Help