#Cant connect Claude to Openclaw

1 messages · Page 1 of 1 (latest)

hallow tundra
#

When i run onboarding and pick "anthropic/claude-opus-4-7' as the model, it says " No auth configured for provider "anthropic". The agent may fail until credentials are │
│ added. Run openclaw models auth login --provider anthropic, openclaw configure, or │
│ set an API key env var."

I ran openclaw models auth login --provider anthropic and this happened

Default model available: claude-cli/claude-opus-4-7 (use --set-default to apply)
│
◇ Provider notes ───────────────────────────────────────────────────────────────────────╮
│ │
│ Claude CLI auth detected; switched Anthropic model selection to the local Claude CLI │
│ backend. │
│ Existing Anthropic auth profiles are kept for rollback. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
omgdi@toastys-pc:~$ --set-default
--set-default: command not found

pseudo grottoBOT
#

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

hollow anchorBOT
vital nicheBOT
#

What does openclaw --version print?

Also, the immediate issue is this:

--set-default is not a shell command. It’s a flag that has to be on the same openclaw command, so this part:

--set-default

failed because bash tried to run it by itself.

More importantly, you’ve got two different backends mixed together:

  • anthropic/claude-opus-4-7 = Anthropic provider auth
  • claude-cli/claude-opus-4-7 = local Claude CLI auth
#

Your login output says OpenClaw detected Claude CLI auth and switched to the claude-cli backend, so the fix is usually:

openclaw models auth login --provider anthropic --method cli --set-default
openclaw models status

Or, if auth is already fine and you just need to switch the model:

openclaw models set claude-cli/claude-opus-4-7
openclaw models status

So in short, if you want to use your local Claude CLI login, don’t keep anthropic/claude-opus-4-7 selected, use the claude-cli/... model instead.

Docs:

hallow tundra
#

omgdi@toastys-pc:~$ openclaw --version
OpenClaw 2026.4.20 (115f05d)

#

🦞 OpenClaw 2026.4.20 (115f05d) — Running on your hardware, reading your logs, judging nothing (mostly).

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : claude-cli/claude-opus-4-7
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (6): claude-cli/claude-opus-4-7, claude-cli/claude-sonnet-4-6, claude-cli/claude-opus-4-6, claude-cli/claude-opus-4-5, claude-cli/claude-sonnet-4-5, claude-cli/claude-haiku-4-5

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

  • claude-cli effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | anthropic:claude-cli=OAuth

OAuth/token status

  • claude-cli
    • anthropic:claude-cli expiring expires in 6h
vital nicheBOT
#

Nice, 2026.4.20 looks fine, so this is probably just model/backend mismatch, not an old-version bug.

Since your auth flow found Claude CLI, try this next:

openclaw models set claude-cli/claude-opus-4-7
openclaw models status

If that works, your issue was just that onboarding had anthropic/claude-opus-4-7 selected, but your actual auth is for claude-cli/....

If you specifically want to keep using the anthropic/... model instead, then you need real Anthropic provider auth, usually an ANTHROPIC_API_KEY on the gateway host, not Claude CLI reuse.

Paste the output of openclaw models status and I’ll check the exact state.

#

Yep, this looks correctly configured now.

What your models status shows:

  • Default model: claude-cli/claude-opus-4-7
  • Configured models: only claude-cli/...
  • Auth: claude-cli OAuth is present

So OpenClaw is not currently trying to use anthropic/claude-opus-4-7. It’s using the local Claude CLI backend, which matches your auth.

So the earlier onboarding warning was probably just from when you picked the anthropic/... model before the auth flow switched you over to claude-cli/....

Two important notes:

  1. You should be good to test it now.
  2. Your Claude CLI OAuth says expires in 6h, so if it stops later, re-run:
# 
openclaw models auth login --provider anthropic --method cli --set-default

If onboarding still shows the same No auth configured for provider "anthropic" warning even though models status looks like this, then I’d call that a UX bug / misleading warning rather than a real auth failure.

If you want, next paste the exact error you get when you send a real prompt, but from this status output, the auth/model setup itself looks good.

hallow tundra
#

Provider notes ───────────────────────────────────────────────────────────────────────╮
│ │
│ Claude CLI auth detected; switched Anthropic model selection to the local Claude CLI │
│ backend. │
│ Existing Anthropic auth profiles are kept for rollback. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Model configured ────────────────────────────────╮
│ │
│ Default model set to claude-cli/claude-opus-4-7 │
│ │
├───────────────────────────────────────────────────╯
│
│
◇ Default model
│ Keep current (claude-cli/claude-opus-4-7)
│
◇ Model check ──────────────────────────────────────────────────────────────────────────────╮
│ │
│ Model not found: claude-cli/claude-opus-4-7. Update agents.defaults.model or run /models │
│ list. │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
Error: Cannot find module '@larksuiteoapi/node-sdk'
Require stack:

  • /home/omgdi/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/extensions/feishu/client-yWGpoGkZ.js
vital nicheBOT
#

Aha, this is the real problem.

Your Claude auth is fine. The new error is a broken install / packaging issue:

Error: Cannot find module '@larksuiteoapi/node-sdk'
.../openclaw/dist/extensions/feishu/client-*.js

So what’s happening is:

  • OpenClaw successfully switches you to claude-cli/claude-opus-4-7
  • then onboarding crashes while loading the bundled Feishu extension
  • and that crash makes the later model check look bogus (Model not found)

So this is not actually an Anthropic auth problem anymore.

#

What I’d do next

Reinstall or upgrade OpenClaw cleanly, on the same Node install that owns this path:

/home/omgdi/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw

If you want, paste:

which openclaw
node -v
pnpm -v

and I’ll tell you the exact safest reinstall command for your setup.

#

If you already know how you installed it, the goal is simply: refresh that global install so the missing Feishu dependency is present.

If it still happens after a clean reinstall on the latest build, that’s bug territory and should go to GitHub issues: https://github.com/openclaw/openclaw/issues

hallow tundra
#

/home/omgdi/.nvm/versions/node/v24.15.0/bin/openclaw, v24.15.0, tried to use pnpm -v and it said pnpm: command not found

vital nicheBOT
#

Perfect, that gives us the exact path. Since your openclaw is coming from the global npm install inside nvm, I’d refresh that install directly:

npm uninstall -g openclaw
npm install -g openclaw@latest

Then check:

openclaw --version
openclaw models status

If the reinstall still throws the same Feishu missing-module error, use this workaround:

# 
npm install -g @larksuiteoapi/node-sdk

That should satisfy the missing bundled dependency at:

/home/omgdi/.nvm/versions/node/v24.15.0/lib/node_modules

So the short version:

  1. Claude auth is already okay
  2. Your global OpenClaw install looks broken
  3. Reinstall openclaw first
  4. If needed, install @larksuiteoapi/node-sdk as a fallback workaround
#

After that, claude-cli/claude-opus-4-7 should be the right model path, not anthropic/claude-opus-4-7.

If you paste the output after the reinstall, I’ll sanity check it.

hallow tundra
#

omgdi@toastys-pc:~$ npm install -g openclaw@latest
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead

added 454 packages in 16s

