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 13, 2026, 1:10 PM ET / 17:10 UTC.

Summary
Keep open: current main and latest release still have the stale setup-wizard session path, and open closing PRs already target this issue, with #718 as the better canonical review target.

Reproducibility: yes. at source level: a wizard.next timeout reaches EnterWizardErrorAsync, which disconnects before the existing cancel helper can send wizard.cancel. I did not run a live setup reproduction in this read-only review.

Next step
No separate ClawSweeper fix job should be queued because open linked PRs already carry the proposed repair, with #718 as the better review target.

Review details

Best possible solution:

Review and land #718 or an equivalent cancel-before-disconnect fix with real setup recovery proof, then close the duplicate #717 and track any remaining Teams timeout separately.

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

Yes at source level: a wizard.next timeout reaches EnterWizardErrorAsync, which disconnects before the existing cancel helper can send wizard.cancel. I did not run a live setup reproduction in this read-only review.

Is this the best way to solve the issue?

Likely yes: reusing the existing best-effort CancelCurrentSessionAsync() before disconnect is the narrowest maintainable fix. The remaining merge decision belongs on the linked PR, where live recovery proof and required validation still matter.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The Teams SDK channel stall itself may be separate from the stale-session recovery bug; the linked repair addresses retry/skip recovery after a timeout, not necessarily the underlying Teams setup timeout.
• This review established the stale-session bug from source and docs, but did not run a live WinUI/gateway reproduction.

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

Label changes

Label changes:

• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• remove issue-rating: 🐚 platinum hermit: Current issue advisory state no longer selects this label.
• remove clawsweeper:needs-live-repro: Current issue advisory state no longer selects this label.

Label justifications:

• P1: A setup wizard timeout can leave users unable to recover or complete gateway setup without clearing stale session state.
• impact:session-state: The issue centers on a gateway wizard session remaining active after the client-side setup flow enters timeout recovery.

Evidence reviewed

What I checked:

• Repository policy read: The full 48-line AGENTS.md was read; its onboarding and connection guidance made the setup wizard docs and connection/session cleanup code relevant review inputs. (AGENTS.md:1, ff38d8499c48)
• Current main error path still disconnects before cancel: On current main, a wizard.next exception calls EnterWizardErrorAsync, and that method calls DisconnectAsync() before showing retry/skip; CancelCurrentSessionAsync() only sends wizard.cancel while _client and _sessionId are still present. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:751, ff38d8499c48)
• Current main retry path starts fresh without cancelling old session: StartWizardAsync still begins with DisconnectAsync() and then clears _sessionId before sending a new wizard.start, so retry from error state does not cancel the old gateway session first. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:59, ff38d8499c48)
• Onboarding recovery contract: The onboarding docs say recovery choices should remain available when an auth/setup flow stalls so users are not trapped retrying a broken session. (docs/ONBOARDING_WIZARD.md:39, ff38d8499c48)
• Open linked implementation PRs: GitHub reports [Repo Assist] fix(setup): cancel wizard session before disconnect to prevent stale-session retry errors #718 as open, draft, mergeable, and closing this issue; [Repo Assist] fix(setup): cancel wizard session before disconnect to prevent stale-session errors #717 is also open but was later identified in discussion as a duplicate of the same two-line fix. (28684abbfb09)
• Release check: The latest release tag v0.6.3 still contains direct DisconnectAsync() calls in the wizard start/error paths; no tag contains current main, and the open PR fix is not merged. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs:54, 85445c78066b)

Likely related people:

• ranjeshj: Authored the out-of-process SetupEngine wizard introduction and the later restart-recovery change that shaped this code path. (role: feature owner / adjacent setup owner; confidence: high; commits: cefce3952ab1, 623427cead04; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, docs/ONBOARDING_WIZARD.md)
• bkudiess: Recently changed the same wizard UI file for gateway console output and OAuth/setup visibility, and current blame points nearby wizard session code through that work. (role: recent area contributor; confidence: medium; commits: 8f134b354df0; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, src/OpenClaw.SetupEngine/SetupWizardRunner.cs)
• Scott Hanselman: Committed the restart-recovery change and later annotated cleanup behavior in CancelCurrentSessionAsync, making him a useful routing candidate for this recovery path. (role: recent adjacent contributor / committer; confidence: medium; commits: 623427cead04, d23f8ca50013; 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