Consolidate setup UI into tray host

[ranjeshj]

Summary

This PR folds the setup experience into the main OpenClaw.Tray.WinUI app so we no longer package and deploy a second setup executable alongside the tray app.

The setup engine and setup UI projects remain separate to preserve clean separation of concerns, but the setup UI is now hosted by the tray process. This keeps the previous setup flow and handoff behavior intact while reducing packaging complexity, avoiding dual-app deployment/runtime issues, and lowering installer size.

What changed

• Host setup UI from OpenClaw.Tray.WinUI instead of launching OpenClaw.SetupEngine.UI.exe.
• Keep OpenClaw.SetupEngine and OpenClaw.SetupEngine.UI as separate projects/layers for maintainability.
• Update setup completion/restart handoff so the tray app gracefully handles post-setup launch behavior.
• Update installer/publish scripts to exclude the standalone setup executable from the shipped payload.
• Add/update tests to assert the new packaging and hosting expectations.
• Update release/setup docs to describe the consolidated app model.

Why

Previously, setup shipped as a separate app. That created duplicated deployment concerns: both apps needed compatible packaging/runtime behavior, signing expectations, payload validation, and setup handoff handling.

By hosting setup inside the tray app, we reduce installer size and remove the second app deployment surface while preserving the existing setup UX.

Validation

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — 2045 passed, 29 skipped
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — 940 passed
• Built the local x64 Inno installer with ./scripts/build-inno-local.ps1 -Arch x64 -Fast
• Tested local installer launch/install flow
• Cleaned up the installed app/tray data and tested from a fresh-install state
• Tested uninstall cleanup path locally
• Structured branch review: clean after removing a duplicate disconnect call in the setup wizard cancellation path

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 5, 2026, 1:26 PM ET / 17:26 UTC.

Summary
The PR hosts the setup wizard from OpenClaw.Tray.WinUI, removes standalone setup executable publishing/signing/installer entrypoints, updates setup restart/uninstall handoff, and adds matching docs/tests.

Reproducibility: not applicable. this is a packaging/topology PR rather than a bug report. The relevant behavior is release/installer flow validation, which the PR body reports for build, tests, local x64 installer, fresh install, and uninstall.

Review metrics: 2 noteworthy metrics.

• PR surface: 33 files changed, +591/-412. The change spans tray startup, setup UI, installer, CI signing, docs, and tests, so maintainer review should treat it as release topology work.
• Release executable topology: 2 standalone setup executables removed from payload/signing expectations. Removing those entrypoints is the main compatibility decision green tests cannot settle.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

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

Rank-up moves:

• Verify release-style ARM64 artifacts in addition to the reported x64 installer smoke.
• Record explicit maintainer acceptance of removing standalone setup executable entrypoints.

Risk before merge

• [P1] Existing users or automation that directly invokes SetupEngine\OpenClaw.SetupEngine.UI.exe or SetupEngine\OpenClaw.SetupEngine.exe would lose those entrypoints after upgrade if maintainers accept the new topology.
• [P1] Release publishing and signing now depend on the tray payload carrying setup UI resources, default-config.json, protocol shortcut behavior, restart handoff, and uninstall behavior across x64 and ARM64 artifacts.
• [P1] The PR body reports x64 local installer proof, but maintainer release acceptance should still cover ARM64 artifact/signing behavior before merge.

Maintainer options:

1. Gate on release-artifact proof (recommended)
   Before merge, verify release-style x64 and ARM64 artifacts for setup resources, protocol shortcut launch, post-setup restart, signing policy, and uninstall cleanup.
2. Accept the single-executable topology
   Maintainers can intentionally accept that standalone setup executable entrypoints are removed and make that an explicit release/upgrade decision.
3. Preserve a compatibility entrypoint
   If direct setup executable callers must remain supported, pause this PR or add a narrow compatibility shim before removing the old payload.

Next step before merge

