OpenClaw Oboard with OpenRouter API | Friends of the Crustacean 🦞🤝 | Page 1

cobalt flicker Apr 19, 2026, 5:53 PM

#

Hello
Since a few days now im trying to get openclaw set up during the onboard with the openrouter API but it doesnt work. I always try to fix it to the point where i have already messed up too many things to i fully whipe openclaw of my mac mini m4. I already downgraded the macOS version because i thought that was the reason. Now i tried an older version of openclaw 2026.2.2 version but even that one wont work. Everytime i onboard with a Openrouter API key, the AI in the dashboard Chat simply wont reply. Just a blank page.

And yes, i have funds on my openrouter account

fallen lionBOT Apr 19, 2026, 5:53 PM

#

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

somber pelicanBOT Apr 19, 2026, 5:53 PM

#

dark frostBOT Apr 19, 2026, 5:55 PM

#

That’s frustrating. I’d stop wiping/downgrading for a minute, 2026.2.2 is pretty old and may just move you away from fixes.

Can you run these on the Mac mini and paste the output as text?

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

Then do one live test:

openclaw logs --follow

#

Keep that running, send one message in Dashboard Chat, then paste the log lines that appear right after.

For this symptom, the usual causes are:

OpenRouter auth is not actually loaded on the gateway host
the dashboard is connected, but the model request is failing and only logs show why
on macOS, if the gateway runs as a service, shell export OPENROUTER_API_KEY=... does not get inherited by launchd

So if models status --probe does not show OpenRouter as authenticated, that’s the first thing to fix.

Docs:

OpenRouter: https://docs.openclaw.ai/providers/openrouter
Troubleshooting: https://docs.openclaw.ai/help/troubleshooting

Paste those outputs and I’ll help you narrow it down.

cobalt flicker Apr 19, 2026, 6:05 PM

#

agentvanguard@Agents-Mac-mini ~ % openclaw --version

OpenClaw 2026.4.15 (041266a)

dark frostBOT Apr 19, 2026, 6:06 PM

#

Good, that helps, you’re on current OpenClaw now, so I would stop downgrading. We can debug this version directly.

Next, please paste these:

openclaw status --all
openclaw models status --probe
openclaw gateway status

Then do one live test:

openclaw logs --follow

While that is running, send one message in Dashboard Chat, then paste the new log lines that appear.

#

That should tell us pretty quickly if this is:

OpenRouter auth not loaded
a gateway/UI issue
a model request failing in the background

cobalt flicker Apr 19, 2026, 6:07 PM

#

agentvanguard@Agents-Mac-mini ~ % openclaw status --all

🦞 OpenClaw 2026.4.15 (041266a)
WhatsApp automation without the "please accept our new privacy policy".

│
OpenClaw status --all

Overview
┌─────────────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼──────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.4.15 │
│ OS │ macos 15.7.5 (arm64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 47ms · auth token · │
│ │ Agents-Mac-mini.local (10.99.99.6) app 2026.4.15 macos 15.7.5 │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 27936) │
│ Node service │ LaunchAgent not installed │

#

│ Agents │ 1 total · 1 bootstrapping · 1 active · 1 sessions │
│ Secrets │ none │
└─────────────────┴──────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬──────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼──────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴──────────────────────────────────────────────────────────────────────┘

Agents
┌────────────┬────────────────┬──────────┬──────────┬────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼────────────────────────────────────────────────┤
│ main │ PRESENT │ 1 │ just now │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴────────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/agentvanguard/.openclaw/openclaw.json
Bind: loopback

✓ Config: /Users/agentvanguard/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none

Gateway last log line:
2026-04-19T20:05:43.476+02:00 [agent/embedded] incomplete turn detected: runId=a51f2729-a368-411c-b968-1bad4f5ce1c1 sessionId=07a2c8df-f789-4a1f-bb12-af19e6b73fc0 stopReason=stop payloads=0 — surfacing error to user
! Port 18789
Port 18789 is already in use.

pid 27936 agentvanguard: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.

dark frostBOT Apr 19, 2026, 6:07 PM

#

Nice, this already helps.

Your gateway is up and reachable, so this does not look like a basic dashboard/connectivity failure.

The next check is the important one:

openclaw models status --probe

Please paste the whole OpenRouter section from that.