82 packages are looking for funding
run npm fund for details
omgdi@toastys-pc:~$ openclaw --version
OpenClaw 2026.4.20 (115f05d)
omgdi@toastys-pc:~$ openclaw models status

🦞 OpenClaw 2026.4.20 (115f05d) — Your config is valid, your assumptions are not.

21:08:03 [plugins] amazon-bedrock installed bundled runtime deps: @aws-sdk/client-bedrock@3.1032.0
21:08:05 [plugins] amazon-bedrock-mantle installed bundled runtime deps: @aws/bedrock-token-generator@^1.1.0
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : claude-cli/claude-opus-4-7
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (6): claude-cli/claude-opus-4-7, claude-cli/claude-sonnet-4-6, claude-cli/claude-opus-4-6, claude-cli/claude-opus-4-5, claude-cli/claude-sonnet-4-5, claude-cli/claude-haiku-4-5

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

  • claude-cli effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | anthropic:claude-cli=OAuth

OAuth/token status

  • claude-cli
    • anthropic:claude-cli expiring expires in 6h
vital nicheBOT
#

Nice, this looks healthy now.

What changed:

  • the Feishu missing-module crash is gone
  • openclaw models status is clean
  • your default is still claude-cli/claude-opus-4-7
  • auth is present for claude-cli

So at this point, Claude is connected. ✅

The key bit is still:

  • use claude-cli/claude-opus-4-7
  • do not expect anthropic/claude-opus-4-7 to work unless you set up a real ANTHROPIC_API_KEY

So if onboarding still shows that old No auth configured for provider "anthropic" warning when you pick the anthropic/... model, that’s basically a misleading warning / UX bug, not your actual runtime state.

#

My recommendation

Don’t keep rerunning onboarding for this. Your model/auth state already looks correct. Just try using OpenClaw normally now.

One small heads-up:

  • your Claude CLI OAuth still says expires in 6h, so if it dies later, rerun:
openclaw models auth login --provider anthropic --method cli --set-default

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

If a real prompt still fails, paste that exact error and I’ll keep going.

hallow tundra
#

Error: Cannot find module 'nostr-tools'
Require stack:

  • /home/omgdi/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/extensions/nostr/setup-surface-d0cfZ0y8.js
vital nicheBOT
#

Yep, same class of problem, different bundled plugin.

Now it’s crashing on Nostr:

Cannot find module 'nostr-tools'
.../openclaw/dist/extensions/nostr/setup-surface-*.js

So I would not keep chasing onboarding errors at this point.

Important part

Your Claude setup is already fine. We verified that with openclaw models status:

  • default model = claude-cli/claude-opus-4-7
  • auth exists for claude-cli
#

So the thing that’s broken is the onboarding flow / bundled plugin packaging, not your Claude connection.

My recommendation

  • Stop rerunning onboarding
  • just use OpenClaw with the current config
  • if actual chatting/runs fail, paste that error

If you specifically want to report the onboarding breakage, this is now solidly GitHub issue material. Include both missing-module traces:

  • @larksuiteoapi/node-sdk
  • nostr-tools

and your version:

  • OpenClaw 2026.4.20 (115f05d)

Issue link: https://github.com/openclaw/openclaw/issues

#

So, short version: Claude is connected, onboarding is busted.

hallow tundra
#

When i try to check the gateway status, this happened omgdi@toastys-pc:~$ openclaw gateway status

🦞 OpenClaw 2026.4.20 (115f05d) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-21.log
Command: /home/omgdi/.nvm/versions/node/v24.15.0/bin/node /home/omgdi/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/omgdi/.nvm/versions/node/v24.15.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/omgdi/.nvm/versions/node/v24.15.0/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state failed, sub failed, last exit 78, reason 1)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-04-21.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Restart attempts: /home/omgdi/.openclaw/logs/gateway-restart.log

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

vital nicheBOT
#

That output is actually useful, it means:

  • the status command worked
  • the gateway service is installed
  • the service is crashing on startup

So the next step is not more onboarding, it’s fixing the gateway service.

Run these in order:

openclaw doctor --repair
openclaw gateway restart
openclaw gateway status
journalctl --user -u openclaw-gateway.service -n 100 --no-pager
#

A couple notes:

  • the nvm / version-manager warnings are real, but they are probably not the immediate root cause
  • the journal output will usually show the actual crash reason, likely another startup/import error

If doctor --repair says it can’t fully migrate because there’s no system Node outside nvm, that’s okay for now, still paste the journalctl output.

Docs:

Paste the last command’s output and I’ll tell you exactly what is killing the gateway.

unique elk
#

so i'm trying to access openclaw control web ui bc i wanna add skillls and and i don't know the website or anything, i did it with hostinger vps with ollama install, but the hostinger openclaw control doesn't have ollama, and i can chat with my agent on telegram

vital nicheBOT
#

First, what does openclaw --version print on the VPS?

For the UI part though, there isn’t a separate OpenClaw website. The Control UI is served by your own gateway.

On the VPS, run:

openclaw dashboard --no-open

or:

openclaw gateway status

That should show the dashboard URL.

#

Most common VPS setup

Usually the gateway is loopback-only, so from your laptop you tunnel to it:

ssh -N -L 18789:127.0.0.1:18789 user@your-vps

Then open this locally in your browser:

http://127.0.0.1:18789/

If it says pairing required, approve the browser:

# 
openclaw devices list
openclaw devices approve <requestId>

About Ollama not showing up

If the Hostinger OpenClaw UI “doesn’t have Ollama”, that usually means one of these:

  1. Ollama isn’t configured in OpenClaw on that VPS
  2. Ollama is running somewhere else, and the VPS can’t reach it
  3. You’re connected to the wrong OpenClaw instance

If you can already chat with the agent on Telegram, OpenClaw is alive, but that does not guarantee it’s using Ollama.

If you want, paste the output of:

hallow tundra
#

omgdi@toastys-pc:~$ journalctl --user -u openclaw-gateway.service -n 100 --no-pager
Apr 21 18:58:29 toastys-pc systemd[324]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.20).
Apr 21 18:58:30 toastys-pc node[2651]: 2026-04-21T18:58:30.409-04:00 [gateway] loading configuration…
Apr 21 18:58:30 toastys-pc node[2651]: 2026-04-21T18:58:30.449-04:00 [gateway] resolving authentication…
Apr 21 18:58:30 toastys-pc node[2651]: 2026-04-21T18:58:30.457-04:00 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.
Apr 21 18:58:30 toastys-pc node[2651]: 2026-04-21T18:58:30.458-04:00 Config write audit: /home/omgdi/.openclaw/logs/config-audit.jsonl
Apr 21 18:58:30 toastys-pc systemd[324]: openclaw-gateway.service: Main process exited, code=exited, status=78/CONFIG
Apr 21 18:58:30 toastys-pc systemd[324]: openclaw-gateway.service: Failed with result 'exit-code'.
Apr 21 18:58:30 toastys-pc systemd[324]: openclaw-gateway.service: Consumed 1.093s CPU time.
Apr 21 18:58:33 toastys-pc systemd[324]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.20).
Apr 21 18:58:34 toastys-pc node[2764]: 2026-04-21T18:58:34.124-04:00 [gateway] loading configuration…
Apr 21 18:58:34 toastys-pc node[2764]: 2026-04-21T18:58:34.134-04:00 [gateway] resolving authentication…
Apr 21 18:58:34 toastys-pc node[2764]: 2026-04-21T18:58:34.143-04:00 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.
Apr 21 18:58:34 toastys-pc node[2764]: 2026-04-21T18:58:34.144-04:00 Config write audit: /home/omgdi/.openclaw/logs/config-audit.jsonl

