#Help setting up clawd

1 messages · Page 1 of 1 (latest)

half raptor
#

Hey I need help to set up openclaw in a Ubuntu 24 VM with discord as channel and chatGpt as available API key.
I have installed clawd.
Gateway is running but it's not responding at all in the webui

I'm also limited to use my phone as access point to the VM and to discord.

I'm currently pretty lost and don't know what to look to get a chat response and locate the issues in my setup

twilit spokeBOT
#

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

verbal solarBOT
# half raptor Hey I need help to set up openclaw in a Ubuntu 24 VM with discord as channel and...

A “Gateway is running but Control UI doesn’t respond” is almost always one of these 3 things on Linux/VMs:

  1. you’re opening the UI remotely over plain HTTP (device identity blocked)
  2. the UI connection is blocked pending device pairing (WS 1008 “pairing required”)
  3. the Gateway service is “running” but the RPC probe is failing (wrong config/profile, wrong bind, crashed loop, etc.)

Can you run these on the VM and paste the output here?

openclaw --version
openclaw gateway status
openclaw status --all

(If your binary is clawd instead of openclaw, run the same commands with clawd.)

While you grab that, 2 quick fixes to try

#

A) If you’re opening http://<vm-ip>:18789/ from another device

That’s insecure HTTP and browsers often block the Control UI auth/crypto flow.

Best workaround (no config changes): SSH tunnel to localhost

ssh -N -L 18789:127.0.0.1:18789 <user>@<vm-ip>

Then open on your computer: http://127.0.0.1:18789/

Also: run openclaw dashboard on the VM to get the correct tokenized URL (don’t paste the token in Discord).

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

B) If the UI says disconnected / code 1008 / “pairing required”

Approve the browser/device (run on the VM):

#
openclaw devices list
openclaw devices approve <requestId>

Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection


Once the Control UI is connected, we’ll verify the two other pieces for “Discord + ChatGPT/OpenAI”:

openclaw models status
openclaw channels status --probe

…but first let’s see your gateway status + status --all output, because that will tell us immediately whether this is (1) insecure HTTP, (2) pairing, or (3) gateway/RPC not reachable.

half raptor
#

Ähm I might could try to run these of I could copy them.

I'm on mobile, so I can't pick specific parts of text here I only can copy full messages.
So it works be awesome if you could drop the code/requests as an extra message each at the end so I can copy them👍

verbal solarBOT
#

If your command is actually clawd (some installs alias it), use these instead:

clawd --version
clawd gateway status
clawd status --all

After you run them, paste the full outputs here (even if long).

half raptor
#

On openclaw Version 2026.2.9
Get way online and active
Status all also online

verbal solarBOT
# half raptor On openclaw Version 2026.2.9 Get way online and active Status all also online

Cool — if openclaw status --all says online, the Gateway itself is probably fine.

Now we need one missing detail to diagnose the Control UI:

What exact URL are you opening for the web UI? (copy/paste it)
Example: http://127.0.0.1:18789/ vs http://<vm-ip>:18789/

And: what does the UI say? (“unauthorized”, “disconnected (1008)”, “pairing required”, “device identity required”, etc.)
If you can, a screenshot of the UI is perfect.

Meanwhile, please run these on the VM and paste the full output:

1) Gateway status (shows bind/auth + probe target)

openclaw gateway status
#

2) List pending device pairing requests (very common cause)

openclaw devices list

If devices list shows a pending request, approve it with:

openclaw devices approve <requestId>

(Important: if any command prints a token, don’t paste the token here — just say “it asked for a token” / “I have a token”.)

half raptor
#

Ahh darn can't add pictures here but this settings all look good.
I'm evening the ui via the IP address

verbal solarBOT
# half raptor Ahh darn can't add pictures here but this settings all look good. I'm evening t...

If you’re opening the Control UI via http://<VM-IP>:18789/ from your phone: that’s plain HTTP. The page can load, but the UI often “does nothing” because the WebSocket auth/device-identity step is blocked in insecure HTTP.

You’ve got 3 ways out:

Option 1 (best, no config change): SSH tunnel → open localhost

From a device that can SSH into the VM, create a local port forward to the VM:

ssh -N -L 18789:127.0.0.1:18789 <user>@<vm-ip>

Then open on that same device:

  • http://127.0.0.1:18789/

This avoids the “remote HTTP” problem entirely.

Option 2 (best long-term): Tailscale Serve (HTTPS)

#

This gives you https://<magicdns>/ which fixes the insecure HTTP issue.
Docs: https://docs.openclaw.ai/gateway/tailscale

Option 3 (quick + a bit less secure): allow token-only over HTTP

This disables device-identity/pairing for the Control UI (temporary “just make it work” mode).

Run on the VM:

openclaw config set gateway.controlUi.allowInsecureAuth true --json

Then restart the gateway:

openclaw gateway restart
#

Then open the UI again via http://<vm-ip>:18789/ and paste your gateway token in the UI settings (don’t paste the token into Discord).

Docs section: https://docs.openclaw.ai/web/control-ui#insecure-http


One thing I still need from you

Please paste the full output of this (it will tell us exactly which bind/auth mode you’re in):

openclaw gateway status
half raptor
#

I'm connecting via rdp directly onto the machine I have openclaw running and opening the https there locally on the browser on exactly that machine

verbal solarBOT
# half raptor I'm connecting via rdp directly onto the machine I have openclaw running and ope...

If the browser is running on the same Ubuntu VM (even if you reached it via RDP), don’t open the Control UI via the VM’s IP and don’t use https:// unless you explicitly set up Tailscale Serve / a reverse proxy.

Do this instead (on the VM):

1) Open the correct local URL

http://127.0.0.1:18789/

2) Even better: let OpenClaw print the exact URL (with token)

openclaw dashboard --no-open

Open the URL it prints on that same VM. (Don’t paste the token link into Discord.)

If it still “does nothing”, it’s usually device pairing or auth. Run:

#
openclaw devices list

If you see a pending request, approve it:

openclaw devices approve <requestId>

And last: please paste the output of this (safe; just don’t include any token values if it prints them):

openclaw gateway status
half raptor
#

I have 2 paired devices

verbal solarBOT
# half raptor I have 2 paired devices

Nice — if openclaw devices list shows 2 paired devices, then it’s not stuck on pairing anymore.

Next most common gotcha (especially on fresh installs):

1) Make sure you’re NOT using https://

By default the Gateway serves the Control UI over plain HTTP.

On the VM, open exactly:

http://127.0.0.1:18789/

And/or run this to print the correct URL (often includes the token if you use token auth):

openclaw dashboard --no-open
#

(Do not paste the token link into Discord.)

2) If it still “does nothing”, I need the actual gateway bind/auth details

Please paste the output of:

openclaw gateway status

And tell me what the UI shows (literally the text), e.g.:

  • “unauthorized”
  • “disconnected (1008)”
  • “connect failed”
  • blank page / spinner forever

If you can’t easily describe it, one more useful one is:

#
openclaw logs --limit 200

Run that right after you reload the Control UI page, so we catch the handshake error in the logs.

half raptor
#

Can't paste anything since rdp from phone does not copy the data from the target system and I can't paste pictures here

verbal solarBOT
#

Reason: 127.0.0.1 / localhost are treated as a secure context; http://<vm-ip> is not, and the Control UI can fail device-identity/auth in a way that looks like “nothing happens”.


Since you can’t copy/paste output: 3 ways to get me the info

Option A (easiest): post from inside the VM