One strong clue here: you’re running the gateway as a macOS LaunchAgent. If your OpenRouter key only exists in your shell, .zshrc, or Terminal session, the daemon will not see it. That often causes exactly this kind of “chat sends, nothing comes back” behavior.

So after models status --probe, also do:

#

openclaw logs --follow

Then send one test message in Dashboard Chat and paste the new log lines.

I’m pretty suspicious this is now down to either:

OpenRouter auth not actually loaded into the daemon
a specific model request failing, which the logs should show immediately

#

This narrows it down a lot.

A few things from that output:

Port 18789 already in use is not the problem here, that just means your gateway is already running.
Bootstrap file PRESENT + 1 bootstrapping means OpenClaw still thinks the first-run bootstrap is not finished.
incomplete turn detected ... payloads=0 means the model call is dying before it returns any text, which matches your blank chat.

So the next command I really need is:

openclaw models status --probe

Please paste the OpenRouter part of that output.

If you want, also do this right after:

#

openclaw logs --follow

Then send one message in Dashboard Chat and paste the fresh lines.

Right now my best guess is:

OpenRouter auth is not actually available to the daemon, or
bootstrap is stuck and the model call is failing during first-run setup.

Also, because this is running as a LaunchAgent on macOS, a key that only exists in your shell will not reach the daemon.

cobalt flicker Apr 19, 2026, 6:08 PM

#

agentvanguard@Agents-Mac-mini ~ % openclaw models status --probe

🦞 OpenClaw 2026.4.15 (041266a) — More integrations than your therapist's intake form.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/minimax/minimax-m2.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : OpenRouter -> openrouter/auto
Configured models (2): openrouter/auto, openrouter/minimax/minimax-m2.5

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

openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...3f42c59e | env=sk-or-v1...62a5917d | source=env: OPENROUTER_API_KEY
perplexity effective=env:sk-or-v1...62a5917d | env=sk-or-v1...62a5917d | source=env: OPENROUTER_API_KEY

OAuth/token status

none

Auth probes
┌──────────────────────────────┬───────────────────────────┬─────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────────────┼───────────────────────────┼─────────────────────────────────────────┤
│ openrouter/minimax/minimax- │ openrouter:default (api_ │ ok · 3.7s │
│ m2.5 │ key) │ │
│ perplexity/- │ env (api_key) │ no_model · - │
│ │ │ ↳ No model available for probe │
└──────────────────────────────┴───────────────────────────┴─────────────────────────────────────────┘
Probed 1 target in 8.9s

dark frostBOT Apr 19, 2026, 6:10 PM

#

Perfect, this rules out the OpenRouter key itself.

Your probe is green:

OpenRouter auth is present
the model probe returned ok
so this is not a balance/API-key problem

That means the failure is almost certainly after auth, and your earlier status --all already gave the clue:

Bootstrap file PRESENT
1 bootstrapping
incomplete turn detected ... payloads=0

So OpenClaw is still stuck in the first-run bootstrap flow, and that turn is dying before any text gets back.

Next step, please do this:

#

openclaw logs --follow

Then send one message in Dashboard Chat and paste the fresh log lines.

My current read is:

OpenRouter works
bootstrap is stuck
the chosen model is not completing that bootstrap/tool flow cleanly

If that log confirms it, I’d try getting through bootstrap with a more tool-reliable model first, then switch back to your preferred OpenRouter route after onboarding.

Bootstrap docs: https://docs.openclaw.ai/start/bootstrapping

Small side note: I also see two different OpenRouter key suffixes in env vs stored auth. That is probably not the main blocker since probing works, but I would clean that up after we unstick bootstrap.

cobalt flicker Apr 19, 2026, 6:12 PM

#