#

Apr 21 18:58:34 toastys-pc systemd[324]: openclaw-gateway.service: Main process exited, code=exited, status=78/CONFIG
Apr 21 18:58:34 toastys-pc systemd[324]: openclaw-gateway.service: Failed with result 'exit-code'.
Apr 21 18:58:34 toastys-pc systemd[324]: openclaw-gateway.service: Consumed 1.005s CPU time, 254.1M memory peak, 0B memory swap peak.
Apr 21 20:35:39 toastys-pc systemd[324]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.20).
Apr 21 20:35:39 toastys-pc node[4058]: 2026-04-21T20:35:39.991-04:00 [gateway] loading configuration…
Apr 21 20:35:42 toastys-pc node[4058]: 2026-04-21T20:35:42.065-04:00 [gateway] resolving authentication…
Apr 21 20:35:42 toastys-pc node[4058]: 2026-04-21T20:35:42.079-04:00 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.
Apr 21 20:35:42 toastys-pc node[4058]: 2026-04-21T20:35:42.080-04:00 Config write audit: /home/omgdi/.openclaw/logs/config-audit.jsonl
Apr 21 20:35:42 toastys-pc systemd[324]: openclaw-gateway.service: Main process exited, code=exited, status=78/CONFIG
Apr 21 20:35:42 toastys-pc systemd[324]: openclaw-gateway.service: Failed with result 'exit-code'.
Apr 21 20:35:42 toastys-pc systemd[324]: openclaw-gateway.service: Consumed 4.447s CPU time.
Apr 21 20:35:47 toastys-pc systemd[324]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.20).
Apr 21 20:35:48 toastys-pc node[4098]: 2026-04-21T20:35:48.618-04:00 [gateway] loading configuration…
Apr 21 20:35:51 toastys-pc node[4098]: 2026-04-21T20:35:51.452-04:00 [gateway] resolving authentication…

#

Apr 21 21:17:52 toastys-pc systemd[324]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.20).
Apr 21 21:17:56 toastys-pc node[5821]: 2026-04-21T21:17:56.016-04:00 [gateway] loading configuration…
Apr 21 21:17:56 toastys-pc node[5821]: 2026-04-21T21:17:56.148-04:00 [gateway] resolving authentication…
Apr 21 21:17:56 toastys-pc node[5821]: 2026-04-21T21:17:56.154-04:00 [gateway] starting...
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.848-04:00 [gateway] starting HTTP server...
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.851-04:00 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/omgdi/.openclaw/canvas)
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.880-04:00 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.897-04:00 [gateway] agent model: claude-cli/claude-opus-4-7
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.897-04:00 [gateway] ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 1.7s)
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.898-04:00 [gateway] log file: /tmp/openclaw/openclaw-2026-04-21.log
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.903-04:00 [heartbeat] started
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.913-04:00 [gateway] starting channels and sidecars...
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.932-04:00 [plugins] embedded acpx runtime backend registered (cwd: /home/omgdi/.openclaw/workspace)
Apr 21 21:17:57 toastys-pc node[5821]: 2026-04-21T21:17:57.960-04:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)

vital nicheBOT
#

Nice, we found the actual blocker.

Your gateway is failing because your config is missing:

gateway.mode = "local"

That’s why it exits immediately with status=78/CONFIG.

Best fix here

Don’t rerun onboarding right now, since your onboarding flow is already tripping over bundled plugin issues.

Just repair the config directly:

# 
openclaw config set gateway.mode local
openclaw gateway restart
openclaw gateway status

If you want, also sanity check it first:

openclaw config get gateway.mode

What you want after the restart is:

  • Runtime: running
  • Connectivity probe: ok
hallow tundra
#


