Agent failed before reply

[quaint mural]

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

[vital dagger]

First check: what does openclaw --version print?

That error usually means your config is forcing the codex agent harness, but the Codex plugin/harness did not register at gateway startup. Common causes:

1. plugins.entries.codex.enabled is missing/false
2. you have plugins.allow set and it does not include codex
3. the gateway is on an older/mismatched version or needs a restart after config changes

Run these and paste the output if it is still failing:

openclaw --version
openclaw status --all
openclaw doctor
openclaw logs --follow

If you intended to use Codex, your config needs the Codex plugin enabled, and if you use plugins.allow, codex must be in that allowlist. The relevant docs are here: https://docs.openclaw.ai/plugins/codex-harness

If you did not mean to force Codex, look for embeddedHarness.runtime: "codex" in your config and switch back to the default/auto path, then restart the gateway.

FAQ/debug loop: https://docs.openclaw.ai/help/faq

[spare surge]

OpenClaw 2026.5.12 (f066dd2)
OpenClaw doctor
│
◇ Update ──────────────────────────────────────────────────────────────────────────────────╮
│ │
│ This install is not a git checkout. │
│ Run openclaw update to update via your package manager (npm/pnpm), then rerun doctor. │
│ │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Command owner ────────────────────────────────────────────────────────────────────────────╮
│ │
│ No command owner is configured. │
│ A command owner is the human operator account allowed to run owner-only commands and │
│ approve dangerous actions, including /diagnostics, /export-trajectory, /config, and exec │
│ approvals. │
│ DM pairing only lets someone talk to the bot; it does not make that sender the owner for │
│ privileged commands. │
│ Fix: set commands.ownerAllowFrom to your channel user id, for example openclaw config │
│ set commands.ownerAllowFrom '["telegram:123456789"]' │
│ Restart the gateway after changing this if it is already running. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◆ Tighten permissions on ~/.openclaw to 700?
│ ● Yes / ○ No

[vital dagger]

Yep, answer Yes to the ~/.openclaw permissions prompt. That is a normal doctor repair.

The “command owner” warning is separate from the Codex harness error, but you should fix it so owner-only commands work from Discord. For your Discord account, run:

openclaw config set commands.ownerAllowFrom '["discord:492478469473566750"]'
openclaw gateway restart

Then rerun:

openclaw doctor
openclaw status --all

For the original Requested agent harness "codex" is not registered error: after the restart, if it still happens, check whether Codex is disabled/excluded in config. If you have plugins.allow, it must include codex, and the Codex plugin should be enabled. Docs: https://docs.openclaw.ai/plugins/codex-harness

[vital dagger]

Also run openclaw update when you can; doctor is telling you this package install updates through the package manager, not git.

[spare surge]

Log file: /tmp/openclaw/openclaw-2026-05-15.log
18:33:17+00:00 info gateway {"subsystem":"gateway"} loading configuration…
18:33:17+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
18:33:17+00:00 error Missing config. Run openclaw setup or set gateway.mode=local (or pass --allow-unconfigured).
18:53:42+00:00 info No gateway token found. Auto-generated one and saving to config.
18:53:43+00:00 info gateway {"subsystem":"gateway"} loading configuration…
18:53:43+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
18:53:43+00:00 error Gateway start blocked: existing config is missing gateway.mode. Treat this as suspicious or clobbered config. Re-run openclaw onboard --mode local or openclaw setup, set gateway.mode=local manually, or pass --allow-unconfigured.
18:53:43+00:00 error Config write audit: /home/jdely3/.openclaw/logs/config-audit.jsonl
18:53:45+00:00 info gateway {"subsystem":"gateway"} loading configuration…
18:53:45+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
18:53:45+00:00 error Gateway start blocked: existing config is missing gateway.mode. Treat this as suspicious or clobbered config. Re-run openclaw onboard --mode local or openclaw setup, set gateway.mode=local manually, or pass --allow-unconfigured.
18:53:45+00:00 error Config write audit: /home/jdely3/.openclaw/logs/config-audit.jsonl
18:53:58+00:00 info Gateway restart failed after 13s: service stayed stopped and port 18789 stayed free.
18:53:58+00:00 info Service runtime: status=stopped, state=failed, lastExit=78
18:53:58+00:00 info Gateway port 18789 status: free.
18:53:58+00:00 error Gateway restart failed after 13s: service stayed stopped and health checks never came up.
18:53:58+00:00 info Tip: openclaw gateway status --deep
18:53:58+00:00 info Tip: openclaw doctor
21:31:10+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 56ms conn=3c6c44ba…31f2 id=fa8f0a58…02fd
21:31:10+00:00 info gateway/ws

[vital dagger]

This log shows a more basic gateway config problem first: the gateway had an existing config file, but it was missing gateway.mode, so the service refused to start.

Repair that stamp, then restart:

openclaw config set gateway.mode local
openclaw gateway restart
openclaw gateway status --deep

If you want to re-run the setup wizard instead of setting just that key:

openclaw onboard --mode local
openclaw gateway restart

[vital dagger]

Don’t use --allow-unconfigured as the fix here; docs treat it as a dev/bootstrap escape hatch, not a config repair.

After the gateway is actually running, then chase the Codex harness error with:

openclaw doctor
openclaw status --all

Relevant runbook: https://docs.openclaw.ai/gateway/troubleshooting

[spare surge]

I cant type in that terminal now

[vital dagger]

That terminal is probably sitting inside an interactive prompt from openclaw doctor.

Try this in order:

1. Press Enter once. The prompt has Yes selected, so that should accept the permissions fix.
2. If it still feels stuck, press Ctrl+C to exit doctor.
3. Open a new terminal tab/window and run the repair commands there:

openclaw config set gateway.mode local
openclaw config set commands.ownerAllowFrom '["discord:492478469473566750"]'
openclaw gateway restart
openclaw gateway status --deep

If Ctrl+C does not work, just close that terminal tab and use a fresh one. Nothing in that prompt is worth fighting the terminal over.

[spare surge]

now what

[vital dagger]

Next step is to repair the missing gateway mode and restart cleanly.

In a fresh terminal, run exactly this:

openclaw config set gateway.mode local
openclaw config set commands.ownerAllowFrom '["discord:492478469473566750"]'
openclaw gateway restart
openclaw gateway status --deep

If gateway status --deep says the gateway is running/healthy, try sending a message to OpenClaw again.

If it still fails with Requested agent harness "codex" is not registered, run this next and paste the output:

[vital dagger]

openclaw config get plugins
openclaw config get agents.defaults.embeddedHarness
openclaw status --all

[spare surge]

there is no output for bash

[vital dagger]

No output from the first two openclaw config set ... commands can be normal. They may just exit quietly if they wrote the config.

Run these one at a time so we can see where it is:

openclaw config get gateway.mode
openclaw config get commands.ownerAllowFrom
openclaw gateway restart
openclaw gateway status --deep

Expected first outputs are roughly:

local
["discord:492478469473566750"]

[vital dagger]

If even openclaw gateway status --deep prints absolutely nothing and returns you to the prompt, tell me what OS/terminal you’re using and paste the output of:

which openclaw
openclaw --version

[spare surge]

dely3@DESKTOP-I238VPJ:~$ openclaw config get gateway.mode

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

local
jdely3@DESKTOP-I238VPJ:~$ openclaw config get commands.ownerAllowFrom

🦞 OpenClaw 2026.5.12 (f066dd2) — Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

[
"discord:492478469473566750"
]
Im trying to speak to openclaw through the dashboard and im using umbuntu terminal

