OpenClaw Setup Not Working

[JMitch0214]

setup-engine-20260609-003711.txt

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 27, 2026, 4:09 PM ET / 20:09 UTC.

Summary
Keep open: the attached setup log shows a real v0.6.3 local gateway setup failure, and current main only partially mitigates adjacent device-pair diagnostics while the same setup/rollback/golden-path work remains tracked in open related issues.

Reproducibility: yes. at source/log level: the attached v0.6.3 log shows pair-node failing with device signature expired and then rolling back the local gateway. I did not run a live current-main Windows/WSL setup reproduction in this read-only review.

Root-cause cluster
Relationship: same_root_cause
Canonical: #677
Summary: This setup failure shares the pair-node failure and rollback/deletion symptom tracked by the earlier open rollback issue, while the broader local-gateway epic remains the coordinating product track.

Members:

• canonical: OpenClawGateway being deleted/rolled back after the failed setup. #677 - The earlier open issue has the same reporter, pair-node failure context, device signature/plugin evidence in comments, and explicit rollback/deletion outcome.
• partial_overlap: 🦞 Tracking: Local gateway is the golden path for the Windows companion app #834 - The open epic lists this issue as a child symptom under the local Windows gateway golden path.
• partial_overlap: Update setup flow — default to the local Windows gateway #840 - The setup-flow child issue names this issue as a related symptom but covers a broader default onboarding path.
• partial_overlap: [Repo Assist] fix(setup): surface actionable error when gateway device-pair plugin is not loaded #747 - The merged PR improves diagnostics for the older gateway device-pair plugin path that appears in the logs, but it does not settle the rollback policy or prove this full setup report resolved.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
Manual review is appropriate because the symptom is already tied to open canonical setup rollback and local-gateway tracking work, and changing rollback behavior needs maintainer direction.

Review details

Best possible solution:

Keep this as concrete symptom evidence under #677 and #834 until setup proves fresh local gateway install, pairing, rollback recovery, and restart persistence end to end.

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

Yes at source/log level: the attached v0.6.3 log shows pair-node failing with device signature expired and then rolling back the local gateway. I did not run a live current-main Windows/WSL setup reproduction in this read-only review.

Is this the best way to solve the issue?

Unclear for a standalone fix: current main has partial diagnostics and newer gateway pinning, but the durable solution should follow the canonical rollback and local-gateway golden-path issues rather than close this symptom as fixed.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• I did not run a live Windows/WSL setup against current main, so the exact node signature failure is not proven fixed or still failing at runtime.
• The rollback/deletion behavior overlaps an open policy decision in the canonical setup rollback issue, so a narrow automated repair could choose the wrong preserve-versus-cleanup behavior.
• The latest release in the provided context is v0.6.3, while several setup mitigations and gateway LKG updates are current-main-only after that release.

Codex review notes: model internal, reasoning high; reviewed against d08a3e749973.

Label changes

Label changes:

• add P1: The report blocks first-run local gateway onboarding and can leave the user without a working OpenClaw setup.
• add impact:data-loss: The attached log shows setup rollback deleting generated gateway identity/state and unregistering the app-owned OpenClawGateway after a late failure.
• add impact:auth-provider: The observed failure occurs in node pairing/device-signature authentication during setup.
• add impact:other: The issue also affects installer/onboarding completion, which is meaningful setup impact outside the more specific owned labels.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-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.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P1: The report blocks first-run local gateway onboarding and can leave the user without a working OpenClaw setup.
• impact:data-loss: The attached log shows setup rollback deleting generated gateway identity/state and unregistering the app-owned OpenClawGateway after a late failure.
• impact:auth-provider: The observed failure occurs in node pairing/device-signature authentication during setup.
• impact:other: The issue also affects installer/onboarding completion, which is meaningful setup impact outside the more specific owned labels.

Evidence reviewed

What I checked:

• Reporter log shows pair-node failure: The attached setup log reaches pair-node, then records repeated device signature expired node registration errors and a final pair-node failure before cleanup starts.
• Reporter log shows rollback after failure: After pair-node fails, the same log records rollback of completed setup steps, deletion of the gateway identity directory, removal of the local gateway record, and unregistering OpenClawGateway.
• Current setup contract expects local gateway onboarding to work: Current setup docs say first launch opens onboarding and the default flow installs and configures a dedicated app-owned local WSL gateway. (docs/SETUP.md:51, d08a3e749973)
• Current rollback path still exists: SetupPipeline still rolls back the failed step and completed steps when RollbackOnFailure is enabled, so the rollback/deletion portion is still relevant to the linked canonical work. (src/OpenClaw.SetupEngine/SetupPipeline.cs:171, d08a3e749973)
• Current main has partial device-pair diagnostic mitigation: AutoApproveNodePairing now detects the older gateway device-pair plugin-not-found path and returns a terminal upgrade message, but this is diagnostic/mitigation coverage rather than proof that this setup report is fully resolved. (src/OpenClaw.SetupEngine/SetupSteps.cs:2422, d08a3e749973)
• Related open issues still own the remaining setup outcome: GitHub issue search and related issue views show OpenClawGateway being deleted/rolled back after the failed setup. #677 remains open for rollback after failed setup, while 🦞 Tracking: Local gateway is the golden path for the Windows companion app #834 remains the open local-gateway golden-path epic listing this issue as a child symptom.

Likely related people:

• ranjeshj: Authored the out-of-process local gateway SetupEngine redesign and later WSL setup pairing-stability work in the central setup pipeline area. (role: setup engine feature owner; confidence: high; commits: cefce3952ab1, ff3a7cc53736; files: src/OpenClaw.SetupEngine, src/OpenClaw.SetupEngine.UI, tests/OpenClaw.SetupEngine.Tests)
• bkudiess: Recent merged PRs changed richer gateway wizard handling, remote setup recovery, and node-mode state around the onboarding and connection path. (role: recent setup and connection recovery contributor; confidence: high; commits: 84d2e6ab80c8, f51a8618ed7b, 9ac8cfb24f35; files: src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, src/OpenClaw.Connection)
• Vincent Koc: Recent commits touched pairing/startup state and device identity/signature dependencies, which are adjacent to the reported node signature failure. (role: adjacent pairing and device-identity contributor; confidence: medium; commits: 260fb90c6dc7, ae61c99bd858; files: src/OpenClaw.Shared/DeviceIdentity.cs, src/OpenClaw.Connection, src/OpenClaw.Tray.WinUI/Services/StartupSetupState.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.

[github-actions]

🤖 This is an automated response from Repo Assist.

Welcome, @JMitch0214! Thanks for filing this issue and attaching the setup log — that's really helpful for diagnosis.

I can see ClawSweeper has already started reviewing. While that review is in progress, a few things that might help the maintainers triage faster:

1. What version are you running? You can find this in the About page of the tray app.
2. What happens exactly? Does the installer fail, the tray app crash on startup, or the setup wizard not complete?
3. Any antivirus / security software? OpenClaw's installer sometimes gets blocked by AV tools — temporarily disabling it during install can help rule that out.

The setup log you attached will be the primary evidence for diagnosis. I've labelled this bug + needs triage so it gets picked up in the next triage pass.

If you can share any additional detail in the meantime, feel free to add it here!

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[JMitch0214]

v0.6.3

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for confirming you're on v0.6.3! That's helpful.

A couple more questions to narrow this down:

1. Which step fails? In the setup wizard, does it get stuck at the "Connecting as operator..." step (pair-operator), or at the "Connecting as node..." step (pair-node)?
2. What error do you see? Does the wizard show "Gateway not reachable" or "Connection refused" or a timeout?

The reason I ask: we've just identified a bug in v0.6.3 where PairOperatorStep was missing a Windows-side gateway connectivity check before attempting the WebSocket connection. WSL port forwarding can lag by a few seconds after the gateway starts, and the missing check caused the connection to fail with a timeout. A fix PR has been submitted.

If you're hitting the pair-operator step specifically, this fix should resolve it. Stay tuned!

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[github-actions]

This issue has been automatically marked as stale due to inactivity.
Please add updated OpenClaw Windows details or it will be closed.