Apr 21 21:18:10 toastys-pc node[5913]: 2026-04-21T21:18:10.308-04:00 [gateway] log file: /tmp/openclaw/openclaw-2026-04-21.log
Apr 21 21:18:10 toastys-pc node[5913]: 2026-04-21T21:18:10.313-04:00 [heartbeat] started
Apr 21 21:18:10 toastys-pc node[5913]: 2026-04-21T21:18:10.318-04:00 [gateway] starting channels and sidecars...
Apr 21 21:18:10 toastys-pc node[5913]: 2026-04-21T21:18:10.335-04:00 [plugins] embedded acpx runtime backend registered (cwd: /home/omgdi/.openclaw/workspace)
Apr 21 21:18:10 toastys-pc node[5913]: 2026-04-21T21:18:10.364-04:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
Apr 21 21:18:15 toastys-pc node[5913]: 2026-04-21T21:18:15.288-04:00 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=toastys-pc (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
Apr 21 21:18:15 toastys-pc node[5913]: 2026-04-21T21:18:15.299-04:00 [plugins] embedded acpx runtime backend ready
Apr 21 21:18:24 toastys-pc node[5913]: 2026-04-21T21:18:24.328-04:00 [agent/cli-backend] cli exec: provider=claude-cli model=opus promptChars=398
Apr 21 21:18:24 toastys-pc node[5913]: 2026-04-21T21:18:24.348-04:00 [gateway] device pairing auto-approved device=06590b5b5ac465a97ac71c75fa7bfcd5f7dcf370cfc947784119421844dd8619 role=operator

vital nicheBOT
#

This one probably doesn’t need escalation yet.

The journal log already points to the immediate fix:

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

That missing gateway.mode error is a local config problem, not a mysterious Claude auth problem.

If that fixes the gateway but onboarding still throws the bundled-plugin missing-module stuff (nostr-tools, @larksuiteoapi/node-sdk), that is the part I’d treat as a bug and send to GitHub issues:
https://github.com/openclaw/openclaw/issues

So I’d do the config fix first, then see what’s left.

hallow tundra
#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-21.log
Command: /home/omgdi/.nvm/versions/node/v24.15.0/bin/node /home/omgdi/.nvm/versions/node/v24.15.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/omgdi/.nvm/versions/node/v24.15.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/omgdi/.nvm/versions/node/v24.15.0/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 6236, 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

vital nicheBOT
#

Yep, same blocker, nothing new in those logs.

The gateway is still dying on:

existing config is missing gateway.mode

So the next step is still just this:

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

Those journal lines are only telling us the service kept retrying before that fix was applied.

#

Paste the output of those 3 commands, not more old journal lines, and we can move this forward.

#

Nice, that’s the good log. 🎉

The important lines are:

  • [gateway] agent model: claude-cli/claude-opus-4-7
  • [gateway] ready
  • browser control listening
  • no more missing gateway.mode

So at this point:

  • gateway is running
  • Claude is connected
  • the gateway.mode fix worked

Next things you can do:

# 
openclaw gateway status
openclaw dashboard --no-open

If you’re on that same PC, the Control UI should be at:

http://127.0.0.1:18789/

If onboarding still throws those random missing-module errors afterward, I’d treat that as a separate onboarding bug, because your actual runtime now looks healthy.

Glad we caught it. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

#

Yep, that looks fully alive now.

The strongest signals are:

  • embedded acpx runtime backend ready
  • cli exec: provider=claude-cli model=opus
  • device pairing auto-approved ... role=operator

So now you’ve got:

  • gateway running
  • Claude CLI backend actually executing
  • Control UI/browser device approved

The bonjour ... re-advertise line is not the scary part here, I’d treat that as noise unless local discovery specifically matters to you.

At this point I’d stop digging through logs and just use it:

#
  • open the Control UI
  • send a real prompt
  • verify replies come back

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow.

unique elk
vital nicheBOT
#

The user there is your SSH username on the VPS.

So this part:

ssh -N -L 18789:127.0.0.1:18789 user@your-vps

should become something like:

ssh -N -L 18789:127.0.0.1:18789 root@your-vps-ip

or:

# 
ssh -N -L 18789:127.0.0.1:18789 ubuntu@your-vps-ip

depending on how your server is set up.

  • user = your VPS login name
  • your-vps = the VPS IP or hostname

If you’re not sure, it’s the same username you normally use when SSHing into Hostinger.

unique elk
#

how do i find out my vps log in name

vital nicheBOT
#

Easiest ways:

  1. If you’re already SSH’d into the VPS, run:

    whoami

  2. Check the Hostinger VPS panel, it usually shows the SSH login user in the server access / SSH section.

  3. Look at the SSH command you already use.
    If you normally connect with something like:

    ssh root@123.45.67.89

    then your username is root.

So if you’re already in the VPS terminal, whoami is the fastest answer.

unique elk
#

its asking for my password to vps but when i go to enter it it doesn't let me type or paste

vital nicheBOT
#

That part is normal.

In an SSH password prompt, nothing shows up while you type:

  • no letters
  • no dots
  • no *

Just type the password blindly and press Enter.

So even though it looks like it’s not typing, it usually is.

If paste doesn’t work in your terminal:

  • try right-click paste
  • or Shift+Insert
  • or just type it manually

If it still fails, the issue is usually the wrong password, not the invisible prompt behavior.

unique elk
#

i typed manually but its wrong

#

and its the password

vital nicheBOT
#

Then the blocker is just VPS access now, not OpenClaw.

You need the actual SSH credentials for that Hostinger VPS.

Try one of these:

  1. Use the Hostinger VPS panel

    • look for SSH access / root password / server credentials
    • if needed, reset the VPS password

  2. Use Hostinger’s web console / browser terminal if they provide one

    • that’s often easier than SSH when you don’t know the password yet

  3. Check whether your VPS uses an SSH key instead of a password

    • in that case password login may fail completely

So at this point I’d do this:

#
  • open the Hostinger VPS dashboard
  • find server credentials
  • either get the right SSH password or reset it
  • then reconnect

If you want, send a screenshot or the exact labels you see in the Hostinger panel and I’ll tell you where to click next.

#

If you’re sure the password is right, then it’s usually one of these:

  1. wrong SSH username
  2. password auth is disabled
  3. root login is disabled
  4. the VPS password was changed and the saved one is old

So I’d check these next:

  • confirm the SSH username in Hostinger
  • try the exact username Hostinger shows, not just root
  • if needed, reset the VPS password
  • if Hostinger has a browser console, use that first and run:
    whoami
    so you know the real login name
#

So yeah, this is probably not your typing, it’s either the wrong username or old password.

unique elk
#

is there another way for me to access

#

without tunnel

vital nicheBOT
#

Yes, but only if one of these already exists:

  1. Hostinger browser console / web terminal
    This is the best alternative if SSH login is failing.

  2. A Control UI URL was already exposed

    • for example through Tailscale Serve
    • or a reverse proxy / domain you already set up

  3. Someone else with VPS access can log in and give you:

    • the dashboard URL
    • the gateway token/password
    • or fix SSH access

But if the gateway is only on:

# 
http://127.0.0.1:18789/

then no, you can’t reach that from outside the VPS without either:

  • SSH tunnel access
  • browser console access
  • or a proper remote setup like Tailscale

So the realistic fallback is: use Hostinger’s browser console if available. If you want, tell me what buttons/options you see in Hostinger and I’ll help you find it.

#

Without a tunnel, the clean option is Tailscale Serve or another proper remote web setup.

But there’s an annoying catch:

you still need VPS access once to set that up.

So the honest answer is:

  • without tunnel
  • without SSH/web-console access
  • without an already-exposed Control UI URL

→ no, not really

Because right now the gateway is on loopback only:

# 
http://127.0.0.1:18789/

That is intentionally not reachable from outside.

Your remote-access options are basically:

  1. SSH tunnel
  2. Hostinger browser console
  3. Tailscale Serve / reverse proxy, but only after you can access the VPS once

So the next real step is still getting Hostinger console or SSH access.

celest mason
#

Can you quickly summarize OpenClaw-style Claude CLI usage is allowed on setup steps?

vital nicheBOT
#

Yep. Short version:

  • Yes, OpenClaw currently treats Claude CLI reuse and claude -p style usage as allowed again.
  • The docs say Anthropic staff told us this usage is allowed again, so OpenClaw considers the bundled claude-cli backend sanctioned unless Anthropic publishes a new policy change.
  • That’s why setup/login can legitimately switch you to:
    • claude-cli/claude-opus-4-7
    • instead of anthropic/...

Typical setup command:

openclaw models auth login --provider anthropic --method cli --set-default

One nuance:

  • Claude CLI auth is fine for local/personal use
  • Anthropic API keys are still the clearer choice for always-on gateway hosts and explicit billing control
celest mason
#

Can you tell me what am I supposed to see as end result in JSON?

vital nicheBOT
#

If you mean the final config shape, the important part is basically this:

{
  "gateway": {
    "mode": "local"
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "claude-cli/claude-opus-4-7"
      }
    }
  }
}
#

But one important nuance:

  • the model selection ends up in openclaw.json
  • the Claude CLI auth itself does not
  • auth is stored separately in:
~/.openclaw/agents/<agentId>/agent/auth-profiles.json

So the “good end result” is really:

openclaw.json

  • gateway.mode = "local"
  • default model = claude-cli/claude-opus-4-7

auth-profiles.json

#
  • a claude-cli / Anthropic-backed OAuth profile exists

openclaw models status

should show something like:

  • Default: claude-cli/claude-opus-4-7
  • provider auth present for claude-cli

If you want, I can give you the exact expected openclaw.json snippet and the expected auth-profiles.json shape separately.

celest mason
#

