Teams SDK Channel selection can't continue

[FireBelow]

During Openclaw companion app setup, after fresh gateway install, I selected the MS Teams channel option but the "continue" button became greyed out but didn't go to a new page.

Then the wizard timed out and if I "skip wizard" or try to continue it says there is a wizard already running.

When I clicked next, it appears my timed out settings were not applied and I'll need to run the wizard again

[clawsweeper]

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

Summary
Keep open: current main still has a plausible setup-wizard recovery bug where a wizard.next timeout can leave the gateway session active and make retry/skip hit the reported “wizard already running” state.

Reproducibility: yes. source-reproducible but not live-reproduced here: a wizard.next timeout throws, the UI disconnects before canceling the active session, and later recovery actions have no client left to send wizard.cancel. The report supplies the concrete Teams channel path and screenshot.

Next step
A focused repair is plausible from source inspection, but merge confidence should include a real setup or mocked gateway proof that timeout recovery clears the wizard session.

Review details

Best possible solution:

Fix the setup UI so timeout/error recovery reliably sends or preserves a wizard.cancel for the active session before disconnecting, then prove the Teams SDK channel flow can retry or skip without a stuck gateway session.

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

Yes, source-reproducible but not live-reproduced here: a wizard.next timeout throws, the UI disconnects before canceling the active session, and later recovery actions have no client left to send wizard.cancel. The report supplies the concrete Teams channel path and screenshot.

Is this the best way to solve the issue?

Yes, the narrowest maintainable fix is in the Windows setup wizard recovery path: preserve or reacquire enough connection state to cancel the active session before retry/skip. If Teams SDK still hangs after that, gateway-side logs should drive a separate gateway/plugin fix.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• I did not run a live Windows/MS Teams gateway reproduction in this read-only review, so the Teams SDK-specific wizard.next stall may still need gateway-side logs after the Windows stale-session recovery is fixed.

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

Label changes

Label changes:

• add P1: Fresh onboarding can become blocked in a real channel setup flow, leaving users unable to retry or skip the gateway wizard cleanly.
• add impact:session-state: The reported failure and source path center on stale gateway wizard session state that survives a timeout and blocks subsequent setup actions.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.

Label justifications:

• P1: Fresh onboarding can become blocked in a real channel setup flow, leaving users unable to retry or skip the gateway wizard cleanly.
• impact:session-state: The reported failure and source path center on stale gateway wizard session state that survives a timeout and blocks subsequent setup actions.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.SetupEngine.Tests/OpenClaw.SetupEngine.Tests.csproj --no-restore

What I checked:

• Issue report: The issue body describes a fresh gateway setup, MS Teams channel selection, a greyed Continue button, timeout, and later retry/skip failures saying a wizard is already running, with a screenshot attached in the report.
• Current submit path waits for wizard.next and enters error state on timeout: The UI disables buttons with SetBusy, sends wizard.next, and on exception calls EnterWizardErrorAsync; this matches the reported greyed Continue followed by timeout/error behavior. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:456, 4be005707f44)
• Error recovery disconnects before later cancel can run: EnterWizardErrorAsync disconnects the client, while CancelCurrentSessionAsync only sends wizard.cancel when _client is still non-null; after an error, Start/Skip cannot cancel the server-side session they need to clear. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:754, 4be005707f44)
• Wizard RPC timeout path is explicit: SendWizardRequestAsync throws TimeoutException when the gateway does not answer before the current step timeout, which is the exception path that feeds the UI error state. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:511, 4be005707f44)
• Onboarding docs define recovery as expected behavior: The onboarding docs say recovery choices remain visible while setup runs so users can start again or skip if an auth flow stalls, which supports treating the stuck session as broken existing behavior. (docs/ONBOARDING_WIZARD.md:39, 4be005707f44)
• History provenance for the current wizard recovery code: Blame ties the error, skip, and cancel-session code to commit 85445c7; later nearby commits touched the page but did not remove the disconnect-before-cancel behavior. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:754, 85445c78066b)

Likely related people:

• christineyan4: Blame points the current wizard start/error/cancel-session code and shared wizard timeout helper to commit 85445c7. (role: introduced behavior; confidence: high; commits: 85445c78066b; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, src/OpenClaw.Shared/OpenClawGatewayClient.cs)
• Barbara Kudiess: Recent wizard work in commit 8f134b3 updated the same page for console output and OAuth-related wizard behavior. (role: recent area contributor; confidence: medium; commits: 8f134b354df0; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs)
• ranjeshj: Commit afa6218 recently touched setup wizard navigation in the same UI page during setup-host consolidation. (role: recent adjacent contributor; confidence: medium; commits: afa6218338d6; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.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.

[github-actions]

🤖 This is an automated response from Repo Assist.

I've investigated this and confirmed the root cause from source.

Root cause: When wizard.next times out (the Teams SDK channel step hung), EnterWizardErrorAsync calls DisconnectAsync() which sets _client = null, then shows the "Start wizard again" / "Skip wizard" buttons. But CancelCurrentSessionAsync checks _client != null before sending wizard.cancel — so the server-side wizard session is never cancelled. The next wizard.start from "Start wizard again" hits the still-live session and gets a gateway error.

Fix: Replace await DisconnectAsync() with await CancelCurrentSessionAsync() in EnterWizardErrorAsync and StartWizardAsync. Since CancelCurrentSessionAsync sends a best-effort wizard.cancel and then calls DisconnectAsync(), the session is cleaned up before the disconnect. The change is a no-op on first-start (no session to cancel) and on already-disconnected paths.

I've opened a draft PR on branch repo-assist/fix-issue-709-wizard-stale-session with this change. Note the Teams SDK channel step hanging is a separate gateway-side issue — this fix specifically addresses the "wizard already running" stuck state that prevents recovery.

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