• [P2] Manual review is appropriate because the remaining decision is release topology and compatibility acceptance, not a narrow automated repair.

Security
Cleared: No concrete security or supply-chain issue was found in the diff; the remaining concern is release/signing topology risk rather than a security defect.

Review details

Best possible solution:

Land only after maintainers explicitly accept the single-executable setup topology and verify release-style x64/ARM64 installer, upgrade, protocol shortcut, restart, and uninstall behavior; otherwise preserve a supported compatibility entrypoint.

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

Not applicable; this is a packaging/topology PR rather than a bug report. The relevant behavior is release/installer flow validation, which the PR body reports for build, tests, local x64 installer, fresh install, and uninstall.

Is this the best way to solve the issue?

Unclear until maintainer acceptance: hosting setup in the tray is a coherent way to remove dual-app deployment, but the best permanent answer depends on whether maintainers accept dropping standalone setup executable entrypoints.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 99efc50cbc22.

Label changes

Label justifications:

• P2: This is a normal-priority packaging/topology improvement with meaningful but bounded release and upgrade blast radius.
• merge-risk: 🚨 compatibility: Merging removes standalone setup executable entrypoints that existing shortcuts, scripts, or support workflows may invoke.
• merge-risk: 🚨 automation: Merging changes CI publish/signing expectations and release artifact validation for both x64 and ARM64 payloads.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes after-change validation with build/test results plus local installer, fresh-install, and uninstall cleanup smokes; no contributor action is needed for the proof gate.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-change validation with build/test results plus local installer, fresh-install, and uninstall cleanup smokes; no contributor action is needed for the proof gate.

Evidence reviewed

What I checked:

• Repository policy read: Read the full target AGENTS.md; its validation and setup/tray architecture guidance was applied as review context, but no validation was run because this was a read-only review. (AGENTS.md:1, 99efc50cbc22)
• Current main still uses standalone setup UI: Current master resolves and launches OpenClaw.SetupEngine.UI.exe from a SetupEngine payload directory, so the PR is not obsolete on main. (src/OpenClaw.Tray.WinUI/App.xaml.cs:2936, 99efc50cbc22)
• PR hosts setup window inside tray: At PR head, the tray owns a SetupWindow, handles post-setup restart arguments, and opens the setup window directly from ShowOnboardingAsync. (src/OpenClaw.Tray.WinUI/App.xaml.cs:3020, bb8746b0067d)
• PR changes installer entrypoints: At PR head, the installer requires the tray executable, rejects SetupEngine.UI.exe, and routes the Gateway Setup shortcut to the tray with openclaw://setup. (installer.iss:61, bb8746b0067d)
• PR changes release signing/publish topology: At PR head, CI publishes only the tray app and stages only OpenClaw.Tray.WinUI.exe for x64 and ARM64 signing inputs. (.github/workflows/ci.yml:388, bb8746b0067d)
• Feature history provenance: git blame and git show tie the current setup engine/UI and installer baseline to the v0.6.3 snapshot, while release signing guard work was later introduced in 528f625. (src/OpenClaw.SetupEngine.UI/SetupWindow.xaml.cs:1, 85445c78066b)

Likely related people:

• Christine Yan: Current setup engine/UI, installer, workflow, and tray setup-launch code are mostly from the v0.6.3 snapshot commit. (role: introduced setup engine/UI baseline; confidence: high; commits: 85445c78066b; files: src/OpenClaw.SetupEngine.UI/SetupWindow.xaml.cs, src/OpenClaw.SetupEngine/Program.cs, src/OpenClaw.Tray.WinUI/App.xaml.cs)
• Scott Hanselman: Recent history introduced the tray app launch wrapper and release executable signing guard touched by this topology change. (role: recent adjacent owner; confidence: medium; commits: 281656fc017e, 528f625edc5b; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/CliUninstallHandler.cs, src/OpenClaw.Tray.WinUI/Pages/SettingsPage.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.