Auth method for Anthropic
| > Claude CLI (Reuse a local Claude CLI login and switch model selection to claude-cli/*)
| Anthropic setup-token
| Anthropic API key

which method do I choose? I have claude pro subs

vital nicheBOT
#

If you have a Claude Pro subscription, choose:

Claude CLI

That is the right option for:

  • reusing your local Claude login
  • switching OpenClaw to claude-cli/*
  • not needing a separate Anthropic API key

So for your case:

  • pick Claude CLI
  • don’t pick Anthropic API key unless you actually have/pay for API usage
  • don’t pick Anthropic setup-token unless you specifically know you need that older/manual token path
#

Short version:

  • Claude Pro sub → Claude CLI
  • Anthropic API billing account → Anthropic API key

If onboarding works correctly, the end result should be a model like:

claude-cli/claude-opus-4-7

not anthropic/claude-opus-4-7.

celest mason
#

o Auth method for Anthropic
| Claude CLI
Error: Claude CLI is not authenticated on this host.
Run claude auth login first, then re-run this setup.

vital nicheBOT
#

Yep, that error is straightforward:

OpenClaw is trying to reuse Claude CLI auth on that machine, but Claude CLI is not logged in there yet.

So the next step is on the same host where OpenClaw runs:

claude auth login

Then rerun:

openclaw models auth login --provider anthropic --method cli --set-default

Important nuance:

#
  • if OpenClaw runs on your VPS, then claude auth login must happen on the VPS
  • logging into Claude on your laptop does not help the VPS

If you do not want to install/login Claude CLI on that host, then choose:

Anthropic API key

instead.

So the choice is:

  • Claude Pro + Claude CLI installed/logged in on that host → Claude CLI
  • No Claude CLI on that host → Anthropic API key
celest mason
#

opus is the only avalaible model to use?

vital nicheBOT
#

No, not necessarily.

What you can use depends on what Claude CLI auth exposes on that host and what OpenClaw has configured, so don’t assume Opus is the only choice.

Check the actual available set on your machine with:

openclaw models list --provider claude-cli
openclaw models status

If you want general model recommendations beyond “what is available right now on this host,” ask in #models since that changes fast.

Docs:

celest mason
#

Model Input Ctx Local Auth Tags
claude-cli/claude-sonnet-4-6 text+image 195k no yes configured,alias:sonnet
claude-cli/claude-haiku-4-5 - - - - configured,missing
claude-cli/claude-opus-4-6 text+image 195k no yes configured,alias:opus
claude-cli/claude-opus-4-7 text+image 977k no yes configured
claude-cli/claude-opus-4-5 - - - - configured,missing
claude-cli/claude-sonnetopenclaw models status - - - configured,missing

This mean that haiku is no longer avaliable in claude-cli correct?

vital nicheBOT
#

Yes, for your current Claude CLI setup on that host, that’s what it means.

configured,missing means OpenClaw still has the model in its configured list, but Claude CLI is not currently exposing/resolving it.

So the careful version is:

  • not necessarily “gone everywhere”
  • but not available through your current Claude CLI auth/catalog right now

So in practice, yes, don’t expect Haiku there right now. Use the entries that are not marked missing.

That garbled last line looks like your command output got mashed together a bit, so if you want a cleaner check, rerun:

openclaw models list --provider claude-cli
celest mason
#

I configured already, but it seems like Openclaw failed to use claude. Can you help me figure out why?
🦞 OpenClaw 2026.4.21 (f788c88) — Greetings, Professor Falken

Model Input Ctx Local Auth Tags
claude-cli/claude-sonnet-4-6 text+image 195k no yes configured,alias:sonnet

claude-cli/claude-haiku-4-5 - - - - configured,missing

claude-cli/claude-opus-4-6 text+image 195k no yes configured,alias:opus

claude-cli/claude-opus-4-7 text+image 977k no yes configured

claude-cli/claude-opus-4-5 - - - - configured,missing

claude-cli/claude-sonnet-4-5 - - - - configured,missing

12:22:18 [agent/cli-backend] cli exec: provider=claude-cli model=opus promptChars=311
12:22:18 [process/supervisor] spawn failed: runId=4f5c223d-1502-4226-92ab-fda20ee9585f reason=Error: spawn ENAMETOOLONG
12:22:18 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=claude-cli/claude-opus-4-7 candidate=claude-cli/claude-opus-4-7 reason=unknown next=openai-codex/gpt-5.4 detail=spawn ENAMETOOLONG

12:23:16 [model-fallback/decision] model fallback decision: decision=candidate_succeeded requested=claude-cli/claude-opus-4-7 candidate=openai-codex/gpt-5.4 reason=unknown next=none
12:23:17 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).

vital nicheBOT
#

Yep, I think the real failure is not auth anymore, it’s this:

  • OpenClaw did select Claude: requested=claude-cli/claude-opus-4-7
  • then the Claude CLI run died before Claude started with:
    Error: spawn ENAMETOOLONG
  • so OpenClaw fell back to openai-codex/gpt-5.4

Why this happens:

  • promptChars=311 is only your user prompt
  • the bundled claude-cli backend sends the user prompt over stdin
  • but it still sends OpenClaw’s big assembled system prompt as one giant --append-system-prompt "..." argument
  • on Linux, that single argv entry can hit the OS/libuv length limit, which matches spawn ENAMETOOLONG

So, short version: Claude auth is present, model selection worked, but the Claude CLI backend crashed on argument length.

Also, --set-default is just a flag, not a command by itself, so:

# 
openclaw models auth login --provider anthropic --set-default

is valid, but typing just:

--set-default

will always give command not found.

Best next options

Option 1, recommended: use direct Anthropic API auth for now
If you want Claude working immediately without this CLI-backend bug:

# 
openclaw models auth login --provider anthropic --method api-key --set-default

Option 2, workaround: disable the Claude CLI system prompt injection
In ~/.openclaw/openclaw.json, add this JSON5:

{
  agents: {
    defaults: {
      cliBackends: {
        "claude-cli": {
          systemPromptWhen: "never"
        }
      }
# 
    }
  }
}

then restart:

openclaw gateway restart

That should avoid the --append-system-prompt argv blowup, but it’s a workaround, not the ideal fix.

Option 3: upgrade if a newer build is available, then if it still happens file a GitHub issue with those exact log lines
https://github.com/openclaw/openclaw/issues

celest mason
#

Ahhh I think I dont have this backend section.

vital nicheBOT
#

Yep, that’s fine, you can add it.

In ~/.openclaw/openclaw.json, add this minimal block:

{
  agents: {
    defaults: {
      cliBackends: {
        "claude-cli": {
          systemPromptWhen: "never"
        }
      }
    }
  }
}
#

If agents or defaults already exist, just merge this in, don’t duplicate the keys.

Then restart the gateway:

openclaw gateway restart

Then test again.

What this does:

  • it tells the claude-cli backend not to send the giant first-turn system prompt as --append-system-prompt
  • that should avoid the spawn ENAMETOOLONG crash

If you want, paste your current ~/.openclaw/openclaw.json here and I’ll show you the exact merged version so you don’t have to guess commas/braces.

Docs:

celest mason
#

Can you help insert the change for me?
},
"agents": {
"defaults": {
"model": {
"primary": "openai-codex/gpt-5.4-mini",
"fallbacks": [
"openai-codex/gpt-5.4"
]
},
"models": {
"openai-codex/gpt-5.3-codex": {
"params": {
"thinking": "medium"
}
},
"openai-codex/gpt-5.4": {},
"openai-codex/gpt-5.3-codex-spark": {},
"ollama/qwen2.5:1.5b-instruct": {},
"ollama/qwen2.5:1.5b-instruct-16k": {},
"ollama/qwen2.5:1.5b-instruct-q4_K_M": {},
"ollama/qwen2.5:3b-instruct-q4_K_M": {},
"openai-codex/gpt-5.4-mini": {},
"openai-codex/gpt-5.4-nano": {},
"openrouter/free": {},
"openrouter/auto": {
"alias": "OpenRouter"
},
"openrouter/moonshotai/kimi-k2.5": {},
"openrouter/openrouter/elephant-alpha": {},
"openrouter/google/gemma-4-31b-it:free": {},
"openrouter/nvidia/nemotron-3-super-120b-a12b:free": {},
"openrouter/nvidia/nemotron-nano-12b-v2-vl:free": {},
"openrouter/nvidia/nemotron-nano-9b-v2:free": {},
"openrouter/openrouter/free": {},
"openrouter/google/gemma-4-26b-a4b-it:free": {},
"claude-cli/claude-sonnet-4-6": {
"alias": "sonnet"
},
"claude-cli/claude-haiku-4-5": {},
"claude-cli/claude-opus-4-6": {
"alias": "opus"
},
"claude-cli/claude-opus-4-7": {},
"claude-cli/claude-opus-4-5": {},
"claude-cli/claude-sonnet-4-5": {}

vital nicheBOT
#

Yep, based on what you pasted, add cliBackends next to model and models under agents.defaults.

If you want to keep your current default model and only add the workaround, make defaults look like this:

"agents": {
  "defaults": {
    "model": {
      "primary": "openai-codex/gpt-5.4-mini",
      "fallbacks": [
        "openai-codex/gpt-5.4"
      ]
    },
    "models": {
      "openai-codex/gpt-5.3-codex": {
        "params": {
# 
          "thinking": "medium"
        }
      },
      "openai-codex/gpt-5.4": {},
      "openai-codex/gpt-5.3-codex-spark": {},
      "ollama/qwen2.5:1.5b-instruct": {},
      "ollama/qwen2.5:1.5b-instruct-16k": {},
      "ollama/qwen2.5:1.5b-instruct-q4_K_M": {},
      "ollama/qwen2.5:3b-instruct-q4_K_M": {},
      "openai-codex/gpt-5.4-mini": {},
      "openai-codex/gpt-5.4-nano": {},
      "openrouter/free": {},
      "openrouter/auto": {
        "alias": "OpenRouter"
      },
# 
      "openrouter/moonshotai/kimi-k2.5": {},
      "openrouter/openrouter/elephant-alpha": {},
      "openrouter/google/gemma-4-31b-it:free": {},
      "openrouter/nvidia/nemotron-3-super-120b-a12b:free": {},
      "openrouter/nvidia/nemotron-nano-12b-v2-vl:free": {},
      "openrouter/nvidia/nemotron-nano-9b-v2:free": {},
      "openrouter/openrouter/free": {},
      "openrouter/google/gemma-4-26b-a4b-it:free": {},
      "claude-cli/claude-sonnet-4-6": {
        "alias": "sonnet"
      },
      "claude-cli/claude-haiku-4-5": {},
      "claude-cli/claude-opus-4-6": {
        "alias": "opus"
      },
# 
      "claude-cli/claude-opus-4-7": {},
      "claude-cli/claude-opus-4-5": {},
      "claude-cli/claude-sonnet-4-5": {}
    },
    "cliBackends": {
      "claude-cli": {
        "systemPromptWhen": "never"
      }
    }
  }
}

If you want Claude to be the default too, also change:

# 
"primary": "openai-codex/gpt-5.4-mini"

to:

"primary": "claude-cli/claude-opus-4-7"

Then restart:

openclaw gateway restart

One important thing: in the snippet you pasted, your default is still Codex mini, so if you want OpenClaw to prefer Claude, you need that primary change too.

celest mason
#

},
"claude-cli/claude-opus-4-7": {},
"claude-cli/claude-opus-4-5": {},
"claude-cli/claude-sonnet-4-5": {}
},
"cliBackends": {
"claude-cli": {
"systemPromptWhen": "never"
},
"workspace": "C:\Users\prapunsak\.openclaw\workspace",
"bootstrapMaxChars": 32000,
"bootstrapTotalMaxChars": 180000,
"memorySearch": {
"enabled": false,
"provider": "local",
"fallback": "none",
"local": {
"modelPath": "hf:ggml-org/embeddinggemma-300m-qat-q8_0-GGUF/embeddinggemma-300m-qat-Q8_0.gguf"
}
},

is the rest correct here?

vital nicheBOT
#

Almost, but that part is not closed correctly yet.

You need to fully close both "claude-cli" and "cliBackends" before "workspace" starts.

Use this exact shape:

},
"claude-cli/claude-opus-4-7": {},
"claude-cli/claude-opus-4-5": {},
"claude-cli/claude-sonnet-4-5": {}
},
"cliBackends": {
  "claude-cli": {
    "systemPromptWhen": "never"
  }
# 
},
"workspace": "C:\\Users\\prapunsak\\.openclaw\\workspace",
"bootstrapMaxChars": 32000,
"bootstrapTotalMaxChars": 180000,
"memorySearch": {
  "enabled": false,
  "provider": "local",
  "fallback": "none",
  "local": {
    "modelPath": "hf:ggml-org/embeddinggemma-300m-qat-q8_0-GGUF/embeddinggemma-300m-qat-Q8_0.gguf"
  }
},

So yes, the main fix is:

#
  • close "claude-cli" with }
  • close "cliBackends" with }
  • then put a comma
  • then continue with "workspace"

Also, if you want Claude as the default, make sure your "primary" is:

"primary": "claude-cli/claude-opus-4-7"

Then restart:

openclaw gateway restart
#

If you want, paste 10-15 lines above and below that section and I’ll sanity-check the whole block.

hollow anchorBOT
celest mason
#

13:04:07 [ws] closed before connect conn=38b2e6d8-a642-45ae-8b9e-5bed41de130f peer=127.0.0.1:49303->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed
13:04:08 [ws] closed before connect conn=336d4636-d956-4fdb-b94f-1ef2f432aa0b peer=127.0.0.1:62819->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed
13:04:09 [ws] closed before connect conn=e956e6eb-a99c-46eb-a99a-5c023a2808c0 peer=127.0.0.1:62820->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed
13:04:11 [ws] closed before connect conn=243a91ed-92c0-43b4-aa0f-3001472f6191 peer=127.0.0.1:62821->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed
13:04:12 [ws] closed before connect conn=b1a3962c-a344-4067-bab8-b795f5d801a1 peer=127.0.0.1:62822->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed

i got a lot of texts after restart

vital nicheBOT
#

Those lines by themselves are not the Claude error, they mean the local UI/websocket was trying to reconnect to 127.0.0.1:18789 and the gateway connect failed.

Since you just edited openclaw.json, my first suspicion is honestly a config syntax issue and the gateway did not come back cleanly.

Please run these two first and paste the output:

openclaw gateway status
openclaw status

What I want to see is:

  • Runtime: running
  • RPC probe: ok

If you don’t see that, then immediately run:

# 
openclaw logs --follow

and paste the first error lines after startup.

If the gateway is healthy and those messages stopped after a few seconds, then it was probably just the Control UI reconnecting during restart, and you can refresh http://127.0.0.1:18789/.

If you want, paste the gateway status output next and I’ll tell you exactly which case you’re in.

celest mason
#

Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-22.log
Command: C:\Program Files\nodejs\node.exe C:\Users\prapunsak\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_STATE_DIR=C:\Users\prapunsak.openclaw OPENCLAW_CONFIG_PATH=C:\Users\prapunsak.openclaw\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (last run 267009, last run time 22-Apr-26 12:56:12 PM)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789

vital nicheBOT
#

Nice, this is the good outcome.

Your gateway is healthy:

  • Runtime: running
  • Connectivity probe: ok
  • Listening: 127.0.0.1:18789

So the spammy ws ... code=1008 reason=connect failed lines were most likely just the Control UI/browser retrying during the restart, not a broken gateway.

Next step

Now test whether the Claude CLI workaround actually fixed the original problem.

Run:

# 
openclaw models status
openclaw logs --follow

Then, in the Control UI at:

http://127.0.0.1:18789/

send a tiny prompt like:

hi, reply with one word

Then paste the new log lines around:

  • cli exec: provider=claude-cli
  • spawn ENAMETOOLONG
#
  • model fallback decision

One important check

Earlier, your config still had:

"primary": "openai-codex/gpt-5.4-mini"

If that is still true, OpenClaw will keep preferring Codex by default.

If you want Claude as the default, make sure it is:

"primary": "claude-cli/claude-opus-4-7"
#

So, at this point:

  • gateway health: good
  • config syntax: good enough to boot
  • next question: does Claude still fall back, or did the workaround fix it?

Paste the next logs --follow output and I’ll check it.

celest mason
#

06:11:28+00:00 info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=claude-cli model=opus promptChars=162
06:11:28+00:00 warn process/supervisor {"subsystem":"process/supervisor"} spawn failed: runId=61d02465-e004-4ef5-8bc2-6e4aff382a90 reason=Error: spawn ENAMETOOLONG
06:11:28+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"f3cb3dc5-234a-4256-838d-df3ee15bd587","decision":"candidate_failed","requestedProvider":"claude-cli","requestedModel":"claude-opus-4-7","candidateProvider":"claude-cli","candidateModel":"claude-opus-4-7","attempt":1,"total":2,"code":"ENAMETOOLONG","errorPreview":"spawn ENAMETOOLONG","errorHash":"sha256:807538f6345d","nextCandidateProvider":"openai-codex","nextCandidateModel":"gpt-5.4","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":true} model fallback decision
06:11:36+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 89ms conn=b0d72422…23b8 id=dfdfb78d…111b
06:11:40+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 150ms conn=b0d72422…23b8 id=29febc17…c95a
06:11:40+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_succeeded"],"runId":"f3cb3dc5-234a-4256-838d-df3ee15bd587","decision":"candidate_succeeded","requestedProvider":"claude-cli","requestedModel":"claude-opus-4-7","candidateProvider":"openai-codex","candidateModel":"gpt-5.4","attempt":2,"total":2,"isPrimary":false,"requestedModelMatched":false,"fallbackConfigured":true,"previousAttempts":[{"provider":"claude-cli","model":"claude-opus-4-7","reason":"unknown","code":"ENAMETOOLONG","errorPreview":"spawn ENAMETOOLONG","errorHash":"sha256:807538f6345d"}]} model fallback decision

vital nicheBOT
#

Good, we narrowed it down.

That restart/config edit did not fix the actual Claude launch, because it is still failing with the exact same:

code":"ENAMETOOLONG"

So at this point I suspect one of two things:

  1. the cliBackends override is not actually being loaded from your config, or
  2. this is a real Windows claude-cli backend bug in 2026.4.21

Please run these exact checks

openclaw config get agents.defaults.cliBackends --json
openclaw config get agents.defaults.model --json
#

What I want to see in the first one is something like:

{
  "claude-cli": {
    "systemPromptWhen": "never"
  }
}

If that does not show up, then the config is nested in the wrong place.

If it does show up and Claude still throws ENAMETOOLONG, then I’d stop fighting the CLI backend and use the practical fix:

openclaw models auth login --provider anthropic --method api-key --set-default
#

That uses direct Anthropic API auth instead of the local Claude CLI backend, which avoids this spawn bug entirely.

So, next step is just those two config get outputs. That’ll tell us whether this is a bad config placement or a real backend bug.

celest mason
#

PS C:\WINDOWS\system32> openclaw config get agents.defaults.cliBackends --json
Config path not found: agents.defaults.cliBackends
PS C:\WINDOWS\system32> openclaw config get agents.defaults.model --json
{
"primary": "openai-codex/gpt-5.4-mini",
"fallbacks": [
"openai-codex/gpt-5.4"
]
}

vital nicheBOT
#

Yep, that tells us exactly what happened:

  • your cliBackends change did not land at agents.defaults.cliBackends
  • and your default model is still Codex mini

So let’s fix both cleanly with the CLI instead of hand-editing.

Run these in PowerShell:

openclaw config unset agents.defaults.models.cliBackends
openclaw config set 'agents.defaults.cliBackends["claude-cli"].systemPromptWhen' "never"
openclaw config set agents.defaults.model.primary "claude-cli/claude-opus-4-7"
openclaw gateway restart

If the first line says path not found, that’s fine, just continue.

#

Then verify:

openclaw config get agents.defaults.cliBackends --json
openclaw config get agents.defaults.model --json

You should now see:

{
  "claude-cli": {
    "systemPromptWhen": "never"
  }
}
#

and:

{
  "primary": "claude-cli/claude-opus-4-7",
  "fallbacks": [
    "openai-codex/gpt-5.4"
  ]
}

Then test one tiny prompt again.

If it still throws ENAMETOOLONG after the config is definitely in the right place, I’d call it a Windows Claude CLI backend bug and switch to direct Anthropic API auth instead.

celest mason
#

PS C:\WINDOWS\system32> openclaw config set 'agents.defaults.cliBackends["claude-cli"].systemPromptWhen' "never"

🦞 OpenClaw 2026.4.21 (f788c88) — Welcome to the command line: where dreams compile and confidence segfaults.

Error: Config validation failed: agents.defaults.cliBackends.claude-cli.command: Invalid input: expected string, received undefined

#

PS C:\WINDOWS\system32> openclaw config unset agents.defaults.models.cliBackends

🦞 OpenClaw 2026.4.21 (f788c88) — Alexa, but with taste.

Config path not found: agents.defaults.models.cliBackends

vital nicheBOT
#

Yep, that error makes sense, and it’s a slightly annoying schema quirk.

For agents.defaults.cliBackends["claude-cli"], OpenClaw wants a full backend entry with at least command present, not just one nested field.

Use this instead:

openclaw config set 'agents.defaults.cliBackends["claude-cli"]' '{ command: "claude", systemPromptWhen: "never" }'
openclaw config set agents.defaults.model.primary "claude-cli/claude-opus-4-7"
openclaw gateway restart

Then verify:

openclaw config get agents.defaults.cliBackends --json
# 
openclaw config get agents.defaults.model --json

You should see command: "claude" and systemPromptWhen: "never" under claude-cli.

So the short version is:

  • your previous path was right
  • but the config schema requires command
  • setting the whole claude-cli object should fix that

If that works, test one tiny prompt again. If it still hits ENAMETOOLONG, then I’m pretty confident this is a real Windows Claude CLI backend bug.

#

That’s okay, no problem, it just means there wasn’t a stray cliBackends key there after all.

You can ignore that and continue with the real fix:

openclaw config set 'agents.defaults.cliBackends["claude-cli"]' '{ command: "claude", systemPromptWhen: "never" }'
openclaw config set agents.defaults.model.primary "claude-cli/claude-opus-4-7"
openclaw gateway restart

Then check:

openclaw config get agents.defaults.cliBackends --json
openclaw config get agents.defaults.model --json
#

So the unset failure is harmless. The important part is the config set for claude-cli.

celest mason
#

PS C:\WINDOWS\system32> openclaw config set 'agents.defaults.cliBackends["claude-cli"]' '{ command: "claude", systemPromptWhen: "never" }'

🦞 OpenClaw 2026.4.21 (f788c88) — Half butler, half debugger, full crustacean.

Error: Config validation failed: agents.defaults.cliBackends.claude-cli: Invalid input: expected object, received string

vital nicheBOT
#

Yep, that’s just PowerShell being annoying with the object value.

Use strict JSON with fully quoted JSON:

openclaw config set 'agents.defaults.cliBackends["claude-cli"]' '{"command":"claude","systemPromptWhen":"never"}' --strict-json
openclaw config set agents.defaults.model.primary '"claude-cli/claude-opus-4-7"' --strict-json
openclaw gateway restart

Then verify:

openclaw config get agents.defaults.cliBackends --json
openclaw config get agents.defaults.model --json
#

The key change here is:

  • use valid JSON, not JSON5-ish shorthand
  • add --strict-json

If that still blows up, paste the exact output, but this version should parse correctly.

celest mason
#

PS C:\WINDOWS\system32> openclaw config set 'agents.defaults.cliBackends["claude-cli"]' '{"command":"claude","systemPromptWhen":"never"}' --strict-json

🦞 OpenClaw 2026.4.21 (f788c88) — Your AI assistant, now without the $3,499 headset.

Error: Failed to parse JSON value: SyntaxError: Expected property name or '}' in JSON at position 1 (line 1 column 2)

vital nicheBOT
#

Ugh, yeah, PowerShell is mangling the JSON on the way through. Let’s sidestep that entirely.

Run it in two steps with a variable:

$json = '{"command":"claude","systemPromptWhen":"never"}'
openclaw config set 'agents.defaults.cliBackends["claude-cli"]' $json --strict-json
openclaw config set agents.defaults.model.primary "claude-cli/claude-opus-4-7"
openclaw gateway restart

Then verify:

openclaw config get agents.defaults.cliBackends --json
openclaw config get agents.defaults.model --json
#

This avoids the quoting mess by letting PowerShell store the JSON first, then passing it through cleanly.

If that still errors, paste the output, but this is the cleanest PowerShell-safe version.

celest mason
#

PS C:\WINDOWS\system32> $json = '{"command":"claude","systemPromptWhen":"never"}'
PS C:\WINDOWS\system32> openclaw config set 'agents.defaults.cliBackends["claude-cli"]' $json --strict-json

🦞 OpenClaw 2026.4.21 (f788c88) — Shell yeah—I'm here to pinch the toil and leave you the glory.

Error: Failed to parse JSON value: SyntaxError: Expected property name or '}' in JSON at position 1 (line 1 column 2)

vital nicheBOT
#

Okay, this is definitely PowerShell/native-arg nonsense now, not you.

Let’s bypass shell quoting completely with a batch file. Run this exactly:

$batchPath = Join-Path $env:TEMP "openclaw-config-set.json"
@'
[
  {
    "path": "agents.defaults.cliBackends[\"claude-cli\"]",
    "value": {
      "command": "claude",
      "systemPromptWhen": "never"
    }
  },
  {
# 
    "path": "agents.defaults.model.primary",
    "value": "claude-cli/claude-opus-4-7"
  }
]
'@ | Set-Content -Encoding UTF8 $batchPath

openclaw config set --batch-file $batchPath
openclaw gateway restart

Then verify:

openclaw config get agents.defaults.cliBackends --json
openclaw config get agents.defaults.model --json
#

This avoids PowerShell mangling the JSON arguments on the command line.

If this works, great. If it still errors, paste that output, but this is the cleanest way to force the config in on Windows.

celest mason
#

Can we skip the default model for now since its not reliable

celest mason
#

It seems like it disspeared. Im repatching it now

vital nicheBOT
#

Yep, that tracks. I’d stick with the batch-file approach, since it’s the least fragile on PowerShell.

After you repatch it, verify immediately with:

openclaw config get agents.defaults.cliBackends --json
openclaw config get agents.defaults.model --json

You want to see:

{
  "claude-cli": {
    "command": "claude",
    "systemPromptWhen": "never"
# 
  }
}

and:

{
  "primary": "claude-cli/claude-opus-4-7",
  "fallbacks": [
    "openai-codex/gpt-5.4"
  ]
}

If those show up, then restart and test again.

#

If they don’t show up, paste the exact config get output before restarting, and we’ll catch where it’s going wrong.

celest mason
#

the clibackend is working now.

Do I need "systemPromptWhen": "never" ?

vital nicheBOT
#

Nice, glad it’s working 🎉

Short answer: no, not ideally.

"systemPromptWhen": "never" was just a workaround for the spawn ENAMETOOLONG problem. It tells the Claude CLI backend not to send the normal first-turn OpenClaw system prompt.

So:

  • if Claude CLI works without it, remove it
  • if removing it brings back ENAMETOOLONG, keep it for now

My recommendation:

  1. leave it in place while you confirm things are stable
  2. later, try removing the cliBackends["claude-cli"] override
  3. if the error returns, put it back and treat it as a temporary bug workaround
#

So, long-term: prefer not to keep it
Short-term: keep it if that’s what makes Claude work

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

celest mason
#

This is another topic, but I have so many sessions stuck in the OpenClaw UI how do I clean it? or start clean?

vital nicheBOT
#

Yep. Two different things here:

Start clean for this chat

Send:

/new

or

/reset

as a standalone message.

#

That starts a fresh session, but it does not delete old transcripts.

Clean old/stale sessions from the store

Preview first:

openclaw sessions --all-agents
openclaw sessions cleanup --all-agents --dry-run

Then actually prune:

openclaw sessions cleanup --all-agents --enforce

Nuclear option

#

If you want to wipe config, creds, and sessions as part of onboarding:

openclaw onboard --reset

or, if you also want to wipe the workspace:

openclaw onboard --reset-scope full

I’d recommend:

  1. use /new for “start fresh”
  2. use sessions cleanup --dry-run first if the UI is cluttered
  3. only use onboard --reset if you really want a big reset
hollow anchorBOT