18:02:13+00:00 info Updated ~/.openclaw/openclaw.json
18:02:13+00:00 info Workspace OK: ~/.openclaw/workspace
18:02:13+00:00 info Sessions OK: ~/.openclaw/agents/main/sessions
18:02:24+00:00 warn Config overwrite: /Users/agentvanguard/.openclaw/openclaw.json (sha256 5628598176f62371429c2451ef3bfc8141ff8546188d523601c74445041f4b36 -> 9626f5fa723bc9aaa646a7a0aa312423369d6f6e4f25eb1e822191ea2bf85c09, backup=/Users/agentvanguard/.openclaw/openclaw.json.bak)
18:02:25+00:00 info gateway {"subsystem":"gateway"} loading configuration…
18:02:25+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
18:02:25+00:00 info gateway {"subsystem":"gateway"} starting...
18:02:26+00:00 error (node:27936) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
18:02:26+00:00 warn Config overwrite: /Users/agentvanguard/.openclaw/openclaw.json (sha256 9626f5fa723bc9aaa646a7a0aa312423369d6f6e4f25eb1e822191ea2bf85c09 -> ed9482141f9bb9cfa8f119157479ce7f23e19f6594372cf901ee8383d72ec366, backup=/Users/agentvanguard/.openclaw/openclaw.json.bak)
18:02:26+00:00 info gateway {"subsystem":"gateway"} gateway: auto-enabled plugins:

openrouter/minimax/minimax-m2.5 model configured, enabled automatically.
18:02:28+00:00 info gateway {"subsystem":"gateway"} starting HTTP server...
18:02:28+00:00 info gateway/canvas {"subsystem":"gateway/canvas"} canvas host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /Users/agentvanguard/.openclaw/canvas)
18:02:28+00:00 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
18:02:28+00:00 info gateway {"subsystem":"gateway"} agent model: openrouter/minimax/minimax-m2.5
18:02:28+00:00 info gateway {"subsystem":"gateway"} ready (5 plugins: acpx, browser, device-pair, phone-control, talk-voice; 2.4s)

#

18:10:41+00:00 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=461e844029110a53a34feca8a32a55713e73aaa0d586b34d8276b784408c2f8f ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=b5aa74bc-92c4-4bbe-b72f-db103167d9e2
18:10:41+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
18:10:41+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
gateway connect failed: GatewayClientRequestError: pairing required
18:10:41+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":33,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"35aead3e-9196-45b5-840d-f7010183e987","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":52164,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:52164->127.0.0.1:18789","deviceId":"461e844029110a53a34feca8a32a55713e73aaa0d586b34d8276b784408c2f8f","requestId":"0306a558-707c-4d2b-a518-5d3f62f4b92f","reason":"scope-upgrade"} closed before connect conn=b5aa74bc-92c4-4bbe-b72f-db103167d9e2 peer=127.0.0.1:52164->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
18:10:42+00:00 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=461e844029110a53a34feca8a32a55713e73aaa0d586b34d8276b784408c2f8f ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=835ba26c-41aa-45af-8163-6b9c880861a6
18:10:42+00:00 error gateway connect failed: GatewayClientRequestError: pairing required

dark frostBOT Apr 19, 2026, 6:13 PM

#

These logs are just the gateway startup, and they actually look fine.

A few quick reads:

the punycode warning is noise, not the cause
OpenRouter loaded
the gateway started cleanly
so we are still back at the same likely culprit: bootstrap is stuck, not auth

At this point I’d do the fastest real test:

In the dashboard model picker, temporarily switch away from openrouter/minimax/minimax-m2.5
Pick a more tool-reliable OpenRouter route, for example an Anthropic- or OpenAI-backed one
Retry the onboarding/bootstrap chat

Why: bootstrap is not just plain text generation, it needs the model to handle the first-run workflow reliably.

#

If you want the exact proof before changing anything, do this:

openclaw logs --follow

Then send one dashboard message and paste only the new lines that appear after you hit send. Right now you only pasted the startup lines.

My honest guess now is: MiniMax via OpenRouter authenticates fine, but is choking on the bootstrap flow.

cobalt flicker Apr 19, 2026, 6:14 PM

#

18:10:42+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
18:10:42+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":34,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"2eab4812-4b62-4520-b0ac-5b65bc2482f1","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":52165,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:52165->127.0.0.1:18789","deviceId":"461e844029110a53a34feca8a32a55713e73aaa0d586b34d8276b784408c2f8f","requestId":"0306a558-707c-4d2b-a518-5d3f62f4b92f","reason":"scope-upgrade"} closed before connect conn=835ba26c-41aa-45af-8163-6b9c880861a6 peer=127.0.0.1:52165->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
18:10:43+00:00 info gateway {"subsystem":"gateway"} device pairing approved device=461e844029110a53a34feca8a32a55713e73aaa0d586b34d8276b784408c2f8f role=operator
18:10:45+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=9e4e57a6-e4b6-4b2c-9b4b-3bda7f46ed02 sessionId=07a2c8df-f789-4a1f-bb12-af19e6b73fc0 stopReason=stop payloads=0 — surfacing error to user

