Dashboard "pairing required" after fresh install | Friends of the Crustacean 🦞🤝 | Page 1

reef ermine Apr 18, 2026, 3:33 AM

#

OpenClaw 2026.4.15 on Ubuntu 24.04 VPS. Fresh install, Kimi working fine (models probe ok), but dashboard web UI won't accept any messages — keeps saying "pairing required" in logs.
Already tried:

gateway.controlUi.dangerouslyDisableDeviceAuth=true
gateway.controlUi.allowInsecureAuth=true
openclaw devices approve <deviceId>
Cleared all sessions

Logs show:
GatewayClientRequestError: pairing required
scope-upgrade: operator.read → operator.admin,operator.write
deviceId: 5c44b340168fdcf6e2188be2751e9f88ff22a1d044a2dd3c756c038026d13308
Dashboard connects (shows UI, token works) but messages don't go through. TUI also connects but messages disappear without response.
How do I approve this device or disable pairing completely?

civic vineBOT Apr 18, 2026, 3:33 AM

#

sinful orbitBOT Apr 18, 2026, 3:33 AM

#

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

tulip lanceBOT Apr 18, 2026, 3:36 AM

#

I think the main issue is simpler than it looks, you're approving the wrong identifier.

openclaw devices approve wants the pending requestId, not the deviceId.
The 5c44... value in your log is the deviceId.

This log:

scope-upgrade: operator.read → operator.admin,operator.write

means the dashboard/TUI connected with a lower scope first, then chat.send tried to upgrade scopes and created a new pending pairing request.

Run this on the VPS:

openclaw devices list
openclaw devices approve <requestId>

#

A couple important gotchas:

Re-run openclaw devices list right before approving. Retries can supersede the old request and create a new requestId.
gateway.controlUi.allowInsecureAuth=true does not bypass pairing. It is only for localhost insecure HTTP compatibility.
gateway.controlUi.dangerouslyDisableDeviceAuth=true is break-glass, but it does not auto-upgrade an already paired device from operator.read to broader scopes.

If you want a clean reset for that browser/device:

openclaw gateway restart
openclaw devices remove 5c44b340168fdcf6e2188be2751e9f88ff22a1d044a2dd3c756c038026d13308

Then reconnect, and either approve the new requestId or test again with the break-glass flag enabled.

Docs:

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

#

If openclaw devices list shows no pending request for that device, paste that output plus openclaw gateway status, because then I’d suspect the service is reading a different config than the CLI.

reef ermine Apr 18, 2026, 3:42 AM

#

Device is now paired with full scopes (operator.admin, operator.read, operator.write, etc.) but dashboard still not responding to messages. Messages disappear after sending, no response from agent.
openclaw devices list shows device as paired correctly.
Kimi probe is ok (25s response time). Gateway is running.
Any idea what's blocking the agent from responding?

tulip lanceBOT Apr 18, 2026, 3:44 AM

#

Yep, at this point it no longer smells like pairing.

If both Dashboard and TUI accept the message, but nothing ever comes back, the usual split is:

the agent runtime is failing after chat.send starts, or
the model/provider can probe, but fails on a real agent turn

models probe only proves auth/basic reachability, not a full agent run.

Run this on the VPS:

openclaw status --all
openclaw gateway status
openclaw doctor
openclaw logs --follow

#

Then, in another shell, test both paths directly:

openclaw agent --message "reply with pong"
openclaw infer model run --model <exact-model-ref> --prompt "reply with pong" --json

How to read that:

infer model run fails/hangs
→ provider/model path is the blocker
infer model run works, but agent --message fails/hangs
→ agent-runtime compatibility issue, most commonly:
- tool schema incompatibility, try compat.supportsTools: false
- string-only backend, try compat.requiresStringContent: true if logs mention messages[].content

#

both work in CLI, but Dashboard/TUI still eat messages
→ then I’d look at event streaming / stale UI session state, not pairing

Also, check openclaw status for a stuck bootstrapping count. If it stays there forever, the agent never really starts.

Docs:

If you paste:

the first error after sending a message from openclaw logs --follow
output of openclaw agent --message "reply with pong"
output of openclaw infer model run --model <...> --prompt "reply with pong" --json

I can narrow it down pretty fast.

reef ermine Apr 18, 2026, 3:46 AM

#

Session file keeps getting locked. Every time I try to run anything I get:
Error: session file locked (timeout 10000ms): pid=11797 /root/.openclaw/agents/main/sessions/fcf1a9e8-fc5f-4504-92ee-0ec13677b0db.jsonl.lock
I kill the pid and delete the lock file but it comes back. What process keeps locking this session file and how do I stop it?

tulip lanceBOT Apr 18, 2026, 3:47 AM

#

That .jsonl.lock is the session transcript write lock. It is normally held by the process actively writing that session, most often the gateway / agent run itself.

So the important bit is the PID in the error:

pid=11797

That is the process to inspect, not the lock file.

Try this order:

ps -fp 11797
openclaw gateway status
openclaw gateway stop

#

openclaw doctor --fix
openclaw gateway start
openclaw logs --follow

A few useful notes:

If the lock comes back immediately after you kill the PID, something is supervising/restarting it, usually the gateway service.
If openclaw gateway stop makes the lock stop reappearing, then yes, it was the gateway.
openclaw doctor --fix is the documented way to clean up stale session lock files. Don’t keep deleting a live lock file by hand, it’ll just come back.

If gateway stop says it’s stopped, but the lock still reappears, then you likely have a second OpenClaw process running. In that case check:

pgrep -af openclaw

#

What I’d want to see next if it still loops:

ps -fp 11797
openclaw gateway status
pgrep -af openclaw

Docs: https://docs.openclaw.ai/gateway/doctor

If you paste those three outputs, I can help pinpoint which process is re-locking it.

reef ermine Apr 18, 2026, 3:56 AM

#

Update: gateway is now running correctly (pid 12654, state active, RPC probe ok). But dashboard still eats messages without response. Here are the three outputs:
ps -fp 11797 → no output (process gone)
openclaw gateway status → Runtime: running (pid 12654, state active), RPC probe: ok
pgrep -af openclaw → 12654 openclaw-gateway
So gateway is healthy now. But messages sent from dashboard still with no agent response. What's next?

tulip lanceBOT Apr 18, 2026, 3:56 AM

#

Nice, that clears the lock/gateway side. So the next split is:

does the agent run at all, or
is this only the dashboard/browser state

I’d do these in order:

openclaw logs --follow

Then in a second shell:

openclaw agent --message "reply with pong"
openclaw infer model run --model <exact-model-ref> --prompt "reply with pong" --json

#

How to read it:

infer model run fails/hangs
→ model/provider path is the problem
infer model run works, but agent --message fails/hangs
→ full agent turn is the problem (probe is not enough)
both commands work
→ this is probably dashboard/browser state, not the gateway

If it looks browser-only, the fastest test is:

open the dashboard in a private/incognito window, or
clear site storage for the dashboard origin and reconnect

That forces a fresh browser/device-token state.

#

If the private window fixes it, I’d clean up the old paired browser token:

openclaw devices rotate --device <deviceId> --role operator

and if needed, fully reset that browser pairing:

openclaw devices remove <deviceId>
openclaw devices list
openclaw devices approve <requestId>

Docs:

#

If you paste the outputs of:

openclaw agent --message "reply with pong"
openclaw infer model run --model <exact-model-ref> --prompt "reply with pong" --json

I can tell pretty quickly whether this is model-side or browser-side.

reef ermine Apr 18, 2026, 4:06 AM

#

Both agent --message and infer model run fail with session file locked:
FailoverError: session file locked (timeout 10000ms): pid=12654 /root/.openclaw/agents/main/sessions/fcf1a9e8-fc5f-4504-92ee-0ec13677b0db.jsonl.lock
pid=12654 is the gateway process itself. Killing the pid and deleting the lock file doesn't help — it comes back immediately because the gateway recreates it.
What's the correct way to clear a session lock that's held by the gateway?

tulip lanceBOT Apr 18, 2026, 4:08 AM

#

The key detail is that this is a live lock, not a stale one.

