Config Wizard: browser links for auth written to hidden terminal window

[Stevenic]

The WSL Claw install flow worked great. I got to the Configuration Wizard and ran into a few issues.

The first is that I tried to configure Codex as my preferred model and that needs a browser login. The issue is that the browser link gets written to a hidden terminal window that openclaw config is being run in. It's impossible to know what link you're supposed to open and since there's no back button you can't change your mind about what model you want to use. You end up having to plug in a bogus value for the auth response to get the start over button.

I get that you're driving a terminal session so you can't really backup. But you should probably surface a "Start Over" button on the wizard as a safety valve.

If you do end up extracting the browser link from the text you should also make sure you look for any codes that are required to plugin. In some flows you have to open a browser and then typing in a code they showed you.

[clawsweeper]

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

Summary
Keep open: current master only added recovery actions, while the underlying hidden auth URL/device-code surfacing gap remains confirmed by source inspection and the post-merge maintainer comment.

Reproducibility: no. high-confidence live reproduction was run. Source inspection and the post-merge maintainer comment make the remaining gap source-reproducible: the UI only renders auth URLs/codes already present in wizard step messages.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Maintainers should choose the protocol/UI boundary for forwarding auth URLs and device codes before a repair PR is queued.

Review details

Best possible solution:

Define and consume structured wizard auth metadata for browser URLs and device codes, render it as open/copy UI in the Configuration Wizard, and keep the existing Start over/Skip wizard recovery path.

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

No high-confidence live reproduction was run. Source inspection and the post-merge maintainer comment make the remaining gap source-reproducible: the UI only renders auth URLs/codes already present in wizard step messages.

Is this the best way to solve the issue?

No, the merged recovery-action PR is not the full solution. A maintainable fix should avoid scraping hidden terminal text if maintainers can instead standardize auth URL/device-code metadata in the gateway wizard protocol.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The durable fix likely needs a gateway wizard protocol or agreed output-forwarding design; the Windows UI alone can only render auth data it receives.
• Auth URLs and device codes may contain sensitive values, so any forwarding/logging design needs redaction and UI-only handling decisions.

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

Label changes

Label changes:

• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority onboarding/auth-provider usability gap with a partial recovery workaround but no durable auth-link surfacing yet.
• impact:auth-provider: The issue is specifically about provider authentication URLs/device codes being hidden during model setup.

Evidence reviewed

What I checked:

• Maintainer context after partial fix: The issue was reopened after the merged recovery-actions PR, with a collaborator stating that Start over/Skip wizard are now present but auth URLs/device codes from hidden gateway/WSL output are still not surfaced in the WinUI wizard.
• UI renders only payload message content: WizardPage reads title/message from the step JSON and calls RenderMessage(message); current rendering can hyperlink URLs and copy codes only when they are already included in that message. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:179, 9d304c110c0f)
• No structured auth side channel in wizard RPC client: SendWizardRequestAsync sends a request and returns the matched JSON payload; it does not expose terminal stdout/stderr or auth-specific metadata outside the wizard response. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:489, 9d304c110c0f)
• Recovery actions are present but separate: Current master has Start over and Skip wizard buttons and cancellation flow, which addresses the trapped-user part but not auth-link visibility. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:693, 9d304c110c0f)
• Partial fix provenance: Merge commit 9d304c1 changed only the WinUI wizard page and onboarding doc for recovery actions; no gateway protocol or auth-metadata surface was added. (9d304c110c0f)
• History for current wizard implementation: Blame shows the message/link rendering and wizard RPC plumbing mostly date to 7d9152f, with recovery-action edits added in 9d304c1. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:560, 7d9152f427a3)

Likely related people:

• ranjeshj: Auth-wait recovery actions were added in the merged PR that partially addressed this issue, and the same collaborator comment clarified the remaining protocol/UI gap. (role: recent adjacent contributor; confidence: high; commits: 9d304c110c0f; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, docs/ONBOARDING_WIZARD.md)
• Regis Brid: Blame and file history show the current WinUI wizard message rendering, code/link detection, SetupWizardRunner, and SendWizardRequestAsync plumbing trace to commit 7d9152f. (role: current wizard implementation introducer; confidence: high; commits: 7d9152f427a3; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.Shared/OpenClawGatewayClient.cs)
• Mike Harsh: File history around onboarding and gateway client work includes the original WSL local gateway onboarding and post-wizard handoff changes, making this a plausible routing backup for setup-flow decisions. (role: adjacent onboarding owner; confidence: medium; commits: 581f78d276e1, fd8ff7dad9d4; files: src/OpenClaw.Shared/OpenClawGatewayClient.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.

[ranjeshj]

PR #651 partially addressed this by adding persistent Start over and Skip wizard recovery actions to the Configuration Wizard, so users are no longer trapped during provider auth waits. The issue should remain open because the underlying auth-link visibility problem is not resolved: auth URLs/device codes emitted only from hidden gateway/WSL terminal output are still not surfaced in the WinUI wizard. A durable fix likely needs structured auth URL/device-code metadata from the gateway wizard protocol, or another agreed mechanism for forwarding auth-relevant command output to the UI.