dark frostBOT Apr 19, 2026, 6:14 PM

#

Yep, this is the smoking gun.

This is not OpenRouter. Your client is being blocked by device pairing / scope upgrade:

pairing required
reason=scope-upgrade
current scopes: operator.read
requested scopes include operator.write, operator.admin, etc.

So the dashboard is getting refused before it can do the full workflow.

Run this on the Mac mini:

openclaw devices list
openclaw devices approve <requestId>

#

Important: use the current requestId from devices list, not the old one from the log, because it can change.

Then refresh the dashboard and try the chat again.

If it asks again, run openclaw devices list once more and approve the newest request. Docs: https://docs.openclaw.ai/cli/devices and https://docs.openclaw.ai/web/control-ui

So, good news, you do not need to wipe anything. We found the actual blocker.

#

Nice, that confirms pairing is fixed:

device pairing approved ✅

So there were actually two problems here. The remaining one is now this:

incomplete turn detected ... payloads=0

That means the model turn is still ending without returning any visible output.

What I’d do next, in this order:

Hard refresh the dashboard, or reopen it
Start a brand new chat/session (New Chat or /new)
Temporarily switch away from openrouter/minimax/minimax-m2.5
Retry the onboarding/bootstrap chat with a more tool-reliable OpenRouter route

#

My guess is the earlier session got wedged during the pairing failure, and MiniMax is still not handling the bootstrap flow cleanly.

If a fresh session + different model still gives payloads=0, then the next thing to target is the stuck bootstrap state itself.

cobalt flicker Apr 19, 2026, 6:16 PM

#

i only have openrouter configured with minimax 2.5

dark frostBOT Apr 19, 2026, 6:17 PM

#

That’s okay, you do not need another provider for this test.

With the same OpenRouter key, you can still use a different OpenRouter route. In your earlier output, you already had:

openrouter/minimax/minimax-m2.5
openrouter/auto

So the simplest next test is:

Refresh the dashboard
Start a new chat
Temporarily switch to openrouter/auto
Retry onboarding/bootstrap

If you prefer CLI, that is:

#

openclaw models set openrouter/auto

Then retry.

If openrouter/auto works, then the issue is very likely the specific minimax-m2.5 route during bootstrap. If openrouter/auto still dies with payloads=0, then we’re down to the stuck bootstrap state itself.

cobalt flicker Apr 19, 2026, 6:19 PM

#

yup still stuck

dark frostBOT Apr 19, 2026, 6:20 PM

#

Okay, then I think we’re down to the stuck bootstrap state itself.

Why I think that:

auth probe was fine
pairing is fixed
openrouter/auto still gets payloads=0
your earlier status showed Bootstrap file PRESENT
BOOTSTRAP.md is supposed to disappear after first-run completes

So I’d try this reversible fix, not a full wipe:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then:

#

hard refresh the dashboard
start a new chat
try again

This is safer than nuking OpenClaw, because it only moves the stuck first-run file out of the way.

Bootstrap docs: https://docs.openclaw.ai/start/bootstrapping

If that still fails, the next thing I’d target is the session store, not the whole install.

cobalt flicker Apr 19, 2026, 6:21 PM

#

still wont reply 🙂

dark frostBOT Apr 19, 2026, 6:22 PM

#

Okay, then I’d stop chasing the model now. At this point the most likely remaining culprit is stale session state.

You already proved:

OpenRouter auth works
pairing is fixed
bootstrap file was handled
but turns still end with payloads=0

So I would do a session reset only, not a full wipe.

mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.bak
openclaw gateway restart

Then:

#

refresh the dashboard
start a brand new chat
try again

This keeps your auth/config, and only resets the session store.

Docs note: if you only want to reset sessions, the agents/<agentId>/sessions/ folder is the part to clear, while keeping auth-profiles.json in place. https://docs.openclaw.ai/pi-dev

