fix(setup): extend timeouts for slow wizard steps

[steipete]

Fixes #641.

Slow authentication, plugin installation, download, and Microsoft Teams setup operations now receive a five-minute RPC timeout in both WinUI and headless setup. Choice prompts only receive the longer timeout when the selected option is actually slow, so skip, Matrix, browser-labeled, and ordinary options keep the normal 30-second timeout.

Progress steps use their title, message, and step ID even when the gateway includes incidental options. This keeps WinUI and headless behavior aligned.

Credit to @ranjeshj for the original diagnosis and implementation direction in #648.

Validation

Native Windows 11 ARM64 VM, clean clone of current main plus this commit:

• ./build.ps1 — Shared, CLI, WinNode CLI, SetupEngine, and WinUI succeeded.
• dotnet test tests/OpenClaw.SetupEngine.Tests/OpenClaw.SetupEngine.Tests.csproj --no-restore --no-build — 429 passed.
• dotnet test tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore --no-build — 2,697 passed, 31 skipped.
• dotnet test tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore --no-build — 1,579 passed.
• Focused timeout regression suite — 21 passed.
• Final AutoReview — no accepted/actionable findings.

Real behavior proof

Launched run-app-local.ps1 -NoBuild -Isolated in the Windows VM and exercised the real onboarding UI through local-gateway selection, confirmation, Standard capabilities, Windows permissions, and Install & set up. The app remained responsive and reached the real fresh WSL distribution creation step.

Not verified / blocked: the Parallels guest cannot provide nested WSL2 virtualization. Gateway creation failed with HCS_E_HYPERV_NOT_INSTALLED, so a real delayed Teams plugin operation could not be exercised in this VM. The actual >30-second Teams behavior remains blocked pending a physical or nested-virtualization-capable Windows host with a disposable Teams fixture; no live-pass claim is made here.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 6, 2026, 12:09 PM ET / 16:09 UTC.

Summary
The PR extends setup wizard RPC timeouts for auth, plugin/install/download, and Teams-related slow steps in both WinUI and headless setup while preserving the default timeout for ordinary selected choices.

Reproducibility: yes. at source level, but not live: current main only classifies auth text for extended timeouts while the PR-linked bug needs Teams/plugin selected-option context. I did not run a real Teams setup reproduction in this read-only review.

Review metrics: 2 noteworthy metrics.

• Changed surface: 5 files, +193/-15. The diff is focused on timeout classification, two callers, and regression tests rather than a broad setup rewrite.
• Regression coverage: 2 test files changed, 95 test-line additions. The added tests cover the slow-option classification and UI progress polling contract that matter for the linked timeout bug.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #641
Summary: This PR is the current focused candidate fix for the open Teams setup timeout issue; the earlier timeout PR is closed unmerged, and the merged stale-session recovery PR only addressed a downstream retry symptom.

Members:

• canonical: Config Wizard: configuring the Teams channel times out #641 - The PR body uses closing syntax for this open issue, whose report describes Teams channel setup timing out during plugin download/install/configuration.
• superseded: Extend setup wizard timeout for Teams channel setup #648 - This closed unmerged PR proposed the same timeout-classification direction and is credited by the current PR as original diagnosis and implementation direction.
• partial_overlap: Teams SDK Channel selection can't continue #709 - This closed issue covered stale wizard-session retry behavior after a Teams timeout, not the underlying slow Teams/plugin timeout budget.
• partial_overlap: [Repo Assist] fix(setup): cancel wizard session before disconnect to prevent stale-session retry errors #718 - This merged PR fixed cancel-before-disconnect recovery for stale wizard sessions, complementary to but not replacing the timeout extension in this PR.

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

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted live output, logs, or a short recording from a host that can exercise the Teams/plugin setup path past 30 seconds.
• Update the PR body with that proof; if a fresh review does not run automatically, ask a maintainer to comment @clawsweeper re-review.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR body reports a real onboarding run to WSL distro creation and a concrete host blocker, but it does not directly show the delayed Teams/plugin timeout path after the fix. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P2] The PR body does not include direct proof that a delayed Teams/plugin setup operation now survives beyond the old short timeout; accepting the documented VM blocker would require an explicit maintainer proof decision.

Maintainer options:

1. Decide the mitigation before merge
   Land this focused timeout fix after normal checks and either live slow Teams/plugin proof or an explicit maintainer proof override confirms the source/test evidence is enough.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P1] No ClawSweeper repair job is appropriate; the remaining blocker is proof sufficiency and normal maintainer review, not a discrete code change.

Maintainer decision needed

