Copilot Github auth doesn't complete

[FireBelow]

On a new WSL Ubuntu 24 install, I ran through the quickstart install config and selected CoPilot -> Github auth for my model. I got a device registration code and URL but after completing that step nothing happens. It seems like the return signal to the installer never happens after the auth.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 2, 2026, 7:55 PM ET / 23:55 UTC.

Summary
Keep open: current main still routes Copilot/GitHub setup through the generic gateway wizard path, and I found no source, release, or canonical duplicate evidence that this device-code completion problem is already fixed.

Reproducibility: no. there is not yet a high-confidence current-main reproduction from this review. The reporter supplied clear steps and a screenshot, but I did not run the Windows/WSL setup flow and the source only identifies the generic wizard wait path.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
Needs maintainer or reporter log review before automation because the fault may be in the upstream gateway Copilot auth flow rather than this repository’s wizard wrapper.

Review details

Best possible solution:

Capture setup JSONL around the Copilot auth step, then either fix the Windows wizard wait/recovery behavior or update the bundled gateway once the provider-auth completion bug is fixed upstream.

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

No, there is not yet a high-confidence current-main reproduction from this review. The reporter supplied clear steps and a screenshot, but I did not run the Windows/WSL setup flow and the source only identifies the generic wizard wait path.

Is this the best way to solve the issue?

Unclear because there is no proposed patch and the failure boundary is not proven. The narrow maintainable path is to determine from setup logs whether wizard.next times out in the Windows wrapper or whether the gateway Copilot auth step never resolves after browser authorization.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The Copilot/GitHub device-code logic appears to live in the bundled gateway, while this repo owns the wrapper that waits for wizard RPC completion; logs are needed to identify the correct owner.
• There are separate headless and WinUI wizard paths, so a Windows-side fix may need both paths covered to avoid leaving one setup route broken.

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

Label changes

Label changes:

• add P2: This is a normal-priority onboarding/auth-provider bug with limited known blast radius to Copilot GitHub model setup.
• add impact:auth-provider: The reported failure blocks GitHub Copilot authentication and model provider selection during setup.
• add issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.
• add clawsweeper:needs-info: 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:

• P2: This is a normal-priority onboarding/auth-provider bug with limited known blast radius to Copilot GitHub model setup.
• impact:auth-provider: The reported failure blocks GitHub Copilot authentication and model provider selection during setup.

Evidence reviewed

What I checked:

• Issue report and screenshot: The reporter describes a fresh WSL Ubuntu 24 quickstart setup, selecting Copilot/GitHub auth, receiving a device registration code and URL, then seeing no completion after authorization; the attached screenshot shows a device-code prompt with a 15-minute expiry.
• Documented setup surface: The user-facing setup guide says the Wizard screen handles gateway-driven AI provider selection through gateway-defined steps, matching the reported Copilot model-auth flow. (docs/SETUP.md:60, bfeb3b5c90be)
• Gateway-owned wizard flow: Onboarding docs state that the gateway controls setup steps over wizard.start / wizard.next, so the provider auth completion may be owned by the bundled gateway rather than only this Windows wrapper. (docs/ONBOARDING_WIZARD.md:30, bfeb3b5c90be)
• Headless wizard wait path: SetupWizardRunner submits answers with wizard.next and waits for the next payload using a text-based timeout heuristic; that is the likely Windows-node touchpoint if the installer is waiting forever or timing out silently. (src/OpenClaw.SetupEngine/SetupWizardRunner.cs:161, bfeb3b5c90be)
• UI wizard wait path: The WinUI wizard uses the same wizard.next request pattern and long-running-step timeout keywords, so a repair may need both UI and headless setup paths if the Windows wrapper is at fault. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:430, bfeb3b5c90be)
• RPC timeout behavior: OpenClawGatewayClient.SendWizardRequestAsync removes the pending request and throws when no wizard.next response arrives before the selected timeout. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:489, bfeb3b5c90be)

Likely related people:

• Régis Brid: Blame and git log -S show the current SetupWizardRunner, UI wizard timeout logic, default wizard answers, and gateway LKG constant coming from commit 7d9152f. (role: introduced current setup wizard path; confidence: medium; commits: 7d9152f427a3; files: src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, src/OpenClaw.SetupEngine/default-config.json)
• Ranjesh: Recent commits touched onboarding and setup-managed WSL gateway behavior around the same local setup surface. (role: recent adjacent setup contributor; confidence: low; commits: f4d4793f744f, e0ce52d2f16c; files: docs/ONBOARDING_WIZARD.md, docs/WSL_GATEWAY_ADMIN.md, src/OpenClaw.Tray.WinUI/Pages/ConnectionPage.xaml.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.

[FireBelow]

After the openclaw install and setup wizard, I tried this command "openclaw models auth login-github-copilot" and had the same issue of not being able to proceed after auth in my browser. CTRL + clicking the URL successfully opened the auth web site but pasting the code didn't allow the auth in openclaw to continue