If this still does not fix it, I’d treat it as a real bug and ask you to file a GitHub issue with the exact incomplete turn detected ... payloads=0 line:
https://github.com/openclaw/openclaw/issues

cobalt flicker Apr 19, 2026, 6:23 PM

#

yup still not fixed

dark frostBOT Apr 19, 2026, 6:24 PM

#

Okay, then I’d stop spending time on local resets. I’m pretty convinced this is a real bug, not you misconfiguring OpenRouter.

You already ruled out a lot:

current OpenClaw version
OpenRouter auth/probe works
pairing/scope upgrade was approved
openrouter/auto also fails
bootstrap file/session reset did not clear it

The useful smoking-gun log is still:

incomplete turn detected ... payloads=0

At this point, please file a GitHub issue here:

#

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

Suggested title:

Dashboard chat blank after onboarding with OpenRouter on macOS, logs show incomplete turn detected ... payloads=0

Please include:

openclaw --version
macOS version + Mac mini M4
openclaw status --all
openclaw models status --probe
the logs showing:
- pairing required
- device pairing approved
- incomplete turn detected ... payloads=0
that openrouter/minimax/minimax-m2.5 and openrouter/auto both reproduce it

#

If you want, I can help you write the issue text in one clean paste.

cobalt flicker Apr 19, 2026, 6:27 PM

#

yes please help me write it in one clean paste

dark frostBOT Apr 19, 2026, 6:28 PM

#

Paste this into a GitHub issue:

Title: Dashboard chat stays blank after onboarding with OpenRouter on macOS, logs show incomplete turn detected ... payloads=0

Body:

Summary

After onboarding with an OpenRouter API key, the Dashboard Chat stays blank and the AI never replies.

I have confirmed this is not just missing OpenRouter funds/auth, because the OpenRouter auth probe succeeds.

Environment

OpenClaw 2026.4.15 (041266a)
macOS 15.7.5 on Mac mini M4 (arm64)
Node 22.22.2

#

Local gateway on 127.0.0.1:18789
Only provider configured: OpenRouter
OpenRouter funds are available

Repro

Run onboarding with OpenRouter API key
Open Dashboard Chat
Send a message
Chat stays blank, no reply appears

Expected

Dashboard Chat should return the onboarding/bootstrap response or a normal chat reply.

Actual

#

Dashboard Chat stays blank, and logs show an incomplete turn with zero payloads.

What I checked

`openclaw models status --probe`

OpenRouter auth appears healthy, and probing succeeds:

Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : openrouter/minimax/minimax-m2.5
Configured models (2): openrouter/auto, openrouter/minimax/minimax-m2.5

Auth overview
- openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1... | env=sk-or-v1... | source=env: OPENROUTER_API_KEY

#


Auth probes
Model: openrouter/minimax/minimax-m2.5
Profile: openrouter:default (api_key)
Status: ok · 3.7s

So this does not look like a simple OpenRouter auth/billing failure.

Relevant logs

At first I hit a pairing/scope issue:

error gateway connect failed: GatewayClientRequestError: pairing required

#

warn gateway/ws ... "cause":"pairing-required" ... "reason":"scope-upgrade"

Then I approved the device pairing successfully:

info gateway {"subsystem":"gateway"} device pairing approved device=461e844029110a53a34feca8a32a55713e73aaa0d586b34d8276b784408c2f8f role=operator

But after that, the chat still did not reply, and the main failure became:

warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=9e4e57a6-e4b6-4b2c-9b4b-3bda7f46ed02 sessionId=07a2c8df-f789-4a1f-bb12-af19e6b73fc0 stopReason=stop payloads=0 — surfacing error to user

Other details

#

Earlier openclaw status --all showed bootstrap was still pending:

Agents: 1 total · 1 bootstrapping · 1 active · 1 sessions
Agent: main
Bootstrap file: PRESENT

Things I already tried

updated to latest OpenClaw (2026.4.15)
confirmed OpenRouter auth probe succeeds
approved the device scope upgrade / pairing request
refreshed dashboard and started a new chat
switched from openrouter/minimax/minimax-m2.5 to openrouter/auto
moved ~/.openclaw/workspace/BOOTSTRAP.md aside and restarted gateway
reset ~/.openclaw/agents/main/sessions/

#OpenClaw Oboard with OpenRouter API