pid=12654 is the running gateway, so the gateway is intentionally holding that specific transcript lock. In that case, the correct fix is not “delete the lock file”, it’s:

stop/abandon that stuck session, or
start a fresh session

openclaw doctor --fix only cleans up stale locks, meaning dead PID / old orphaned lock files. It will not remove a live gateway-held lock.

What I’d try next:

openclaw agent --session-id scratch-1 --message "reply with pong"
openclaw tui --session scratch-1

For the dashboard/chat side, send a standalone:

#

/new

or

/reset

That should force a new session instead of reusing the wedged one.

Why this matters:

the lock file is for one transcript file
your broken file is:
fcf1a9e8-fc5f-4504-92ee-0ec13677b0db.jsonl
a fresh session should create a different transcript and bypass that stuck lock

#

If the fresh session works, then the old session is just poisoned/stuck, and you can ignore/reset it.

If even a brand new --session-id scratch-1 still hits the same lock/file, that’s not expected and I’d treat it as a bug. In that case please paste:

openclaw status --all
openclaw logs --follow

and if it keeps reproducing, file it here:
https://github.com/openclaw/openclaw/issues

Docs:

If you want, paste what happens with --session-id scratch-1, that’s the fastest next checkpoint.

reef ermine Apr 18, 2026, 4:15 AM

#

Fresh session --session-id scratch-1 also times out. Logs show:
embedded run timeout: runId=... timeoutMs=600000
Profile moonshot:default timed out
moonshot/kimi-k2.5 produced no reply before the idle watchdog
The model probe returns ok in 25s but full agent turns always timeout after 10 minutes. Is Kimi incompatible with the embedded agent runtime? Should I try compat.supportsTools: false or compat.requiresStringContent: true?

tulip lanceBOT Apr 18, 2026, 4:16 AM

#

Yep, this is finally looking like a model/runtime compatibility problem, not pairing.

Given your logs:

moonshot/kimi-k2.5 produced no reply before the idle watchdog
probe works, but full agent turns hang
no explicit messages[].content validation error

I’d try compat.supportsTools: false first, not requiresStringContent.

Why:

supportsTools: false is the usual fix when a model accepts the request, but stalls on the full agent prompt + tool schema
requiresStringContent: true is mainly for backends that explicitly complain about messages[].content needing to be a plain string

So my order would be:

add compat.supportsTools: false to the existing moonshot -> kimi-k2.5 model entry

#

restart the gateway
test again with a fresh session id, like scratch-2

Only try compat.requiresStringContent: true if the next logs start showing content-shape errors.

I would not just raise the timeout yet. If the model never emits a first chunk, longer timeout usually just makes the wait more painful.

Relevant docs:

If you want, the next thing to paste is just the moonshot model block from your config, and I can point to the exact spot to add the compat flag.

reef ermine Apr 18, 2026, 4:19 AM

#

Here's my moonshot model block:
json"moonshot": {
"baseUrl": "https://api.moonshot.ai/v1",
"api": "openai-completions",
"models": [
{
"id": "kimi-k2.5",
"name": "Kimi K2.5",
"reasoning": false,
"input": ["text", "image"],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 262144,
"maxTokens": 262144,
"api": "openai-completions"
}
]
}
Where exactly do I add compat.supportsTools: false?

tulip lanceBOT Apr 18, 2026, 4:20 AM

#

Right inside the kimi-k2.5 model object, as a sibling of api, contextWindow, maxTokens, etc.

Like this:

"moonshot": {
  "baseUrl": "https://api.moonshot.ai/v1",
  "api": "openai-completions",
  "models": [
    {
      "id": "kimi-k2.5",
      "name": "Kimi K2.5",
      "reasoning": false,
      "input": ["text", "image"],
      "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
      "contextWindow": 262144,

#

      "maxTokens": 262144,
      "api": "openai-completions",
      "compat": {
        "supportsTools": false
      }
    }
  ]
}

Then:

restart the gateway
test with a fresh session again (scratch-2)

If it still hangs after that, the next thing I’d try is adding:

#

"requiresStringContent": true

inside that same compat block, so:

"compat": {
  "supportsTools": false,
  "requiresStringContent": true
}

Docs: https://docs.openclaw.ai/gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail

If you want, paste the next error after trying supportsTools: false, and I’ll help you decide whether to add requiresStringContent too.

reef ermine Apr 18, 2026, 4:32 AM

#

Tried supportsTools: false and requiresStringContent: true — both still timeout. Logs show same pattern:
Profile moonshot:default timed out
moonshot/kimi-k2.5 produced no reply before the idle watchdog
No content-shape errors in logs at all. Just pure timeout every time. Model probe returns ok in 25s but agent turns never get a first chunk.
Is Kimi k2.5 actually compatible with OpenClaw's embedded agent runtime? Or is there a known issue?

tulip lanceBOT Apr 18, 2026, 4:34 AM

#

I don’t think this is “Kimi is incompatible with OpenClaw” in general.

I think this is specifically Moonshot thinking mode.

Your symptoms match the Moonshot behavior pretty closely:

probe works
no content-shape errors
full agent turn never emits a first visible chunk
idle watchdog fires

OpenClaw’s Moonshot docs explicitly support forcing:

thinking: { type: "disabled" }

and the repo’s live Moonshot test does exactly that, because otherwise Moonshot can burn time/tokens in hidden reasoning and never emit visible assistant text.

#

So I’d try this next, under agents.defaults.models, not under the provider model catalog:

{
  agents: {
    defaults: {
      models: {
        "moonshot/kimi-k2.5": {
          params: {
            thinking: { type: "disabled" },
          },
        },
      },
    },
  },
}

#

Important bit:

reasoning: false in the model catalog is not the same thing
you want the actual request param: thinking.type = "disabled"

Then:

restart the gateway
test with a fresh session
optionally also send /think off in the session to confirm runtime behavior

Docs: https://docs.openclaw.ai/providers/moonshot

So, short answer: not a known blanket incompatibility, but yes, there is a Moonshot/Kimi behavior here, and thinking.type=disabled is the next real fix I’d try.

If that still times out after a fresh session, then I’d call it a likely bug and point you to GitHub issues with the exact log snippet.

reef ermine Apr 18, 2026, 4:49 AM

#

Tried thinking: {type: "disabled"} under agents.defaults.models — still timing out. Fresh session, gateway restarted. Same behavior: probe ok, agent turns never emit first chunk. /think off in session also no response.
Is there anything else to try before filing a GitHub issue?

tulip lanceBOT Apr 18, 2026, 4:50 AM

#

At this point, I wouldn’t keep guessing config knobs.

The last really useful thing before filing an issue is a direct Moonshot chat-completions smoke test, because models probe is too shallow.

Since Moonshot is OpenAI-compatible, try this outside OpenClaw:

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k2.5",
    "messages": [
      { "role": "user", "content": "Reply with exactly smoke-ok" }
    ],
    "thinking": { "type": "disabled" },

#

    "stream": false,
    "max_tokens": 64
  }'

If that works, do one more test with streaming:

curl -N https://api.moonshot.ai/v1/chat/completions \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k2.5",
    "messages": [
      { "role": "user", "content": "Reply with exactly smoke-ok" }

#

    ],
    "thinking": { "type": "disabled" },
    "stream": true,
    "max_tokens": 64
  }'

How to read it:

direct non-streaming + streaming both work
→ this really does look like an OpenClaw Moonshot/Kimi runtime/streaming bug, so I’d file a GitHub issue
direct non-streaming works, streaming hangs
→ likely a provider-side streaming compatibility issue, still worth filing with your OpenClaw logs because that’s exactly where agent turns break
direct API hangs too

#

→ this is probably not OpenClaw, it’s Moonshot/account/endpoint behavior

If you do file, include:

your Moonshot provider block
the timeout log lines
whether the two curl tests above worked or hung
your version: 2026.4.15

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

If you paste the result of those two curl tests, I can tell you pretty confidently whether this is OpenClaw-side or Moonshot-side.

reef ermine Apr 18, 2026, 4:57 AM

#

Both curl tests work perfectly:

Non-streaming: returns smoke-ok immediately
Streaming: chunks arrive correctly, [DONE] received

So Moonshot API is fine. The timeout is happening inside OpenClaw's agent runtime, not at the provider level.
Version: 2026.4.15
Model: moonshot/kimi-k2.5
Config: thinking: {type: "disabled"}, supportsTools: false, requiresStringContent: true
Logs show: moonshot/kimi-k2.5 produced no reply before the idle watchdog
Filing as a bug?

tulip lanceBOT Apr 18, 2026, 4:58 AM

#

Yes, I’d file that as a bug.

You’ve already done the right isolation:

direct Moonshot API works
direct Moonshot streaming works
OpenClaw agent turns never get a first chunk
thinking: {type:"disabled"}, supportsTools:false, and requiresStringContent:true don’t change it

That’s a pretty solid repro for an OpenClaw-side Moonshot/Kimi runtime bug on 2026.4.15.

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

I’d include exactly this:

Version: 2026.4.15

#

OS: Ubuntu 24.04 VPS
Model: moonshot/kimi-k2.5
Config tried: thinking.type=disabled, compat.supportsTools=false, compat.requiresStringContent=true
Observed: moonshot/kimi-k2.5 produced no reply before the idle watchdog
What works: direct curl non-streaming + streaming to Moonshot both succeed
What fails: openclaw agent, infer model run, dashboard/TUI agent turns
Extra note: fresh session + gateway restart + repaired pairing did not help

A good title would be:

[Bug]: moonshot/kimi-k2.5 agent turns timeout before first chunk, direct Moonshot API works

Short-term workaround, I’d use another provider/model for now until that path is fixed.

If you want, I can help you tighten the issue body into a clean copy-paste report.

reef ermine Apr 18, 2026, 1:55 PM

#

Is MiniMax compatible as an LLM provider in OpenClaw 2026.4.15? Specifically the text/chat models, not Hailuo video. If yes, which model would you recommend and is there a known-good config?

tulip lanceBOT Apr 18, 2026, 1:57 PM

#

Yes, MiniMax text/chat is supported in 2026.4.15.

For OpenClaw, the two main text/chat paths are:

minimax → API key, Anthropic-compatible endpoint
minimax-portal → OAuth / Coding Plan

The docs default to MiniMax M2.7, so that’s the safest place to start. For the freshest “which exact MiniMax tier feels best lately” advice, I’d still ask in #models since that changes fast.

Docs:

MiniMax provider: https://docs.openclaw.ai/providers/minimax
Models/community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Known-good setup

Easiest path:

#

openclaw onboard --auth-choice minimax-global-api

Then verify:

openclaw models list --provider minimax

Known-good manual config

{
  env: { MINIMAX_API_KEY: "sk-..." },
  agents: {

#

    defaults: {
      model: { primary: "minimax/MiniMax-M2.7" },
    },
  },
  models: {
    mode: "merge",
    providers: {
      minimax: {
        baseUrl: "https://api.minimax.io/anthropic",
        apiKey: "${MINIMAX_API_KEY}",
        api: "anthropic-messages",
        models: [
          {
            id: "MiniMax-M2.7",
            name: "MiniMax M2.7",

#

            reasoning: true,
            input: ["text", "image"],
            cost: { input: 0.3, output: 1.2, cacheRead: 0.06, cacheWrite: 0.375 },
            contextWindow: 204800,
            maxTokens: 131072,
          },
          {
            id: "MiniMax-M2.7-highspeed",
            name: "MiniMax M2.7 Highspeed",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 0.6, output: 2.4, cacheRead: 0.06, cacheWrite: 0.375 },
            contextWindow: 204800,
            maxTokens: 131072,
          },

#

        ],
      },
    },
  },
}

Important MiniMax caveat

On the Anthropic-compatible streaming path, OpenClaw already has a MiniMax-specific guard:

it disables MiniMax thinking by default unless you explicitly set thinking yourself

That’s actually good here, because MiniMax’s stream format can otherwise get weird with reasoning output.

So, short version:

#Dashboard "pairing required" after fresh install

Known-good setup

Known-good manual config

Important MiniMax caveat