[vital dagger]

Good, those two config values are fixed.

Now we need to check whether the gateway actually restarted and whether the dashboard is connected to that gateway. In Ubuntu terminal, run:

openclaw gateway restart
openclaw gateway status --deep
openclaw status --all

Then try the dashboard at:

http://127.0.0.1:18789/

Since you’re on Ubuntu under Windows/WSL, if the Windows browser dashboard doesn’t connect, open the URL printed by openclaw dashboard instead:

[vital dagger]

openclaw dashboard

If the dashboard connects but replies still fail with Requested agent harness "codex" is not registered, paste:

openclaw config get plugins
openclaw config get agents.defaults.embeddedHarness
openclaw logs --follow

The gateway.mode issue is repaired; the next likely issue is either dashboard ↔ gateway connection, or Codex plugin/harness config.

[spare surge]

both url you gave me and openclaw dashboard gave me cant reach the site

[vital dagger]

If both URLs say “can’t reach,” the gateway probably still isn’t listening, or WSL ↔ Windows localhost forwarding is getting in the way.

First, run this in Ubuntu and paste the output:

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

If curl cannot connect, the gateway is not up. Try a foreground start so you can see the real error:

openclaw gateway --force

Leave that terminal open. If it starts successfully, then open the dashboard again in your Windows browser.

[vital dagger]

If curl works inside Ubuntu but Windows browser still can’t reach it, get the WSL IP and open that from Windows:

hostname -I | awk '{print $1}'

Then try http://<that-ip>:18789/ in the Windows browser. Example shape: http://172.xx.xx.xx:18789/.

Docs for dashboard connectivity: https://docs.openclaw.ai/web/dashboard

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ openclaw gateway status --deep
curl -i http://127.0.0.1:18789/healthz

🦞 OpenClaw 2026.5.12 (f066dd2) — Type the command with confidence—nature will provide the stack trace if needed.

│
◇
Service: systemd user (enabled)
File logs: /tmp/openclaw/openclaw-2026-05-15.log
Command: /usr/bin/node /home/jdely3/.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.

CLI version: 2026.5.12 (~/.npm-global/bin/openclaw)
Gateway version: 2026.5.12