• Question: Should this external PR wait for live slow Teams/plugin setup proof, or can the documented nested-virtualization blocker be accepted as a proof override?
• Rationale: The repository and ClawSweeper proof gates require current-head proof of the changed setup behavior, but the PR only proves adjacent onboarding flow and documents why the central delayed Teams/plugin path could not be run in the VM.
• Likely owner: ranjeshj — The PR credits ranjeshj for the original diagnosis and implementation direction, and prior related setup wizard work makes him the best available proof-sufficiency routing candidate.
• Options:
  • Require slow-path proof (recommended): Ask for redacted live output, logs, or a short recording from a host that can exercise Teams/plugin setup beyond 30 seconds before merge.
  • Override with source/test evidence: A maintainer can explicitly accept the VM blocker and merge after CI if the source diff and focused tests are sufficient for this fix.

Security
Cleared: The diff only changes C# timeout classification and tests; I found no dependency, workflow, credential, permission, or code-execution source change.

Review details

Best possible solution:

Land this focused timeout fix after normal checks and either live slow Teams/plugin proof or an explicit maintainer proof override confirms the source/test evidence is enough.

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

Yes at source level, but not live: current main only classifies auth text for extended timeouts while the PR-linked bug needs Teams/plugin selected-option context. I did not run a real Teams setup reproduction in this read-only review.

Is this the best way to solve the issue?

Yes, with a proof caveat: sharing option-aware timeout classification across WinUI and headless setup is the narrowest maintainable repair I found. Merge readiness still depends on live slow-path proof or a maintainer proof override.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P2: This is a normal-priority setup wizard bug fix for a real Teams/channel configuration timeout with limited blast radius.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body reports a real onboarding run to WSL distro creation and a concrete host blocker, but it does not directly show the delayed Teams/plugin timeout path after the fix. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P2: This is a normal-priority setup wizard bug fix for a real Teams/channel configuration timeout with limited blast radius.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body reports a real onboarding run to WSL distro creation and a concrete host blocker, but it does not directly show the delayed Teams/plugin timeout path after the fix. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy applied: AGENTS.md was read fully; its onboarding/setup validation and proof guidance applies because the PR changes the setup wizard path. (AGENTS.md:1, 38fd2cf15e71)
• Current main timeout classifier is auth-only: Current main's WizardTimeouts only has auth hints and returns the default timeout for non-auth text, so generic Teams/channel/plugin choices can stay on the short path. (src/OpenClaw.SetupEngine/WizardTimeouts.cs:21, 38fd2cf15e71)
• PR adds slow setup classification: The PR head adds slow setup hints for plugin/install/download/teams and an option-aware ForGatewayStep helper that passes selected option metadata into timeout classification. (src/OpenClaw.SetupEngine/WizardTimeouts.cs:27, 6cb7bd285a97)
• UI caller passes selected option context: WizardPage now gathers selected options for select/multiselect steps and passes them with title, message, and step id to the shared timeout classifier. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:789, 6cb7bd285a97)
• Headless setup caller passes answer context: SetupWizardRunner now forwards the resolved answer to WizardTimeouts.ForGatewayStep so headless setup can classify selected Teams/plugin options the same way as the UI. (src/OpenClaw.SetupEngine/SetupWizardRunner.cs:481, 6cb7bd285a97)
• Focused regression tests added: The PR adds tests for slow setup text, selected Teams/plugin option metadata, ordinary options staying short, and progress steps using step metadata despite incidental options. (tests/OpenClaw.SetupEngine.Tests/WizardTimeoutsTests.cs:26, 6cb7bd285a97)

Likely related people:

• steipete: Authored the current-main native Windows gateway onboarding wizard commit that introduced recent WizardPage setup flow changes and is also carrying this replacement timeout PR. (role: recent setup wizard feature contributor; confidence: high; commits: adcb4c378f90, 6cb7bd285a97; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, docs/ONBOARDING_WIZARD.md)
• ranjeshj: Authored the closed unmerged timeout PR and prior setup-engine/wizard recovery work that matches the linked issue's diagnosis and repair shape. (role: original setup timeout implementation-direction owner; confidence: high; commits: 4525867153ae, cefce3952ab1, 9d304c110c0f; files: src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, tests/OpenClaw.SetupEngine.Tests/WizardTimeoutsTests.cs)
• shanselman: Current blame on the existing timeout classifier and callers points to a recent setup/test commit, and prior adjacent setup recovery work makes this a plausible routing signal. (role: current-line provenance and adjacent setup contributor; confidence: medium; commits: 4166e0fd63f8, 3ddade7072b0; files: src/OpenClaw.SetupEngine/WizardTimeouts.cs, src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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.