In the RDP session, open Discord Web (https://discord.com/app), go to this #help channel, and paste command output there.

Option B (phone-copyable): serve the output as a tiny local webpage for 2 minutes

Run on the VM:

openclaw gateway status --json > /tmp/gw.json
openclaw logs --limit 200 --json > /tmp/logs.json
python3 -m http.server 8000 --directory /tmp --bind 0.0.0.0
#

Then on your phone (normal browser, not RDP), open:

  • http://<VM-IP>:8000/gw.json
  • http://<VM-IP>:8000/logs.json

Copy/paste those into Discord.

When done, stop the server with Ctrl+C.

Option C (also good): SSH from the phone (Termux on Android)

SSH into the VM from the phone, run the commands, and then you can copy output normally.


If you want the “no copy/paste” minimal version:

Run this on the VM and just type these lines into Discord:

#
openclaw gateway status

Please type (exactly as shown):

  • Probe target: ...
  • RPC probe: ok/failed
  • Bind: ... (loopback/lan/tailnet/auto)
  • Auth: ... (token/password/none)
  • Last gateway error: ... (if present)

And tell me: when you open http://127.0.0.1:18789/, what does the UI text say (unauthorized / disconnected / blank / spinner)?

half raptor
#

openclaw logs --limit 200
/home/patrick/.npm-global/bin/openclaw: Zeile 3: imp
ort: Befehl nicht gefunden
/home/patrick/.npm-global/bin/openclaw: Zeile 5: //:
Ist ein Verzeichnis
/home/patrick/.npm-global/bin/openclaw: openclaw: Ze
ile 6: Syntaxfehler beim unerwarteten Wort »{«
/home/patrick/.npm-global/bin/openclaw: openclaw: Ze
ile 6: `if (module.enableCompileCache && !process.en
v.NODE_DISABLE_COMPILE_CACHE) {'
patrick@patrick-Standard-PC-i440FX-PIIX-1996:~$

#

Getting this when I run the logs

verbal solarBOT
# half raptor Getting this when I run the logs

What does it say exactly? Your message cut off right after “Getting this…”.

Since you can’t paste full output from the RDP session, the fastest is: type just the error line(s) you see after running logs (even 1–3 lines is enough). For example it might say unauthorized, ECONNREFUSED, RPC probe failed, etc.

Run this on the VM and then manually type the first error line + the last line you see:

openclaw logs --limit 50

If you want a way to copy from your phone without RDP clipboard, do this on the VM:

openclaw logs --limit 200 --json > /tmp/openclaw-logs.json
python3 -m http.server 8000 --directory /tmp --bind 0.0.0.0
#

Then on your phone (normal browser), open:

http://<VM-IP>:8000/openclaw-logs.json

Copy/paste the relevant bits here (please redact any tokens if you spot them).

Also: confirm you’re opening the UI as HTTP localhost on the VM:

http://127.0.0.1:18789/
half raptor
#

Yes I open the ui local as http with the 127.0.0.1:18789/ IP adress

#

bash
openclaw logs --limit 200 --json > /tmp/openclaw-logs.json
python3 -m http.server 8000 --directory /tmp --bind 0.0.0.0

half raptor
verbal solarBOT
#

Yep — that’s the right idea.

Now do this from your phone browser (not inside RDP):

  1. Open the logs file:
http://<VM-IP>:8000/openclaw-logs.json
  1. Copy/paste here the last ~50–100 lines (or search in the page for keywords like):
  • controlUi
  • unauthorized
  • pairing
  • 1008
  • connect
  • ws
  • error
#

That will tell us exactly why the UI “doesn’t respond”.

Also grab gateway status the same way (super useful)

On the VM, run:

openclaw gateway status --json > /tmp/gateway-status.json

Then open on your phone:

http://<VM-IP>:8000/gateway-status.json

…and paste that JSON here too.

#

Quick safety note

python3 -m http.server --bind 0.0.0.0 exposes those files to anything that can reach the VM on port 8000. If you’re on a phone hotspot it’s probably fine, but once you’ve copied the files, stop it with Ctrl+C in that terminal.

verbal solarBOT
# half raptor Yes I open the ui local as http with the 127.0.0.1:18789/ IP adress

Perfect — http://127.0.0.1:18789/ is the right place.

Now we need to figure out what part is failing (UI assets vs WebSocket auth vs “no model configured”). Since you can’t paste logs, let’s use short outputs you can type manually.

1) Does the Control UI HTML actually load?

Run this on the VM and type just the first line it prints (the HTTP status):

curl -I http://127.0.0.1:18789/ | head -n 1

You want something like HTTP/1.1 200 OK.
If it’s 404/500/etc, the UI isn’t being served right.

2) Can the CLI talk to the Gateway WebSocket?

Run:

#
openclaw health

Then tell me: does it say OK / healthy, or does it show an error (just type the error line)?

3) If the UI loads + Gateway is healthy, the next culprit is usually “no model/auth”

Run:

openclaw models status --plain

…and type exactly what it prints (it should be a single line).


#

That URL has two issues:

  1. it should be .json, not .js
  2. you must replace <VM-IP> with the VM’s real IP (e.g. 192.168.x.x)

Try this from your phone browser:

A) Open the directory listing first

http://VM-IP:8000/

You should see a file list. Tap:

  • openclaw-logs.json

So the full URL should be:

#
http://VM-IP:8000/openclaw-logs.json

If you don’t see openclaw-logs.json in the list, re-create it on the VM:

openclaw logs --limit 200 --json > /tmp/openclaw-logs.json

And also generate gateway status (super helpful):

openclaw gateway status --json > /tmp/gateway-status.json

Then on your phone open:

#
http://VM-IP:8000/gateway-status.json

Paste both here (or at least the last ~50 lines of the logs). If you spot any tokens, redact them.

When you’re done, stop the file server with Ctrl+C in that terminal.

#

If typing those lines is still too painful: easiest workaround is to open Discord Web inside the VM (in the RDP browser) and paste the command outputs directly from there. That avoids the phone/RDP clipboard limitation entirely.

half raptor
#

Getting Connection refused when I try to connect to the temporary address

#

Well the ui does respond but not the ai it's just giving back nothing

#

Health gives me back this

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

Discord: failed (401) - getMe failed (401)
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/patrick/.openclaw/agents
/main/sessions/sessions.json (1 entries)

  • agent:main:main (36m ago)
verbal solarBOT
# half raptor Health gives me back this 🦞 OpenClaw 2026.2.9 (33c75cb) I run on caffeine, ...

That output is the smoking gun:

Discord: failed (401) - getMe failed (401) = your Discord bot token is wrong / missing.
So OpenClaw can’t log into Discord at all → no Discord replies will ever work until that’s fixed.

Fix (don’t paste the token into Discord)

  1. Go to Discord Developer Portal → Your App → Bot

    • Click Reset Token (or copy the correct token)
    • Make sure you’re using the Bot Token (not client secret)
  2. Set it in OpenClaw config on the VM (recommended, survives restarts):

openclaw config set channels.discord.enabled true --json
#
openclaw config set channels.discord.token "PASTE_YOUR_BOT_TOKEN_HERE"
  1. Restart the gateway:
openclaw gateway restart
  1. Re-check:
openclaw health

You want Discord to show ok/connected (no 401).

#

Docs (for later, after token works): https://docs.openclaw.ai/channels/discord


If after this Discord connects but still doesn’t reply in your server channels, that’s usually mention gating / guild allowlist / missing Message Content Intent — but the 401 has to be solved first.

half raptor
#

So the discord issue is the issue that the ai isn't even responding in the ui it self?

verbal solarBOT
# half raptor So the discord issue is the issue that the ai isn't even responding in the ui it...

No — the Discord 401 should not be what makes the Control UI chat not respond.

Think of it like this:

  • Control UI chat = your browser talks directly to the Gateway WebSocket, then the Gateway talks to the model provider (OpenAI/Anthropic/etc).
  • Discord = just one “channel connector” into the same Gateway. If Discord auth is broken, Discord won’t work, but the UI can still work.

So you currently have at least one real problem (Discord token 401), and you might have a second problem (model/auth), which would explain “no response in the UI”.

What I want to check next (this is the key for UI not responding)

Run this on the VM and paste the output:

openclaw models status

That will tell us if OpenAI is configured correctly or if it says “missing auth / no API key”.

#

Also, after you try sending a message in the Control UI (just “hi”), run:

openclaw logs --limit 200

and tell me the one error line you see near the end (even if you have to type it manually).

Separate: fix Discord (so Discord replies can work)

Your health output shows:

Discord: failed (401) - getMe failed (401)

That means the bot token is invalid/wrong/missing. Fix by updating channels.discord.token (don’t paste the token here), then:

#
openclaw gateway restart

But first let’s confirm the model situation with openclaw models status, because that’s what usually blocks the Control UI chat too.

half raptor
verbal solarBOT
# half raptor Yeah that's what I was expecting. Thought I'd I get the ui to respond, I can use...

Yeah — the Control UI chat does call the model, so if you keep hitting “send” while it looks stuck, it will happily burn credits even if the UI never renders the reply.

Two fast “escape hatches” to get unstuck without the web UI:

1) Use the Terminal UI (TUI) instead of the web UI

This talks to the same Gateway but avoids any Control UI weirdness.

openclaw tui

Type hello and hit Enter. If you get a reply here, your model/auth is fine and the issue is just the Control UI.

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

2) Check model/auth (this is usually the real reason for “no reply”)

Run:

#
openclaw models status

If it says missing auth / no credentials / etc, that’s why the UI “does nothing” (the run fails server-side).


Separate (but important): your Discord connector is broken

Your earlier openclaw health showed:

Discord: failed (401) - getMe failed (401)

That means wrong/missing Discord bot token. Fixing that won’t fix the Control UI chat, but it will stop Discord from ever working until corrected.


#

If TUI also doesn’t reply

Run this in one terminal:

openclaw logs --follow

Then (in TUI or Control UI) send one message (“hi”) and watch the log output. Even if you can’t copy/paste the whole thing, type the single error line you see (usually mentions the provider/model/auth failure). That one line is enough to diagnose.

half raptor
#

patrick@patrick-Standard-PC-i440FX-PIIX-1996:~$ open
claw models status

🦞 OpenClaw 2026.2.9 (33c75cb)
I'll butter your workflow like a lobster roll: me
ssy, delicious, effective.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/gpt-4.1-mini
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : GPT -> openai/gpt-5.1-codex
Configured models (3): google/gemini-flash-lite-late
st, openai/gpt-5.1-codex, openai/gpt-4.1-mini

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

  • google effective=profiles:~/.openclaw/agents/main/
    agent/auth-profiles.json | profiles=1 (oauth=0, toke
    n=0, api_key=1) | google:default=AIzaSyCJ...PDyparm0
  • openai effective=env:sk-proj-...m3Un9UUA | env=sk-
    proj-...m3Un9UUA | source=env: OPENAI_API_KEY

OAuth/token status

  • none
    patrick@patrick-Standard-PC-i440FX-PIIX-1996:~$
#

TUI is also not giving any tesponses

verbal solarBOT
# half raptor patrick@patrick-Standard-PC-i440FX-PIIX-1996:~$ open claw models status 🦞 Open...

Good news: your model setup is fine.

From your openclaw models status:

  • Default model: openai/gpt-4.1-mini
  • OPENAI_API_KEY is being picked up (source=env: OPENAI_API_KEY)

So the “UI eats credits but shows no reply” is not because OpenAI is missing.

Now we need to separate: does the agent actually reply (Gateway+model OK) vs just the Control UI not rendering it.

1) Quick sanity test (bypasses the web UI completely)

Run this on the VM:

openclaw tui
#

Type hi and press Enter.

  • If you get a reply in the TUI → Gateway+model are working, and your problem is Control UI frontend.
  • If the TUI also hangs / errors → we’ll diagnose the Gateway run errors from logs.

(You can keep using TUI to finish setup even if the web UI is annoying.)

2) If TUI works: fix Control UI by “fresh browser storage”

Most common cause: the UI has a stale gatewayUrl/auth setting in localStorage.

Try incognito/private window on the VM and open:

http://127.0.0.1:18789/

Also run (prints the “canonical” URL):

#
openclaw dashboard --no-open

3) We still need one log snippet around a send attempt

Do this:

  1. In one terminal:
openclaw logs --follow
  1. Then send one message in the Control UI (“test”).

  2. Copy/paste the last ~20 lines that appear in that log terminal after you send.

That will tell us exactly what the Gateway thinks is happening (run started, run finished, error, etc.).

#

Separate issue (will block Discord replies no matter what)

Your earlier health output showed:

Discord: failed (401) - getMe failed (401)

That’s an invalid Discord bot token (wrong token / revoked / typo). Fixing the UI won’t fix Discord until you replace channels.discord.token and restart the gateway.

But first: let’s confirm with openclaw tui whether the assistant can reply at all.

half raptor
#

Claw isn't opening tui

#

Might need to restart it

verbal solarBOT
# half raptor Claw isn't opening tui

openclaw tui is a full-screen terminal app (it doesn’t “open a new window”). On a weird terminal it can look like “nothing happened”.

Two likely causes here:

  1. It actually opened, but you’re seeing a blank/odd screen in your terminal
  2. Your terminal session doesn’t look like a real TTY (TERM issues), so the TUI can’t start

Do these in order and tell me what you see:

1) Confirm the command exists

openclaw tui --help
  • If this says “unknown command” → we’ve got an install/path mismatch.
  • If it prints help → command exists.

2) Try forcing a sane terminal type

#
echo $TERM

Then run:

TERM=xterm-256color openclaw tui --url ws://127.0.0.1:18789

3) If it still doesn’t show, force a real TTY wrapper

script -q -c "openclaw tui --url ws://127.0.0.1:18789" /dev/null

When it opens, you should see a header + chat log. Exit with Ctrl+D (or type /exit).


#

Separate but important: your OpenAI key might not be in the Gateway service env

Your models status shows OpenAI auth is coming from env (OPENAI_API_KEY) and Shell env: off. If the Gateway is running via systemd, it often does not inherit your shell env, so UI chats can fail/hang.

Quick fix: put the key in ~/.openclaw/.env (so the service always sees it), then restart gateway:

nano ~/.openclaw/.env

Add:

OPENAI_API_KEY=sk-proj-...
DISCORD_BOT_TOKEN=...

Then:

#
openclaw gateway restart

(Do not paste keys in Discord.)


Reply with: what openclaw tui --help prints (or the exact error line), and whether TERM=... openclaw tui ... shows anything or immediately returns to the prompt.

#

Yeah—restart is a good next move here (it clears wedged runs + reconnects the UI WS).

Run these on the VM (each block is copy/pasteable):

1) Restart the Gateway service

openclaw gateway restart

2) Immediately verify it’s reachable

openclaw health

3) Then open the UI (on the VM)

#
http://127.0.0.1:18789/

If it’s still weird after restart, do a “harder” cycle:

Stop → start

openclaw gateway stop
openclaw gateway start

Important: make sure the service has your API keys

Your models status showed OpenAI auth coming from shell env (OPENAI_API_KEY) and Shell env: off. On Ubuntu, the systemd service often does not inherit your shell env, so the UI can fail/hang even though the CLI looks fine.

#

Fix: put keys in ~/.openclaw/.env (so the service always sees them), then restart again.

nano ~/.openclaw/.env

Add (example):

OPENAI_API_KEY=sk-proj-...
DISCORD_BOT_TOKEN=...

Then:

openclaw gateway restart
#

After restart: confirm the Discord 401 is gone

openclaw health

You want Discord to be “ok”; if it still says failed (401), the bot token is still wrong.

If you tell me what openclaw health shows after the restart, we’ll know exactly which piece is still broken.

half raptor
#

Getting this from the followed logs
22:27:56 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
22:27:56 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=2 queueSize=0
22:27:56 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
22:27:56 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=2 queueSize=0
22:27:56 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=0989fe9e-16c8-484c-9409-07d20d9bdffe sessionId=30343494-5636-448a-8d74-7532636d4b9a provider=openai model=gpt-4.1-mini thinking=off messageChannel=webchat
22:27:56 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=30343494-5636-448a-8d74-7532636d4b9a sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
22:27:56 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=30343494-5636-448a-8d74-7532636d4b9a totalActive=1
22:27:56 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=0989fe9e-16c8-484c-9409-07d20d9bdffe sessionId=30343494-5636-448a-8d74-7532636d4b9a
22:27:56 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=0989fe9e-16c8-484c-9409-07d20d9bdffe
22:28:03 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=0989fe9e-16c8-484c-9409-07d20d9bdffe
22:28:03 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=0989fe9e-16c8-484c-9409-07d20d9bdffe sessionId=30343494-5636-448a-8d74-7532636d4b9a durationMs=7240
22:28:03 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=30343494-5636-448a-8d74-7532636d4b9a sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
22:28:03 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=30343494-5636-448a-8d74-7532636d4b9a totalActive=0

#

22:28:03 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=0989fe9e-16c8-484c-9409-07d20d9bdffe sessionId=30343494-5636-448a-8d74-7532636d4b9a durationMs=7294 aborted=false
22:28:03 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=7296 active=0 queued=0
22:28:03 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=7301 active=0 queued=0

verbal solarBOT
# half raptor Getting this from the followed logs 22:27:56 debug diagnostic {"subsystem":"diag...

Those log lines are actually good:

  • the run starts
  • OpenAI is called (provider=openai model=gpt-4.1-mini)
  • the run completes (run_completed)
  • no error is logged

So the Gateway + model call are working. If the UI shows no reply, it’s usually one of these:

  1. the reply is getting generated but not being shown (frontend/state issue), or
  2. the model is replying with the silent-reply token (so OpenClaw intentionally doesn’t deliver anything), or
  3. the UI client disconnects before the reply is delivered.

Let’s confirm which one by checking what was actually written to the session transcript.

A) Find the transcript file that changed when you sent the message

Run this right after you send one test message in the UI:

#
find ~/.openclaw/agents/main/sessions -type f -mmin -5 | head -50

Then take the most “transcript-looking” file from that list and show the last lines:

tail -n 80 /path/to/that/file

(If you paste that tail here, we’ll immediately see whether the assistant replied with something like NO_REPLY / empty / etc.)

B) Quick “force a visible reply” test

In the UI, send exactly:

#
Reply with exactly: PING

If even that results in nothing displayed, it’s almost certainly UI delivery/rendering (not the model).

C) Also check if the UI is disconnecting

Run:

openclaw logs --limit 300 | grep -i "webchat\\|disconnect\\|connect\\|closed\\|1008\\|unauthor" | tail -n 80

If you paste the output of A (tail of the transcript) or C, we’ll know the precise failure mode.

Side note (separate issue): your earlier openclaw health showed Discord: failed (401), so Discord will still never reply until you fix the bot token — but that’s independent of the UI chat problem.

half raptor
#

Give me the commands as a single message.

So description what the command is needed for.
New message with only the command to copy.
New message with next step.
If there is a command I should copy. Send it in a own message.
Don't add any descriptions into that message.
Post them in the message before or after the commands

verbal solarBOT
# half raptor 22:28:03 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: ...

Those lines confirm the agent run is finishing cleanly (aborted=false, no errors). So the “it eats credits but UI shows nothing” isn’t a model/auth failure — it’s either:

  • the model reply is getting filtered out (e.g. it replied NO_REPLY / empty), or
  • the Control UI isn’t rendering/receiving the chat event.

Fastest way to tell which: pull the chat history directly from the Gateway.

Run this on the VM and paste the output:

openclaw gateway call chat.history --params '{"sessionKey":"main","limit":20}'

What I’m looking for in that JSON:

  • Do you see an assistant message after your last user message?
  • If yes: what’s the assistant text? (Especially if it’s NO_REPLY or empty.)
#

Also: what exact text did you type into the Control UI when you tested? (Even just “hi”, “/status”, etc.)

half raptor
#

Seems my agent run out of credits
is provided. Be yourself - use your defined voice,
mannerisms, and mood. Keep it to 1-3 sentences and
ask what they want to do. If the runtime model
differs from default_model in the system prompt,
mention the default model. Do not mention internal
steps, files, tools, or reasoning.

You exceeded your current quota, please check your
plan and billing details. For more information on
this error, read the docs:
https://platform.openai.com/docs/guides/error-code
s/api-errors.

help

You exceeded your current quota, please check your
plan and billing details. For more information on
this error, read the docs:
https://platform.openai.com/docs/guides/error-code
s/api-errors.

openclawd --version

You exceeded your current quota, please check your
plan and billing details. For more information on
this error, read the docs:
https://platform.openai.com/docs/guides/error-code
s/api-errors.

hi

You exceeded your current quota, please check your
plan and billing details. For more information on
this error, read the docs:
https://platform.openai.com/docs/guides/error-code
s/api-errors.

hello

(no output)
connected | idle
agent main | session main (openclaw-tui) |
openai/gpt-4.1-mini | tokens 0/1.0m (0%)

#

How can I solve this?

verbal solarBOT
# half raptor Seems my agent run out of credits is provided. Be yourself - use your defined vo...

Yep — that output means it’s not a Control UI bug anymore:

Your OpenAI API account is out of quota / billing isn’t enabled (You exceeded your current quota…).
When that happens, every message you send will fail at the model call, so the UI/TUI can’t produce a real reply.

Key nuance: a ChatGPT subscription ≠ OpenAI API credits. The API needs its own billing/quota.

Fix option A: enable OpenAI API billing (keep using OpenAI)

Go to the OpenAI Platform billing/limits pages and:

  • add a payment method
  • make sure you have a non-zero credit/quota and a reasonable monthly limit

Then restart the gateway:

openclaw gateway restart
verbal solarBOT
# half raptor How can I solve this?

You fix it by giving OpenClaw a model provider that actually has usable quota.

Option 1 (recommended if you want “ChatGPT/OpenAI”): enable OpenAI API billing

That error is from the OpenAI API, not the ChatGPT app. A ChatGPT subscription usually doesn’t include API credits.

Do this:

  1. Go to https://platform.openai.com/
  2. Billing → add a payment method / buy credits (and check you have a non-zero spend limit)
  3. Then on the VM restart:
openclaw gateway restart

Then test in TUI again:

#

Fix option B (fastest): switch to your Google model temporarily

Your models status showed you already have a Google API key + a Google model configured. Switch the default model to that so you can keep debugging right now:

openclaw models set google/gemini-flash-lite-latest

Then test in TUI / Control UI again.

(If you want to verify Google works before switching, you can run:)

openclaw models status --probe-provider google

After that: Discord is still broken (separate issue)

Earlier you had:

#
openclaw tui

Option 2 (fastest to get unstuck right now): switch to Google Gemini (you already have it configured)

Your openclaw models status showed google/gemini-flash-lite-latest is configured with an API key.

Set it as default:

openclaw models set google/gemini-flash-lite-latest

Then test:

openclaw tui
#

Discord: failed (401) - getMe failed (401)

That’s an invalid Discord bot token. Once you’ve got any model responding again, we can fix Discord by updating channels.discord.token and restarting.

If you tell me which path you want (A keep OpenAI vs B switch to Google for now), I’ll give you the exact next commands.

#

Option 3: add another provider (Anthropic/OpenRouter/etc.)

If you don’t want to use OpenAI API billing, you can configure a different provider with a key and set it as default.


After you get any model replying again, we should fix the other blocker you had:
Discord 401 = wrong Discord bot token. That’s separate and will still prevent Discord replies until corrected.

Which do you prefer: Option 1 (OpenAI API billing) or Option 2 (switch to Google)?

half raptor
#

Switch to Google for now

half raptor
#

bash
openclaw models set google/gemini-flash-lite-latest

#

What free plans work the best with openclaw or are there free plans that actually work?

verbal solarBOT
# half raptor What free plans work the best with openclaw or are there free plans that actuall...

“Free plans” are the rough spot for OpenClaw: the app is free, but the LLM + tool-calling API usually isn’t. Most “free” options fall into two buckets:

  1. Trial credits / limited free tiers (cloud)
  • They can work to get you through setup and a few tests.
  • The common failure mode is rate limits / quotas right when you start using tools (browser, exec, message routing, etc.).
  • If you go this route, pick a provider/model that explicitly supports tool/function calling reliably.
  1. Local models (actually free to run, but hardware-dependent)
  • Works without paid API keys, but for agentic/tool-heavy flows you generally need a pretty beefy machine to avoid it feeling broken/slow.
  • Also: some local stacks are still flaky at strict tool JSON, which can cause “tool not found / ignored tool result” type issues.

Practical advice: if you want something that “actually works” for agent + tools, you’ll usually have a better time with a cheap paid model (even a few dollars) than any free tier.

Docs + community notes (kept up to date):

#

If you tell me what you’re trying to do (just chat? or browser/automation?), and whether you want cloud or local, I can point you to the most realistic option.