Include cloud provider setup in the onboarding experience

[RomneyDa]

e.g. chatgpt oauth can be baked into the onboarding

[clawsweeper]

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

Summary
Current main and v2026.7.1 already provide gateway-driven provider, model, and key onboarding, including an OpenAI OAuth URL path. This member-authored issue stays open for explicit maintainer confirmation that the existing flow meets the intended ChatGPT OAuth experience.

Reproducibility: not applicable. this is a feature request, and current docs, source, and regression coverage already show provider setup plus an OpenAI OAuth URL path in onboarding.

Ways to help us reproduce this

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

Maintainer decision needed

Question	Recommendation
Does the existing gateway-driven provider setup and OpenAI OAuth browser path satisfy the intended ChatGPT OAuth onboarding experience, or is a distinct provider-specific UX required?	Confirm existing flow satisfies the request: Close as already available in v2026.7.1 and current main, with the gateway wizard remaining the auth-flow owner.

Why: Current source and released documentation cover the stated behavior, but the issue is member-authored and its one-line request does not establish whether a different UX is intended.

Next step
Explicit maintainer confirmation is required before closing a member-authored request whose stated behavior is already present.

Review details

Best possible solution:

Retain the gateway-owned provider/auth wizard; if maintainer review identifies a concrete missing ChatGPT OAuth step, track that narrow gateway-contract or tray-rendering gap rather than adding a parallel onboarding flow.

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

Not applicable: this is a feature request, and current docs, source, and regression coverage already show provider setup plus an OpenAI OAuth URL path in onboarding.

Is this the best way to solve the issue?

Yes, the existing gateway-owned wizard is the narrowest maintainable solution; maintainer confirmation is needed only to determine whether the request means a different UX.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The request does not specify a gap beyond the shipped OpenAI OAuth browser path, so a new provider-specific flow could duplicate the gateway-owned wizard.

Codex review notes: model internal, reasoning high; reviewed against 3880b62dd517; fix evidence: release v2026.7.1, commit 4206611f2b2e.

Label changes

Label changes:

• add P3: The requested onboarding capability appears to be present in the released flow; the remaining work is low-urgency product confirmation.
• add issue-rating: 🌊 off-meta tidepool: 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:

• P3: The requested onboarding capability appears to be present in the released flow; the remaining work is low-urgency product confirmation.

Evidence reviewed

What I checked:

• Current onboarding contract: The onboarding documentation says gateway RPC supplies select steps for AI-provider choice and password-style input for API keys, with recovery when an auth flow stalls. (docs/ONBOARDING_WIZARD.md:39, 4206611f2b2e)
• OAuth path is surfaced in the tray: The console-tail implementation explicitly handles OAuth URLs emitted by upstream wizard plugins, and the UI attaches it when the gateway wizard starts. (src/OpenClaw.SetupEngine.UI/WizardConsoleTail.cs:11, 4206611f2b2e)
• OpenAI OAuth regression coverage: A tray test verifies extraction of the auth.openai.com authorization URL for the OpenAI Codex browser path. (tests/OpenClaw.Tray.Tests/WizardConsoleTailTests.cs:14, 4206611f2b2e)
• Release and current-main provenance: The relevant onboarding files are unchanged between v2026.7.1's commit and current main; the release tag points at that commit and main contains it. (docs/SETUP.md:67, 4206611f2b2e)

Likely related people:

• Scott Hanselman: The provider/onboarding documentation, OAuth console-tail implementation, and associated regression test all trace to the released baseline commit. (role: current implementation provenance; confidence: high; commits: 4206611f2b2e; files: docs/ONBOARDING_WIZARD.md, src/OpenClaw.SetupEngine.UI/WizardConsoleTail.cs, tests/OpenClaw.Tray.Tests/WizardConsoleTailTests.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.