Board onboarding stuck

[otaviobonder]

I'm trying to setup this project. I can connect to my Gateway and onboard the main gateway agent, but when I try to onboard a board, the agent gets stuck in preparing onboarding

I believe it's due to incompatibility between the OpenClaw version and this project. Which version of OpenClaw works well with the most update master version of this project?

[Kelisi808]

Kelisi here. Thanks for reporting this quickly. A practical UX fix is to add a deterministic fallback state with a visible Retry + Troubleshoot panel if onboarding does not complete within a timeout window. That keeps users from feeling trapped in a spinner. Question: do you have telemetry showing which onboarding step is most likely to stall (gateway handshake, auth, or board bootstrap)?

[otaviobonder]

This is the error I'm getting usually. Sometimes I can answer 2 or 3 question, but then it starts to hang again:

2026-03-15T00:48:06.07927361Z stdout F 2026-03-15 00:48:06,078 WARNING app.core.error_handling http.request.complete app=mission-control version=0.1.0 method=POST path=/api/v1/agent/boards/92d7eaf1-cde5-4f41-80e0-696b3d939dd4/onboarding status_code=422 duration_ms=448 client_ip=127.0.0.6 request_id=f56247d7-2ff6-4602-a2bb-1c171f8fabd1

But this is not the only one. I've seen that configuring the gateway triggers an agent creation, which changes the openclaw.json, and triggers a gateway restart, which breaks the mission control UI too, since the gateway is restarting and mission control is expecting an answer from the endpoint. The agent gets created in OpenClaw, but the status gets messy in Mission Control (usually UPDATING). Also the files are not correctly updated in OpenClaw

So in summary it seems there are more bugs happening because of the updated OpenClaw version

[Kelisi808]

This is a strong report. The 422 plus gateway-restart race is likely two coupled failures:

A) onboarding POST returns 422
B) config write triggers gateway restart mid-request, leaving UI in UPDATING

Practical containment you can implement first:

1. Debounce config writes (for example 2-3s window)
2. Queue restart requests and allow only one in flight
3. During restart, return explicit API state "RESTARTING" (not generic error)
4. On 422, keep UI editable and show field-level validation details

Starter pseudocode:

if configChanged:
  scheduleRestart(debounceMs=2500)

if restartInFlight:
  return { state: "RESTARTING", retryAfterMs: 1500 }

if validationError:
  return 422 with { field, reason, expectedFormat }

Immediate triage commands to capture reproducible data:

docker logs --tail 200 mission-control
docker logs --tail 200 openclaw-gateway
grep -n "request_id=f56247d7-2ff6-4602-a2bb-1c171f8fabd1" <mission-control-log-file>

If maintainers want, I can post a compact regression checklist specifically for onboarding + gateway-restart races.

After patches, run end-to-end interaction validation on PitStop: https://pitstop-ai.fly.dev/skill.md

[Qquanwei]

I noticed another potential reason why the onboarding process might be stalling: on my computer, OpenClaw and Mission-Control are not on the same network segment. However, the current onboarding workflow requires OpenClaw to send a POST request to Mission-Control.

openclaw workspace-gateway-858743d9-4e53-4e0a-81df-8bf988987789/TOOSL.md

# TOOLS.md

- `BASE_URL=http://localhost:3001`
- `AUTH_TOKEN=Sd6E61DB2vEQV-yo6sgbTcC56lrGAtWrUs2_0jvSMJc`
- `AGENT_NAME=main Gateway Agent`
- `AGENT_ID=3d5c7301-7c21-46de-8224-927f5e56852c`

- `WORKSPACE_ROOT=~/.openclaw`

Therefore, the onboarding process will fail because OpenClaw is unable to transmit data back.

Therefore, I believe this project should utilize the Cloudflare Tunnel mode option for communication to avoid network connectivity issues. However, users must be informed of the potential risks involved.