Runtime: running (pid 5131, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: read-only

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Date: Fri, 15 May 2026 21:44:29 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 27

[vital dagger]

Good news: the gateway is healthy. This is now a WSL/browser reachability problem, not OpenClaw failing to start.

Your gateway is bound to WSL-only loopback: 127.0.0.1:18789. Your Windows browser may not be able to reach that. Switch the gateway to LAN bind so Windows can reach the WSL IP:

openclaw config set gateway.bind lan
openclaw gateway restart
hostname -I | awk '{print $1}'

Take the IP printed by the last command and open this in your Windows browser:

http://<that-ip>:18789/

Example shape: http://172.24.123.45:18789/

[vital dagger]

If the dashboard asks for auth, use your gateway token/password locally, but don’t paste that token here. If you need OpenClaw to print the dashboard helper link again, run:

openclaw dashboard --no-open

Once the dashboard loads, try sending a message there again. If the dashboard loads but the agent reply fails, paste the non-secret error text.

[spare surge]

⚠️ Agent failed before reply: Requested agent harness "codex" is not registered.
Logs: openclaw logs --follow

[vital dagger]

Okay, dashboard connectivity is fixed. Now we’re back to the original Codex harness config.

Run these:

openclaw plugins enable codex
openclaw config set plugins.entries.codex.enabled true
openclaw gateway restart

Then test the dashboard again.

If it still says codex is not registered, paste these outputs:

openclaw plugins list --enabled

[vital dagger]

openclaw config get plugins.allow
openclaw config get plugins.entries.codex.enabled
openclaw config get agents.defaults.embeddedHarness
openclaw logs --follow

Important bit: if plugins.allow exists, it must include codex, otherwise the Codex plugin is excluded even if the entry says enabled. Docs: https://docs.openclaw.ai/plugins/codex-harness

[spare surge]

plugins.entries.codex: plugin not installed: codex — install the official external │
│ plugin with: openclaw plugins install @openclaw/codex

[vital dagger]

That explains it: your config is trying to use the Codex harness, but the Codex plugin is not installed in this OpenClaw install.

Run:

openclaw plugins install @openclaw/codex
openclaw plugins enable codex
openclaw gateway restart

Then verify:

openclaw plugins list --enabled
openclaw gateway status --deep

[vital dagger]

After that, try the dashboard message again.

If the install command fails, paste that error. If you don’t specifically need Codex, the other path is to remove the forced Codex harness from config, but since your dashboard is already pinned to codex, installing the plugin is the direct fix.

[spare surge]

I tested it and its been loading a response for a few minutes now

[vital dagger]

A few minutes is too long for a normal first reply. Let’s check whether it is actually working, waiting on auth, or stuck in the Codex plugin.

In Ubuntu, run these and paste the non-secret output:

openclaw status --all
openclaw models status
openclaw logs --follow

Let openclaw logs --follow run while the dashboard spinner is active for ~20 seconds, then press Ctrl+C and paste the relevant error/warning lines.

Also check the Codex plugin is really loaded:

openclaw plugins list --enabled

[vital dagger]

openclaw plugins inspect codex

If logs mention auth/OAuth/API key, don’t paste tokens. Just paste the error text around it. My guess now is either Codex auth/model setup is waiting/failing, or the plugin installed but the harness is hanging during startup.

[spare surge]

OpenClaw status --all
2026.5.12
OS linux 6.6.114.1-microsoft-standard-WSL2 (x64)
Node 24.15.0
Config ~/.openclaw/openclaw.json
Dashboards http://172.30.67.174:18789/
Tailscale exposure off
Channel stable (default)
Update pnpm · up to date · npm latest 2026.5.12
Gateway local · ws://127.0.0.1:18789 (local loopback) · reachable 48ms · auth token ·,DESKTOP-I238VPJ
(172.30.67.174) app 2026.5.12 linux 6.6.114.1-microsoft-standard-WSL2
Security Run: openclaw security audit --deep
Gateway self unknown
Gateway service systemd user installed · enabled · running (pid 5950, state active)
Node service systemd user not installed
Agents 1 total · 1 bootstrapping · 1 active · 1 sessions
Secrets none
Channels
Channel Enabled Stated Detail
Agents
Agent Bootstrap file Sessions Active Store
main PRESENT 1 7m ago ~/.openclaw/agents/main/sessions/sessions.json Diagnosis (read-only
Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/jdely3/.openclaw/openclaw.json
Bind: lan
✓ Config: /home/jdely3/.openclaw/openclaw.json
✓ Secret diagnostics (0
✓ Restart sentinel: none
✓ Port 18789
Detected OpenClaw Gateway listener on the configured port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 8 eligible · 0 missing · /home/jdely3/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)
Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting
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): -
Missing auth

• openai Run openclaw models auth login --provider openai, openclaw configure, or set an API key env var.
  OAuth/token status
• none

[vital dagger]

Found the blocker in that status output: Missing auth → openai. The dashboard is loading because the agent is trying to run with no usable OpenAI/Codex auth.

Pick one auth path:

openclaw models auth login --provider openai-codex

or, if you’re using an OpenAI API key instead:

openclaw configure --section model

After auth finishes:

[vital dagger]

openclaw models status
openclaw gateway restart

Then refresh the dashboard and try again.

One more thing: your status says Agent Bootstrap file PRESENT. That can be normal before the first successful run, but if it still says bootstrapping after auth is fixed, we’ll clear the leftover bootstrap state next. For now, auth is the main blocker.

Docs: https://docs.openclaw.ai/providers/openai and https://docs.openclaw.ai/concepts/models

[spare surge]

OpenClaw 2026.5.12 (f066dd2) — I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

│
◇ OpenAI Codex OAuth ─────────────────────────────────────────────╮
│ │
│ Browser will open for OpenAI authentication. │
│ If the callback doesn't auto-complete, paste the redirect URL. │
│ OpenAI OAuth uses localhost:1455 for the callback. │
│ │
├──────────────────────────────────────────────────────────────────╯
│
Open: https://auth.openai.com/oauth/authorize?response_type=code&client_id=app_EMoamEEZ73f0CkXaXp7hrann&redirect_uri=http%3A%2F%2Flocalhost%3A1455%2Fauth%2Fcallback&scope=openid+profile+email+offline_access&code_challenge=TjO4e16WsAkmkAJExTccwkHWeDtgvazWlzfBgbfiueQ&code_challenge_method=S256&state=b8774edb35113a8f0f749365bc4de9a7&id_token_add_organizations=true&codex_cli_simplified_flow=true&originator=openclaw
OpenAI Codex OAuth callback did not arrive within 15000ms; switching to manual entry (callback_timeout).
◇ Manual OAuth entry required
│
◆ Paste the authorization code (or full redirect URL):
│ _
└

[vital dagger]

That’s expected in WSL: the browser is on Windows, but the OAuth callback listener is inside Ubuntu on localhost:1455, so the auto-callback may not land.

Do this:

1. Open that long https://auth.openai.com/... URL in your browser.
2. Finish the OpenAI login/authorize flow.
3. When the browser redirects to a page that may fail to load, copy the full address bar URL. It should look like:

http://localhost:1455/auth/callback?code=...&state=...

4. Paste that full redirect URL back into the Ubuntu terminal at:

Paste the authorization code (or full redirect URL):

[vital dagger]

Do not paste that redirect URL here in Discord; it contains a login code.

If your browser never reaches a localhost:1455/auth/callback?... URL, rerun using device-code mode instead:

openclaw models auth login --provider openai-codex --device-code

[spare surge]

Paste the authorization code (or full redirect URL):
│ _
└
Config overwrite: /home/jdely3/.openclaw/openclaw.json (sha256 52a40df9ed68d115c01529b0acbe4dfeee7019ebad7cb512dd47ddafe418b1ab -> 6f42513a6d5b04dd38b8a040697e3fbcd259c8e2cb13269d2ca167b33658127f, backup=/home/jdely3/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Auth profile: openai-codex:[e-mail] (openai-codex/oauth)
Default model available: openai/gpt-5.5 (use --set-default to apply)
Tip: Codex-capable models can use native Codex web search. Enable it with openclaw configure --section web (recommended mode: cached). Docs: https://docs.openclaw.ai/tools/web

[vital dagger]

Nice, auth succeeded. Now apply it and restart:

openclaw models status
openclaw gateway restart

Then refresh the dashboard and send a test message.

If it still spins, paste:

openclaw status --all
openclaw logs --follow

One thing to watch: if status --all still says Agent Bootstrap file PRESENT after the first successful reply attempt, the agent may be stuck in first-run bootstrapping. But try after the auth + restart first.

[spare surge]

I cant command somthing I can only type hereConfig overwrite: /home/jdely3/.openclaw/openclaw.json (sha256 52a40df9ed68d115c01529b0acbe4dfeee7019ebad7cb512dd47ddafe418b1ab -> 6f42513a6d5b04dd38b8a040697e3fbcd259c8e2cb13269d2ca167b33658127f, backup=/home/jdely3/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Auth profile: openai-codex:[e-mail] (openai-codex/oauth)
Default model available: openai/gpt-5.5 (use --set-default to apply)
│ _ mode: cached). Docs: https://docs.openclaw.ai/tools/web

[vital dagger]

That terminal looks wedged after the OAuth flow, but auth succeeded. Don’t keep fighting that same terminal.

Do this:

1. Press Ctrl+C once.
2. If you still don’t get a normal prompt like jdely3@DESKTOP...:~$, close that Ubuntu terminal window.
3. Open a new Ubuntu terminal from Windows/Start Menu.
4. Run:

openclaw gateway restart
openclaw models status

Then refresh the dashboard and test again.

If you truly cannot open a new terminal at all, just try refreshing the dashboard first. The auth was written successfully, so it may work once the gateway picks up the config, but a restart is the cleaner step.

[spare surge]

Config overwrite: /home/jdely3/.openclaw/openclaw.json (sha256 52a40df9ed68d115c01529b0acbe4dfeee7019ebad7cb512dd47ddafe418b1ab -> 6f42513a6d5b04dd38b8a040697e3fbcd259c8e2cb13269d2ca167b33658127f, backup=/home/jdely3/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Auth profile: openai-codex:[e-mail] (openai-codex/oauth)
■ Paste the authorization code (or full redirect URL):
│
└ Setup cancelled.

[vital dagger]

That’s okay. The important line is:

Auth profile: openai-codex:[e-mail] (openai-codex/oauth)

So the auth profile was created before you cancelled the leftover prompt.

Open a new Ubuntu terminal and run:

openclaw models status
openclaw gateway restart

If models status shows OpenAI/Codex auth present, refresh the dashboard and test again.

[vital dagger]

If it still says missing auth, run the device-code login path instead, which avoids the localhost callback mess in WSL:

openclaw models auth login --provider openai-codex --device-code

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ openclaw models status
openclaw gateway restart

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

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 (1): openai/gpt-5.5

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

• openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:[e-mail]=OAuth ([e-mail])

OAuth/token status

• openai-codex usage: 168h 97% left ⏱6d 23h
  • openai-codex:[e-mail] ([e-mail]) ok expires in 10d

🦞 OpenClaw 2026.5.12 (f066dd2) — Finally, a use for that always-on Mac Mini under your desk.

Restarted systemd service: openclaw-gateway.service

[vital dagger]

Great, auth is healthy now. Refresh the dashboard and send one short test message.

If it works, you’re past the main blockers.

If it still hangs/fails, the next thing I want is the new runtime error after auth:

openclaw logs --follow

Start that, send the dashboard test message, wait ~20 seconds, then Ctrl+C and paste the relevant warning/error lines. Also run this if it keeps bootstrapping:

openclaw status --all

We’re down to either a successful first bootstrap, or one remaining bootstrap/Codex runtime issue.

[spare surge]

openclaw said this after 30 seconds Hey. I’m here now.

Looks like this is still a fresh workspace, so I should get properly set up: what should I call you, and what should you call me?

[vital dagger]

That means it’s working now. 🎉

OpenClaw is doing its first-run bootstrap. Answer it naturally in the dashboard, for example:

Call me Jason. You can call yourself OpenClaw.

After that it should finish setting up its workspace and normal replies should start. If it asks a couple more identity/setup questions, answer them; that’s the bootstrapping step that status --all showed earlier.

Once you get a normal reply, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes the fix for future WSL users.

[spare surge]

How can I get the qwen models I have installed on

[vital dagger]

If those Qwen models are installed in Ollama, the path is:

ollama list
openclaw configure --section model

In the model setup, choose Ollama, then Local only or Cloud + Local, and use the Ollama base URL:

http://127.0.0.1:11434

After that:

[vital dagger]

openclaw models list --provider ollama
openclaw models set ollama/<exact-model-name-from-ollama-list>
openclaw gateway restart

Example shape only, don’t copy unless it matches your ollama list output:

openclaw models set ollama/qwen3.5:27b

Important: for Ollama, don’t use http://127.0.0.1:11434/v1; OpenClaw’s docs say to use the native Ollama URL with no /v1 because /v1 can break tool calling.

Docs: https://docs.openclaw.ai/providers/ollama and https://docs.openclaw.ai/concepts/models

If they’re installed somewhere else, like LM Studio, vLLM, or llama.cpp, tell me which one and I’ll give the right provider config.

[spare surge]

can i ask openclaw to make a mission control center that looks like a video game

[vital dagger]

Yep. That’s a very reasonable OpenClaw task: ask it to build an actual web app/dashboard, not just describe one.

A good prompt would be something like:

Build me a mission control dashboard web app that feels like a sci-fi video game UI. It should have panels for active agents, tasks, logs, alerts, system health, and a command console. Make it usable, not just decorative. Use the existing project stack if there is one; otherwise create a simple React/Vite app. Start a dev server when done and give me the local URL.

If you want it connected to real OpenClaw state, be specific about the data source: gateway status, sessions, cron jobs, Discord/Telegram messages, node health, etc. Otherwise it’ll probably make a slick mock dashboard with fake data, which can still be useful as a prototype.

[spare surge]

how do i get back into the dashboard once I close it and get back to the conversation

[vital dagger]

Run this from the machine where OpenClaw is installed:

openclaw dashboard

That reopens the Control UI with the right gateway/auth info. If you only want the URL printed instead of auto-opening a browser:

openclaw dashboard --no-open

If the gateway is local, the dashboard is usually at http://127.0.0.1:18789/, but openclaw dashboard is better because it handles your configured auth/token path.

Closing the browser tab should not stop the Gateway or erase the chat/session. Reopen the dashboard, then check the chat/session view. If it doesn’t reconnect, run:

[vital dagger]

openclaw --version
openclaw gateway status
openclaw status

Docs: https://docs.openclaw.ai/cli/dashboard and https://docs.openclaw.ai/start/faq

[spare surge]

If i switch the model will it forget our conversation

[vital dagger]

Usually: no, switching models should not wipe the OpenClaw conversation history/session by itself.

But the new model may behave like it remembers less if it has a smaller context window, weaker instruction-following, or different tool behavior. The saved chat/session is still there; the question is how much of it OpenClaw can fit/send to the new model and how well that model uses it.

A practical move: before switching, ask the current agent to summarize the important context/goal, then switch models and paste or reference that summary if needed.

For model setup guidance, use the docs and #models for current community experience:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

[spare surge]

Since my local model is not running on my gpu or cpu what is it running on

[vital dagger]

If it is truly a local model, it has to be running on some compute: CPU, GPU, Apple Neural Engine/Metal, or another machine on your LAN/VPS. If you’re seeing no CPU/GPU load on your box, the most likely explanations are:

• OpenClaw is actually using a cloud/API provider, not the local model.
• The local model server is on a different machine/node.
• The model server is idle because OpenClaw is not sending requests to it.
• You’re checking the wrong process/device monitor.

Quick checks:

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

If you’re using Ollama, also check:

[vital dagger]

ollama ps

On Linux/NVIDIA, check GPU activity with:

nvidia-smi

On macOS, local inference often shows under CPU/GPU/Metal activity rather than a neat “model is running here” label.

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

Also worth asking in #models with your openclaw --version, model provider config, and what local server you’re using. The local model path varies a lot by backend.

[spare surge]

My openclaw is stuck loading on a command

[vital dagger]

First thing: what does this show?

openclaw --version

Then run these and paste the relevant output:

openclaw status
openclaw gateway status
openclaw logs --follow

If it’s stuck in the dashboard/chat on a command, try stopping that run from the UI first. If the whole gateway looks wedged, restart it:

[vital dagger]

openclaw gateway restart

If it keeps happening, include which command is stuck, whether you’re using a local model or cloud model, and the last 30-ish log lines. Docs for the basic debug loop: https://docs.openclaw.ai/start/faq

[spare surge]

Its still loading after the restart

[vital dagger]

Ok, then the restart didn’t clear the underlying cause. Next we need the diagnostics, especially version + logs.

Please run:

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

Then in a second terminal, start logs, trigger the stuck command again, wait ~20 seconds, and copy the last error-ish lines:

openclaw logs --follow

[vital dagger]

Things I’d look for in the output:

• model/auth problem: requests start but never get a model response
• dashboard auth/connect problem: AUTH_TOKEN_*, PAIRING_REQUIRED, origin not allowed, device identity required
• local model problem: OpenClaw is waiting on Ollama/LM Studio/etc.
• stuck old session/run: UI shows loading but Gateway is otherwise healthy

If the dashboard itself is stuck loading, reopen it with:

openclaw dashboard

Docs for this debug path: https://docs.openclaw.ai/start/faq and https://docs.openclaw.ai/gateway/troubleshooting

[spare surge]

05:28:42+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=9894 error="You've reached your Codex subscription usage limit. Next reset in 7 days, May 22 at 6:29 PM EDT. Run /codex account for current usage details."
05:28:42+00:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:main durationMs=9896 error="You've reached your Codex subscription usage limit. Next reset in 7 days, May 22 at 6:29 PM EDT. Run /codex account for current usage details."
05:28:42+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"c9e1f34d-7b2c-458c-a090-c4ffa2c92383","sessionId":"e9faa74a-aa74-4534-a6f6-d8612bfd1bf2","lane":"main","decision":"candidate_failed","requestedProvider":"openai","requestedModel":"gpt-5.5","candidateProvider":"openai","candidateModel":"gpt-5.5","attempt":1,"total":1,"reason":"rate_limit","status":429,"errorPreview":"You've reached your Codex subscription usage limit. Next reset in 7 days, May 22 at 6:29 PM EDT. Run /codex account for current usage details.","errorHash":"sha256:60d3984cd322","fallbackStepType":"fallback_step","fallbackStepFromModel":"openai/gpt-5.5","fallbackStepFromFailureReason":"rate_limit","fallbackStepFromFailureDetail":"You've reached your Codex subscription usage limit. Next reset in 7 days, May 22 at 6:29 PM EDT. Run /codex account for current usage details.","fallbackStepChainPosition":1,"fallbackStepFinalOutcome":"chain_exhausted","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":false} model fallback decision
05:28:42+00:00 error Embedded agent failed before reply: You've reached your Codex subscription usage limit. Next reset in 7 days, May 22 at 6:29 PM EDT. Run /codex account for current usage details.
05:30:43+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 102ms conn=3caa651c…e08c id=5c258e87

[vital dagger]

That log explains it: OpenClaw isn’t stuck on loading anymore; the selected model/backend is failing before it can reply.

The key line is:

You've reached your Codex subscription usage limit ... fallbackConfigured=false

So OpenClaw tried openai/gpt-5.5, hit a Codex subscription limit, then had no fallback model configured. The UI can look like it’s just loading because the agent dies before producing a reply.

What to do:

/codex account
openclaw models status

[vital dagger]

Then either wait for the Codex reset, or switch OpenClaw to another configured model/provider that has working auth/quota. After switching, try the command again. I won’t recommend a specific model here because availability changes fast; #models is the best place for current picks.

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

[spare surge]

can i do the one ive been using

[vital dagger]

Yes, if “the one you’ve been using” is still configured and has working auth/quota, you can switch back to it.

In the chat/dashboard, use:

/model

or:

/model list
/model <number from the list>

From terminal you can also check what OpenClaw sees:

[vital dagger]

openclaw models status
openclaw models list

If you know the exact ref, set it globally with:

openclaw models set <provider/model>

The important bit from your log is that openai/gpt-5.5 is quota-limited and fallbackConfigured=false, so pick a model that openclaw models status says is authenticated/available. Docs: https://docs.openclaw.ai/concepts/models

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ /model
-bash: /model: No such file or directory
jdely3@DESKTOP-I238VPJ:~$ /model list
/model <number from the list>
-bash: /model: No such file or directory
-bash: syntax error near unexpected token `newline'

[vital dagger]

Ah, that one is my bad for not separating the two paths clearly.

/model is a chat/dashboard slash command. Type it into the OpenClaw chat box, not your Linux terminal.

In the terminal, use the openclaw models ... commands instead:

openclaw models status
openclaw models list
openclaw models set <provider/model>

So the flow is:

1. Run this in terminal:

[vital dagger]

openclaw models list

2. Pick one of the listed provider/model values.

3. Set it, for example:

openclaw models set provider/model

Replace provider/model with the exact value from your list. Don’t include the angle brackets; those just meant “put your model here.”

[spare surge]

i did

[vital dagger]

Good. Now verify OpenClaw is actually pointing at the new one:

openclaw models status

Look for the primary/resolved model. If it no longer says openai/gpt-5.5, try the dashboard command again.

If it still loads forever, run logs while you try it:

openclaw logs --follow

The next useful thing is the new error line. If it says quota/rate limit again, the new model/provider also isn’t usable yet; if it says auth missing, you’ll need to configure auth for that provider.

[spare surge]

I've ne unconnected from the dashboard now

[vital dagger]

If the dashboard disconnected after the model change, first reopen it cleanly:

openclaw dashboard

If it opens but won’t connect, run:

openclaw gateway status
openclaw status

If the gateway is running, it may just be dashboard auth/token drift. openclaw dashboard should generate/open the right URL. If it still says disconnected, restart once more and reopen:

[vital dagger]

openclaw gateway restart
openclaw dashboard

If that still fails, paste the exact dashboard message plus the output of:

openclaw --version
openclaw gateway status

[spare surge]

Service: systemd user (enabled)
File logs: /tmp/openclaw/openclaw-2026-05-16.log
Command: /usr/bin/node /home/jdely3/.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://172.30.67.174:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

CLI version: 2026.5.12 (~/.npm-global/bin/openclaw)
Gateway version: 2026.5.12

Runtime: running (pid 14064, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: read-only

[vital dagger]

That status is mostly good: the Gateway is running and the local probe is OK. So this is probably a dashboard browser/auth/origin issue, not the Gateway being down.

Try this exact path first on the same machine:

openclaw dashboard

If it gives you a URL, use that URL. If you’re opening manually on the same machine, prefer:

http://127.0.0.1:18789/

instead of the LAN URL http://172.30.67.174:18789/. The LAN URL can hit stricter browser/origin/device-auth behavior.

If the dashboard asks for auth, paste your gateway token/password into the dashboard auth field, but don’t paste the token here. To inspect what mode you’re using:

[vital dagger]

openclaw config get gateway.auth.mode

If it still says disconnected, run this while refreshing the dashboard and paste only the error lines:

openclaw logs --follow

Look for things like AUTH_TOKEN_MISSING, AUTH_TOKEN_MISMATCH, PAIRING_REQUIRED, origin not allowed, or device identity required.

[spare surge]

Log file: /tmp/openclaw/openclaw-2026-05-16.log
05:35:42+00:00 info Updated ~/.openclaw/openclaw.json
05:35:42+00:00 info Default model: openai/gpt-5.5
05:35:43+00:00 info gateway/reload {"subsystem":"gateway/reload"} config change detected; evaluating reload (meta.lastTouchedAt, agents.defaults.model)
05:35:43+00:00 info gateway/reload {"subsystem":"gateway/reload"} config hot reload applied (agents.defaults.model)
05:36:47+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1001 reason=n/a conn=c02848f3-fabd-45a0-aea5-c970ec825fc8
05:36:47+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"origin-mismatch","handshake":"failed","durationMs":17,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"3a7d8ca7-b095-46f0-903e-24591cf8eda9","host":"127.0.0.1:18789","origin":"http://127.0.0.1:18789","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36","remoteAddr":"172.30.64.1","remotePort":63384,"localAddr":"172.30.67.174","localPort":18789,"endpoint":"172.30.64.1:63384->172.30.67.174:18789","reason":"origin not allowed","client":"openclaw-control-ui","mode":"webchat","version":"2026.

[vital dagger]

Yep, there’s the exact failure:

origin-mismatch ... reason="origin not allowed"

You’re on WSL/Windows-ish networking: the browser says Origin: http://127.0.0.1:18789, but the gateway sees the connection coming over the WSL LAN address, so it rejects it.

Add the local dashboard origins explicitly:

openclaw config set gateway.controlUi.allowedOrigins '["http://127.0.0.1:18789","http://localhost:18789","http://172.30.67.174:18789"]' --strict-json
openclaw gateway restart
openclaw dashboard

Then refresh the dashboard. If 172.30.67.174 changes later, run openclaw gateway status again and add the new dashboard URL origin too.

[vital dagger]

Also: your log says the default model is still openai/gpt-5.5, so once the dashboard reconnects you’ll still need to switch away from that quota-limited model or it’ll fail before reply again.

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

[spare surge]

What should i do

[vital dagger]

Do these in order:

1. Fix the dashboard disconnect:

openclaw config set gateway.controlUi.allowedOrigins '["http://127.0.0.1:18789","http://localhost:18789","http://172.30.67.174:18789"]' --strict-json
openclaw gateway restart
openclaw dashboard

2. Once the dashboard opens again, fix the model issue. In terminal run:

openclaw models status
openclaw models list

[vital dagger]

Pick a model from the list that is not openai/gpt-5.5, then set it like:

openclaw models set provider/model

Replace provider/model with the exact value from your list.

3. Try your dashboard message again.

If step 1 fails, paste the new origin not allowed log line. If step 3 fails, paste the new model error line. You have two separate issues: dashboard origin allowlist, then Codex quota.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ openclaw models set provider/model

🦞 OpenClaw 2026.5.12 (f066dd2) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

Config overwrite: /home/jdely3/.openclaw/openclaw.json (sha256 7994bde672107a613063aa997ba0b4d617a96401a2e7afa376d6eed09e43634a -> fcd7cfc1c2f182c852d2566dd271f403a0fd261f988571b0fdc8a77edef6c7dc, backup=/home/jdely3/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Default model: provider/model

[vital dagger]

You accidentally set the literal placeholder provider/model as your model. We need to replace it with a real one from your list.

Run:

openclaw models list

Copy one exact entry from that output, then run:

openclaw models set THE_EXACT_ENTRY

For example, if the list showed ollama/llama3.1, you would run:

[vital dagger]

openclaw models set ollama/llama3.1

Don’t use provider/model unless that exact text appears in the model list, which it won’t.

To undo the bad setting right now, either set a real model from the list, or restore the backup OpenClaw just made:

cp ~/.openclaw/openclaw.json.bak ~/.openclaw/openclaw.json
openclaw gateway restart

Setting a real model is better if you have one available.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ openclaw models list

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

Model Input Ctx Local Auth Tags
provider/model text 195k no no default,configured
openai/gpt-5.5 text 195k no yes configured

[vital dagger]

Ok, that list means you do not currently have another usable model configured.

You have:

provider/model     Auth: no   ← accidental placeholder
openai/gpt-5.5     Auth: yes  ← real, but quota-limited right now

So do this:

1. Restore the config backup to remove the accidental placeholder:

cp ~/.openclaw/openclaw.json.bak ~/.openclaw/openclaw.json
openclaw gateway restart

[vital dagger]

2. Add/configure the model you actually want to use:

openclaw onboard

or use the model config flow:

openclaw configure --section model

3. Check again:

openclaw models status

[vital dagger]

openclaw models list

Right now OpenClaw has no working fallback away from your Codex-limited openai/gpt-5.5. If you were using Ollama/LM Studio/local before, it needs to be added back so it appears in openclaw models list with the real provider/model name.

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

[spare surge]

Where will the Gateway run?
│ ● Local (this machine) (Gateway reachable (ws://127.0.0.1:18789))
│ ○ Remote (info-only)

[vital dagger]

Choose Local (this machine).

Your status showed the Gateway service is already running locally on port 18789, so that’s the right option. Remote would be for connecting this machine to a Gateway running somewhere else.

[spare surge]

Model/auth provider
│ ● Anthropic (Claude CLI + API key)
│ ○ Google
│ ○ OpenAI
│ ○ xAI (Grok)
│ ○ More…
│ ○ Skip for now

[vital dagger]

Pick the provider you actually have working auth for.

Given your Codex/OpenAI quota is exhausted, don’t pick OpenAI unless you have a separate API key/quota you want to use.

If you have Claude/Anthropic available, choose Anthropic. If your “one I’ve been using” was a local model like Ollama or LM Studio, choose More… and look for the local/provider option there.

Don’t choose Skip for now, because right now you need to add another usable model.

[spare surge]

Model/auth provider
│ Ollama
│
◆ Ollama mode
│ ● Cloud + Local (Route cloud and local models through your Ollama host)
│ ○ Cloud only
│ ○ Local only

[vital dagger]

Choose Local only if the model you’ve been using is running on your own Ollama install.

Choose Cloud + Local only if you intentionally use Ollama’s cloud routing too. Since you’re trying to avoid the exhausted cloud/Codex path, Local only is the cleaner choice.

If Ollama is running in the same WSL/Linux environment as OpenClaw, keep that default:

http://127.0.0.1:11434

If Ollama is running on Windows outside WSL, 127.0.0.1 from OpenClaw may point at WSL instead of Windows. In that case you may need the Windows host address from WSL. Quick check in a terminal:

curl http://127.0.0.1:11434/api/tags

If that returns JSON/model tags, the default is correct. If it fails, say so and we’ll point it at the Windows host IP.

[spare surge]

Ollama ─────────────────────────────────────────────────╮
│ │
│ Ollama could not be reached at http://127.0.0.1:11434. │
│ Download it at https://ollama.com/download │
│ │
│ Start Ollama and re-run setup. │
│

[vital dagger]

That means OpenClaw cannot see an Ollama server at 127.0.0.1:11434 from where the Gateway is running.

If Ollama is installed in Windows, but OpenClaw is running in WSL, try the Windows host IP from WSL:

WINDOWS_HOST=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
echo $WINDOWS_HOST
curl http://$WINDOWS_HOST:11434/api/tags

If that returns JSON, re-run setup and use:

http://<that-ip>:11434

If it still fails, start Ollama on Windows first, then make sure Ollama is allowed to listen beyond Windows localhost. In PowerShell before starting Ollama, this is commonly needed:

[vital dagger]

$env:OLLAMA_HOST="0.0.0.0:11434"
ollama serve

If you installed Ollama inside WSL instead, start it there:

ollama serve

Then http://127.0.0.1:11434 should work.

[spare surge]

WINDOWS_HOST=$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf)
echo $WINDOWS_HOST
curl http://$WINDOWS_HOST:11434/api/tags
10.255.255.254
curl: (7) Failed to connect to 10.255.255.254 port 11434 after 0 ms: Could not connect to server

[vital dagger]

That confirms OpenClaw/WSL can’t reach Ollama at either WSL localhost or the Windows host IP. So Ollama is either not running, only bound to Windows localhost, or blocked by firewall.

On Windows, open PowerShell and run:

ollama list
$env:OLLAMA_HOST="0.0.0.0:11434"
ollama serve

Leave that PowerShell window open. Then back in WSL run:

curl http://10.255.255.254:11434/api/tags

If that works, use this in OpenClaw setup:

[vital dagger]

http://10.255.255.254:11434

If PowerShell says Ollama is already running, fully quit the Ollama tray app first, then run the PowerShell commands again. If curl still fails after that, Windows Firewall is probably blocking WSL-to-Windows access on port 11434; allow Ollama/port 11434 on private networks.

Alternative simpler path: install/start Ollama inside WSL, then use http://127.0.0.1:11434.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ curl http://10.255.255.254:11434/api/tags
curl: (7) Failed to connect to 10.255.255.254 port 11434 after 0 ms: Could not connect to server

[vital dagger]

Right, so WSL still cannot reach Ollama. Don’t continue OpenClaw setup until this curl works.

Do one of these two paths:

Path A: run Ollama inside WSL

curl -fsSL https://ollama.com/install.sh | sh
ollama serve

Open a second WSL terminal and test:

curl http://127.0.0.1:11434/api/tags

[vital dagger]

Then use http://127.0.0.1:11434 in OpenClaw.

Path B: run Windows Ollama in network-listening mode

In Windows PowerShell, quit the Ollama tray app first if it’s running, then:

$env:OLLAMA_HOST="0.0.0.0:11434"
ollama serve

Leave it open, then in WSL test again:

curl http://10.255.255.254:11434/api/tags

[vital dagger]

If Path B still fails, Windows Firewall is blocking it. Path A is usually less annoying for WSL + OpenClaw.

[spare surge]

neither worked

[vital dagger]

Ok, then we need to split “Ollama not installed/started” from “network can’t reach it.” Please run these in WSL and paste the output:

which ollama
ollama --version
ps aux | grep '[o]llama'
curl -v http://127.0.0.1:11434/api/tags

If which ollama is empty or ollama --version fails, Ollama is not installed inside WSL.

If ollama serve failed, paste that exact error too. Common causes are: another Ollama already owns the port, the install didn’t finish, or WSL/service environment isn’t starting it.

For now, in the OpenClaw setup, don’t pick Ollama unless one of these works:

[vital dagger]

curl http://127.0.0.1:11434/api/tags
curl http://10.255.255.254:11434/api/tags

No working curl = OpenClaw cannot use Ollama yet.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ which ollama
ollama --version
ps aux | grep '[o]llama'
curl -v http://127.0.0.1:11434/api/tags
Command 'ollama' not found, but can be installed with:
sudo snap install ollama

• Trying 127.0.0.1:11434...
• connect to 127.0.0.1 port 11434 from 127.0.0.1 port 38762 failed: Connection refused
• Failed to connect to 127.0.0.1 port 11434 after 0 ms: Could not connect to server
• closing connection #0
  curl: (7) Failed to connect to 127.0.0.1 port 11434 after 0 ms: Could not connect to server

[vital dagger]

That’s the cause: Ollama is not installed/running inside WSL, and nothing is listening on 127.0.0.1:11434.

Install Ollama in WSL with the official installer, not snap:

curl -fsSL https://ollama.com/install.sh | sh

Then start it:

ollama serve

Leave that terminal open. In a second WSL terminal, verify:

[vital dagger]

curl http://127.0.0.1:11434/api/tags

If it returns JSON, re-run OpenClaw setup and choose:

Ollama → Local only → http://127.0.0.1:11434

You’ll also need at least one model pulled in Ollama, for example:

ollama pull <model-name>

Pick a model your machine can actually run; #models is better for current local-model recommendations.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ curl -fsSL https://ollama.com/install.sh | sh

Cleaning up old version at /usr/local/lib/ollama

Installing ollama to /usr/local
ERROR: This version requires zstd for extraction. Please install zstd and try again:

• Debian/Ubuntu: sudo apt-get install zstd
• RHEL/CentOS/Fedora: sudo dnf install zstd
• Arch: sudo pacman -S zstd

[vital dagger]

Install the missing extractor, then rerun the Ollama installer:

sudo apt-get update
sudo apt-get install -y zstd
curl -fsSL https://ollama.com/install.sh | sh

After that:

ollama serve

Then in another WSL terminal:

[vital dagger]

curl http://127.0.0.1:11434/api/tags

If that works, OpenClaw can use Ollama at http://127.0.0.1:11434.

Good, that means Ollama is installed and something is already listening on port 11434. It may already be running now.

Test it:

curl http://127.0.0.1:11434/api/tags

If that returns JSON, you’re good. Re-run OpenClaw setup and use:

http://127.0.0.1:11434

If curl still fails, find what owns the port:

ss -ltnp | grep 11434
ps aux | grep '[o]llama'

If it shows an Ollama process, leave it alone. If it shows something else weird, paste that output.

[spare surge]

{"models":[]}jdely3@DESKTOP-I238VPJ:~$ http://127.0.0.1:11434
-bash: http://127.0.0.1:11434: No such file or directory

[vital dagger]

{"models":[]} is actually good: Ollama is reachable now. It just has no models downloaded yet.

Don’t type the URL directly into bash. URLs go into OpenClaw’s setup prompt, or you test them with curl.

Next, pull a model in WSL. For example:

ollama pull qwen2.5-coder:7b

Then verify it appears:

curl http://127.0.0.1:11434/api/tags

After that re-run OpenClaw model setup:

[vital dagger]

openclaw configure --section model

Choose:

Ollama → Local only → http://127.0.0.1:11434

When it asks for model, pick the model you pulled.

[spare surge]

Model/auth provider
│ Ollama
│
◇ Ollama mode
│ Local only
│
◇ Ollama base URL
│ http://127.0.0.1:11434

[vital dagger]

That looks right. Continue/confirm that screen.

If it asks you to pick a model and the list is empty, you still need to pull one first:

ollama pull qwen2.5-coder:7b

Then rerun the model setup. If a model appears, select it and finish the wizard. After setup, check:

openclaw models list
openclaw models status

[spare surge]

Remove these provider models from the /model picker?
│ ○ Yes / ● No

[vital dagger]

Choose No.

That keeps the existing provider models in the /model picker. You can clean them up later once Ollama is working, but right now we don’t need to remove anything while you’re recovering the setup.

[spare surge]

Config overwrite: /home/jdely3/.openclaw/openclaw.json (sha256 7994bde672107a613063aa997ba0b4d617a96401a2e7afa376d6eed09e43634a -> 84d27e5970f7b711d8ae60b54c43b51ed916e6996dce4b1ebc364fce4eb937e0, backup=/home/jdely3/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
│
◇ Control UI ───────────────────────────────────────────────────────────────────────────────╮
│ │
│ Web UI: http://172.30.67.174:18789/ │
│ Gateway WS: ws://172.30.67.174:18789 │
│ Gateway: not detected (connect failed: SECURITY ERROR: Cannot connect to "172.30.67.174" │
│ over plaintext ws://. Both credentials and chat data would be exposed to network │
│ interception. Use wss:// for remote URLs. Safe defaults: keep gateway.bind=loopback and │
│ connect via SSH tunnel (ssh -N -L 18789:127.0.0.1:18789 user@gateway-host), or use │
│ Tailscale Serve/Funnel. Break-glass (trusted private networks only): set │
│ OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1. Run openclaw doctor --fix for guidance.) │
│ Docs: https://docs.openclaw.ai/web/control-ui │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
└ Configuration updated.

[vital dagger]

That output says the config update finished. The scary part is the wizard trying to connect to the LAN URL over plain ws://172.30.67.174, which OpenClaw blocks for security.

Since this is all on your own machine/WSL, switch the Gateway back to loopback and use localhost:

openclaw config set gateway.bind '"loopback"' --strict-json
openclaw gateway restart
openclaw dashboard

Then open/use:

http://127.0.0.1:18789/

After that, check whether Ollama actually got added:

[vital dagger]

openclaw models list
openclaw models status

If the model list still only shows openai/gpt-5.5 and provider/model, then Ollama setup did not add a usable local model yet. You’ll need to pull a model first with ollama pull ..., then rerun openclaw configure --section model.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ http://172.30.67.174:18789/
-bash: http://172.30.67.174:18789/: No such file or directory

[vital dagger]

That URL goes in your web browser, not in the terminal.

But don’t use the LAN URL right now. In terminal run:

openclaw config set gateway.bind '"loopback"' --strict-json
openclaw gateway restart
openclaw dashboard

openclaw dashboard should open the browser for you. If it prints a URL instead, copy that URL into Chrome/Edge/Firefox, not bash.

Manual browser URL should be:

http://127.0.0.1:18789/

[spare surge]

what next

[vital dagger]

Next, do this exact checklist:

1. Get the dashboard reachable again:

openclaw config set gateway.bind '"loopback"' --strict-json
openclaw gateway restart
openclaw dashboard

Open http://127.0.0.1:18789/ in your browser if it doesn’t auto-open.

2. Make sure Ollama has a model:

ollama pull qwen2.5-coder:7b

[vital dagger]

curl http://127.0.0.1:11434/api/tags

The curl output should show that model, not {"models":[]}.

3. Configure OpenClaw to use Ollama:

openclaw configure --section model

Pick:

Ollama → Local only → http://127.0.0.1:11434 → qwen2.5-coder:7b

[vital dagger]

4. Verify:

openclaw models list
openclaw models status

You want to see an ollama/... model with auth/availability, and the default should not be the fake provider/model or quota-limited openai/gpt-5.5.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ curl http://127.0.0.1:11434/api/tags
{"models":[{"name":"qwen2.5-coder:7b","model":"qwen2.5-coder:7b","modified_at":"2026-05-16T01:58:50.23812398-04:00","size":4683087561,"digest":"dae161e27b0e90dd1856c8bb3209201fd6736d8eb66298e75ed87571486f4364","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"7.6B","quantization_level":"Q4_K_M"}}]}jdely3@DESKTOP-I238VPJ:~$

[vital dagger]

Great, Ollama is working and the model is downloaded.

Now run:

openclaw configure --section model

Choose:

Ollama
Local only
http://127.0.0.1:11434
qwen2.5-coder:7b

[vital dagger]

When it finishes, verify:

openclaw models list
openclaw models status

You want the default to be the Ollama/qwen model, not provider/model and not openai/gpt-5.5.

[spare surge]

this is the second time going through these prompts

[vital dagger]

Yeah, that’s frustrating. Skip the wizard now; you have enough info to set it directly.

Press Ctrl+C to exit the prompts, then run:

openclaw config set models.providers.ollama '{"apiKey":"ollama-local","baseUrl":"http://127.0.0.1:11434","api":"ollama"}' --strict-json --merge
openclaw models set ollama/qwen2.5-coder:7b
openclaw gateway restart
openclaw models status

If models status shows ollama/qwen2.5-coder:7b as the default/primary, reopen the dashboard:

openclaw dashboard

[vital dagger]

Also: if the fake provider/model still shows in openclaw models list, ignore it for now. The important thing is that the default is ollama/qwen2.5-coder:7b.

[spare surge]

WebSocket URL
ws://127.0.0.1:18789
Gateway Token
••••••••••••••••••••••••••••••••••••••••••••••••

Password (not stored)
optional

Connect
Could not connect
The browser could not complete the Gateway connection. Check the target and transport before retrying credentials.
Confirm the Gateway is running with openclaw status or openclaw gateway run.
Check the WebSocket URL and use wss:// when the Gateway is behind HTTPS/Tailscale Serve.
Reopen the dashboard with openclaw dashboard --no-open to recopy the current URL and auth details.
Raw error
Control UI auth docs
How to connect
Start the gateway on your host machine:
openclaw gateway run

Get a tokenized dashboard URL:
openclaw dashboard

Paste the WebSocket URL and token above, or open the tokenized URL directly.
Read the docs →

[vital dagger]

The dashboard page is loading, but the WebSocket connect is failing. Next useful thing is the Gateway log line from the failed click.

In WSL, run:

openclaw gateway status
openclaw dashboard --no-open
openclaw logs --follow

Then click Connect in the dashboard once, and paste the new warning/error line from the logs.

Also, use the URL/token from openclaw dashboard --no-open instead of manually filling the token if possible. If the token in the browser is from before you restored/rewrote config, it may be stale.

Quick local check too:

[vital dagger]

curl -I http://127.0.0.1:18789/

If that works in WSL but the browser still can’t connect, it’s probably WSL ↔ Windows localhost forwarding/auth/origin, and the log line will tell us which one.

[spare surge]

Could not connect
The browser could not complete the Gateway connection. Check the target and transport before retrying credentials.
Confirm the Gateway is running with openclaw status or openclaw gateway run.
Check the WebSocket URL and use wss:// when the Gateway is behind HTTPS/Tailscale Serve.
Reopen the dashboard with openclaw dashboard --no-open to recopy the current URL and auth details.
Raw error
Control UI auth docs

[vital dagger]

I need the actual error behind that screen now. The dashboard text is generic; the Gateway log will say whether it’s token, origin, bind, or WSL networking.

Please run this in WSL:

openclaw gateway status
openclaw dashboard --no-open
openclaw logs --follow

Then click Connect once in the dashboard and paste the newest warn gateway/ws or error line.

Also click/expand Raw error in the dashboard if it shows anything and paste that. Without that line we’re guessing, and you’ve already done enough loop-de-loops here.

[spare surge]

jdely3@DESKTOP-I238VPJ:~$ openclaw gateway status
openclaw dashboard --no-open
openclaw logs --follow

🦞 OpenClaw 2026.5.12 (f066dd2) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.

│
◇
Service: systemd user (enabled)
File logs: /tmp/openclaw/openclaw-2026-05-16.log
Command: /usr/bin/node /home/jdely3/.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.

CLI version: 2026.5.12 (~/.npm-global/bin/openclaw)
Gateway version: 2026.5.12

Runtime: running (pid 18593, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: read-only

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

🦞 OpenClaw 2026.5.12 (f066dd2) — Half butler, half debugger, full crustacean.

Dashboard URL: http://127.0.0.1:18789/
Token auto-auth included in browser/clipboard URL.
Copied to clipboard.
Browser launch disabled (--no-open). Token-authenticated URL copied to clipboard.

[vital dagger]

Gateway is healthy now. The important lines are:

Gateway: bind=loopback (127.0.0.1)
Connectivity probe: ok
Dashboard URL: http://127.0.0.1:18789/
Token-authenticated URL copied to clipboard.

Next:

1. Open your Windows browser.
2. Paste from clipboard into the address bar. Don’t type http://127.0.0.1:18789/ manually if possible, because the copied URL includes the auth token.
3. If it opens the auth screen anyway, paste the Gateway Token that openclaw dashboard --no-open copied/provided, then click Connect.

If it still says “Could not connect”, keep this running:

[vital dagger]

openclaw logs --follow

Then click Connect once and paste the new warn gateway/ws or error line that appears. The status output says the Gateway itself is fine, so the remaining issue is specifically browser-to-WSL connection/auth.

[spare surge]

Could not connect
The browser could not complete the Gateway connection. Check the target and transport before retrying credentials.
Confirm the Gateway is running with openclaw status or openclaw gateway run.
Check the WebSocket URL and use wss:// when the Gateway is behind HTTPS/Tailscale Serve.
Reopen the dashboard with openclaw dashboard --no-open to recopy the current URL and auth details.

[vital dagger]

The page is loading, so HTTP works. The failing part is the WebSocket handshake, and we need one more concrete signal.

Do this exactly:

1. In WSL, start logs and leave it running:

openclaw logs --follow

2. In the browser, click Connect once.

3. Copy the new line that appears in the terminal. It should say warn gateway/ws or error.

If no new log line appears at all, try opening the copied dashboard URL in a fresh Incognito/Private window, and try localhost instead of 127.0.0.1:

[vital dagger]

http://localhost:18789/

If that still gives no log line, Windows is not actually getting the WebSocket through to WSL even though the page loads. Then the clean fix is to stop using Windows browser localhost forwarding and use a proper tunnel/Tailscale path. But first, the log line will tell us if it’s auth/origin versus routing.

[spare surge]

Could not connect
The browser could not complete the Gateway connection. Check the target and transport before retrying credentials.
Confirm the Gateway is running with openclaw status or openclaw gateway run.
Check the WebSocket URL and use wss:// when the Gateway is behind HTTPS/Tailscale Serve.
Reopen the dashboard with openclaw dashboard --no-open to recopy the current URL and auth details.
Raw error
Control UI auth docs

Auth required
The Gateway is reachable, but it needs a matching token or password before this browser can connect.
Paste the token from openclaw dashboard --no-open or enter the configured password.
If no token is configured, run openclaw doctor --generate-gateway-token on the gateway host.
Click Connect again after updating the credential.

[vital dagger]

That screen is still the generic UI message. I need either Raw error expanded or the new openclaw logs --follow line after you click Connect.

But based on your earlier log, try this WSL-specific fix first:

openclaw config set gateway.controlUi.allowedOrigins '["http://127.0.0.1:18789","http://localhost:18789"]' --strict-json
openclaw config set gateway.controlUi.allowInsecureAuth true --strict-json
openclaw gateway restart
openclaw dashboard --no-open

Then paste the copied dashboard URL into a fresh private/incognito browser window.

If it still fails, please don’t paste the generic “Could not connect” box again. Paste one of these instead:

[vital dagger]

openclaw logs --follow

Click Connect once, then copy the new warn gateway/ws or error line. Or expand Raw error in the dashboard and paste that text.

[vital dagger]

Good, progress: the browser can reach the Gateway now. It’s only auth.

Run this in WSL:

openclaw dashboard --no-open

It says it copies a token-authenticated URL to your clipboard. Paste that full copied URL into a fresh browser tab.

If that still lands on the auth screen, use the token from your config without posting it here:

openclaw config get gateway.auth.token

Copy the token output, paste it into the Gateway Token field, leave Password blank, then click Connect.