Step 'pair-operator' fails due to a connection error

[cugwmui]

While using the wizard to configure the Openclaw dedicated instance, it fails at the second last step of pair-operator.

The exact error is:

Setup failed
Step 'pair-operator' failed: Operator connection failed: Error

Logs and screenshot attached.

pair-operator error log.json

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 3, 2026, 8:27 AM ET / 12:27 UTC.

Summary
This should stay open: the attached report is concrete, current main still uses the localhost setup path that can fail before operator pairing, and the overlapping repair in #547 is still open and proof-blocked rather than a merged fix.

Reproducibility: no. high-confidence current-main runtime reproduction was performed in this Linux review environment. The attached log and current source make the failure source-reproducible enough to keep open, but the final repro should run on Windows with WSL networking.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
Maintainers should decide whether to land the relevant proven subset of #547 or request a narrower replacement PR before ClawSweeper opens duplicate repair work.

Review details

Best possible solution:

Land a narrow, tested setup fix that uses a Windows-reachable loopback URL and waits for Windows-side gateway reachability before pair-operator, either by proving the relevant subset of #547 or replacing it with a smaller PR.

Do we have a high-confidence way to reproduce the issue?

No high-confidence current-main runtime reproduction was performed in this Linux review environment. The attached log and current source make the failure source-reproducible enough to keep open, but the final repro should run on Windows with WSL networking.

Is this the best way to solve the issue?

Unclear. The likely technical direction is 127.0.0.1 plus a Windows-side port-reachability wait before pair-operator, but maintainers should decide whether to land that from the broad open PR or ask for a focused replacement.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact reporter machine networking mode is unknown; a fix should be proven on a Windows WSL setup where Windows-side localhost forwarding is slow or refused.
• The broad overlapping repair in fix: setup engine slow-machine fixes and config audit #547 may cover the root cause, but it is still open and proof-blocked, so it is not safe to close this issue as resolved.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 53ff55aff974.

Label changes

Label changes:

• add P1: The report blocks first-run local gateway setup at the operator pairing step for a real user.
• add impact:auth-provider: The failure is in the operator pairing and credential handoff path before the Windows device can be paired.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P1: The report blocks first-run local gateway setup at the operator pairing step for a real user.
• impact:auth-provider: The failure is in the operator pairing and credential handoff path before the Windows device can be paired.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.SetupEngine.Tests/OpenClaw.SetupEngine.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore

What I checked:

• Repository policy read: AGENTS.md was read fully; its connection, pairing, setup-engine, and validation guidance is relevant to this issue review. (AGENTS.md:1, 53ff55aff974)
• Attached log shows real failure: The downloaded log shows mint-token succeeded, pair-operator created a gateway record, then three attempts to connect to ws://localhost:18789 failed with SocketException 10061 before the step completed as failed.
• Screenshot matches failure: The issue screenshot shows the setup UI reporting: Step 'pair-operator' failed: Operator connection failed: Error.
• Current default still uses localhost: Current main still derives the setup gateway URL as ws://localhost:{GatewayPort}. (src/OpenClaw.SetupEngine/SetupContext.cs:35, 53ff55aff974)
• Gateway health only checks inside WSL: StartGatewayStep declares the gateway running after a curl from inside WSL to 127.0.0.1 succeeds; it does not prove the Windows host can reach the forwarded port before pair-operator starts. (src/OpenClaw.SetupEngine/SetupSteps.cs:1384, 53ff55aff974)
• Pair-operator fails on first Error outcome: PairOperatorStep connects to ctx.GatewayUrl, waits 15 seconds, and returns Operator connection failed when WaitForConnectionOrPairing observes ConnectionStatus.Error. (src/OpenClaw.SetupEngine/SetupSteps.cs:1613, 53ff55aff974)

Likely related people:

• ranjeshj: Authored the out-of-process SetupEngine work, several recent WSL setup hardening commits touching SetupSteps/SetupContext, and the open overlapping repair PR for localhost/port-forwarding pairing failures. (role: feature owner and recent repair author; confidence: high; commits: cefce3952ab1, 98d0760cb5b6, ff3a7cc53736; files: src/OpenClaw.SetupEngine/SetupSteps.cs, src/OpenClaw.SetupEngine/SetupContext.cs, src/OpenClaw.SetupEngine/default-config.json)
• kmahone: GitHub file history shows a recent local setup touch to SetupSteps.cs after the SetupEngine redesign, making this a useful secondary routing candidate. (role: recent area contributor; confidence: medium; commits: 9106725567af; files: src/OpenClaw.SetupEngine/SetupSteps.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.