Config Wizard: configuring the Teams channel times out

[Stevenic]

To setup the Teams channel, OpenClaw needs to first download and install the plugin and then run you through a configuration process. Selecting the Teams Channel timed out for me (I think it said it had a 60 second timeout.) The bigger issue is that I then had to skip the wizard so I lost all of my other settings.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 2, 2026, 3:55 AM ET / 07:55 UTC.

Summary
Keep open: current main and v0.6.12 still use auth-only timeout classification for wizard.next, so Teams/channel/plugin selection can remain on the short timeout path; the exact timeout PR was closed unmerged, while later progress polling and stale-session recovery work only partially overlaps.

Reproducibility: no. live high-confidence reproduction was run. Source inspection shows generic Teams/channel selections still use the short timeout and the gateway client throws on timeout, which matches the reported failure shape.

Root-cause cluster
Relationship: canonical
Canonical: #641
Summary: This issue is the concrete remaining Teams/channel timeout report; related items either attempted a closed-unmerged fix, fixed a downstream stale-session symptom, or track broader onboarding validation.

Members:

• fixed_by_candidate: Extend setup wizard timeout for Teams channel setup #648 - Closed unmerged PR proposed the direct shared timeout-classifier fix for this issue.
• partial_overlap: Teams SDK Channel selection can't continue #709 - Closed issue covered the stale wizard session and retry failure after a Teams timeout, not the underlying slow Teams/channel selection timeout.
• partial_overlap: 🦞 Tracking: Onboard the channels & providers I use #836 - Open epic lists this issue as a child of broader channel/provider onboarding reliability work.
• adjacent_distinct: Automation validation for wizard combinations #847 - Open validation issue asks for channel/provider matrix coverage and references this bug, but it is not the same concrete timeout fix.

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

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A focused replacement PR can reuse the closed timeout-fix shape: update shared wizard timeout classification and both callers, then prove the Teams/channel path.

Review details

Best possible solution:

Land a narrow shared setup-wizard timeout fix that gives slow channel/plugin/install/download/Teams selections the extended budget in both wizard callers, preserves existing retry cancellation behavior, and adds focused regression tests plus live Teams-path proof or a documented gateway blocker.

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

No live high-confidence reproduction was run. Source inspection shows generic Teams/channel selections still use the short timeout and the gateway client throws on timeout, which matches the reported failure shape.

Is this the best way to solve the issue?

Yes directionally: the narrowest maintainable fix is to extend the shared timeout classifier with selected answer/option context and tests, while preserving the existing cancel-before-disconnect recovery path.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live Teams setup run was performed in this read-only review, so the remaining evidence is source-level plus related PR history.
• The Teams plugin/gateway implementation may still impose its own timeout outside this checkout; a Windows-node fix should include live proof or document that blocker.
• The stale-session retry problem after a timeout was fixed by [Repo Assist] fix(setup): cancel wizard session before disconnect to prevent stale-session retry errors #718, but that does not prove the original Teams/channel timeout or settings-loss path is resolved.

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

Label changes

Label changes:

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

Label justifications:

• P2: This is a normal-priority setup wizard bug with real first-run channel configuration impact but limited blast radius.
• impact:data-loss: The reporter says skipping after the timeout lost previously entered wizard settings.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.SetupEngine.Tests/OpenClaw.SetupEngine.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• Redacted live setup wizard proof through the Teams/channel selection path, or an explicit gateway/plugin blocker if the local host cannot exercise Teams

What I checked:

• Repository policy read: AGENTS.md was read fully; its setup/onboarding validation and proof guidance shaped the review and recommended work validation, while this cleanup pass stayed read-only. (AGENTS.md:1, f89a88a6baf4)
• Issue report: The issue body says Teams channel setup timed out during plugin download/install/configuration, then skipping the wizard caused prior settings to be lost.
• Current timeout classifier is auth-only: WizardTimeouts.ForStep only checks auth-related hints and otherwise returns the 30 second default; it does not include channel, plugin, install, download, or Teams terms. (src/OpenClaw.SetupEngine/WizardTimeouts.cs:21, f89a88a6baf4)
• WinUI wizard uses that short path for submitted answers: WizardPage sends wizard.next with TimeoutForCurrentStep(), and that helper only passes the current title/message to WizardTimeouts.ForStep, not the selected Teams option text. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:566, f89a88a6baf4)
• Headless setup runner has the same timeout boundary: SetupWizardRunner sends answer-bearing wizard.next calls through TimeoutFor(parsed), which also only uses the parsed title/message. (src/OpenClaw.SetupEngine/SetupWizardRunner.cs:222, f89a88a6baf4)
• Timeouts surface as wizard failures: OpenClawGatewayClient.SendWizardRequestAsync removes the pending response and throws TimeoutException when the supplied timeout budget elapses. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:629, f89a88a6baf4)

Likely related people:

• bkudiess: Authored the merged richer gateway wizard protocol PR that changed WizardPage, SetupWizardRunner, WizardTimeouts, and related tests adjacent to the remaining timeout path. (role: recent setup wizard contributor; confidence: high; commits: 8b12acddf4ca, 97a87d7413e3; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.SetupEngine/WizardTimeouts.cs)
• shanselman: Authored the merged progress polling budget commit and later setup triage quick-win tests around provider/channel wizard answers. (role: recent adjacent setup hardening contributor; confidence: medium; commits: 97a87d7413e3, bf69a8b63331; files: src/OpenClaw.SetupEngine/WizardTimeouts.cs, tests/OpenClaw.SetupEngine.Tests/WizardTimeoutsTests.cs, tests/OpenClaw.SetupEngine.Tests/WizardDefaultAnswerMatrixTests.cs)
• ranjeshj: Authored the closed unmerged PR that directly implemented the selected-option timeout approach for this issue, making him useful routing context for a replacement fix. (role: proposed fix author / setup wizard contributor; confidence: high; commits: ed0e52183c16; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, src/OpenClaw.SetupEngine/SetupWizardRunner.cs, src/OpenClaw.SetupEngine/WizardSelection.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.

The timeout issue reported here appears to have a fix in progress: PR #648 by @ranjeshj — Extend setup wizard timeout for Teams channel setup.

Looking at the code, TimeoutForCurrentStep() in WizardPage.xaml.cs currently only extends the timeout to 5 minutes for steps containing auth keywords (device, authorize, login, sign in, oauth). All other steps — including plugin installation/download — get a 30-second window. PR #648 extends the extended-timeout path to cover channel/plugin/install/progress steps and also includes the submitted answer text in the classification heuristic, so Teams channel selection steps get the longer window even when the step title is generic.

If you're able to repro this, testing against that PR branch would help validate the fix.

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.