# [Bug]: Installer setup wizard has no Back button

[hgoodrow]

Description

The Windows installer/setup wizard does not provide a Back button at any step of the installation process. If a user makes a mistake (e.g., selects the wrong installation directory, provider, or configuration option), there is no way to go back and correct it.

The only workaround currently available is to cancel/terminate the installer entirely and restart from the beginning, which is disruptive and forces re-entry of all previously completed steps.

---

Steps to Reproduce

1. Launch the OpenClaw Windows installer (OpenClawTray-0.6.3-win-x64.exe).
2. Progress through one or more steps of the setup wizard (e.g., select an installation path, configure a provider, etc.).
3. Realize a mistake was made on a previous step.
4. Attempt to navigate back to the previous step.

Expected: A Back button is present, allowing the user to return to the previous step and correct the mistake.
Actual: No Back button exists. The user is stuck moving forward or must abort the entire installation.

---

Workaround

Cancel/kill the installer process and restart it from the beginning.

---

Impact

• Severity: Medium — not a crash, but significantly degrades the installation UX.
• Affected users: Anyone who makes any configuration error during the multi-step setup wizard.
• Risk of workaround: Depending on how far into installation the user is when they abort, partial artifacts may be left on disk, potentially causing issues on retry.

---

Expected Behavior

Each step of the setup wizard should include a Back button that navigates the user to the previous step, preserving any values already entered — consistent with standard Windows installer UX conventions (NSIS, Inno Setup, WiX, etc.).

---

Environment

• OS: Windows 11 Enterprise (64-bit)
• OS Build: 10.0.26200
• Architecture: AMD64 (x64)
• Installer version: 0.6.3 (OpenClawTray-0.6.3-win-x64)
• Installation method: Windows setup wizard / .exe installer

---

Additional Notes

Most installer frameworks (Inno Setup, WiX Toolset, NSIS) provide built-in Back/Next/Cancel navigation. If the current framework supports it, enabling the Back button may be a low-effort change.

[clawsweeper]

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

Summary
Keep open: current main still lacks a general Back affordance in the packaged SetupEngine installer flow, and v0.6.3 contains the same setup UI. The request is valid, but the exact Back semantics need maintainer UX/product judgment because some setup phases are irreversible or gateway-controlled.

Reproducibility: yes. from source inspection: the packaged SetupEngine UI exposes forward/recovery controls but no general Back affordance in the installer setup flow. I did not run the Windows installer in this Linux read-only review.

Next step
Maintainers should first choose the supported Back behavior across SetupEngine pages, irreversible progress, and gateway RPC steps before a fix PR is queued.

Review details

Best possible solution:

Define which setup phases are reversible, add Back only where state can be safely preserved, and keep explicit Start over/Skip behavior for irreversible or gateway-controlled phases unless a supported previous-step protocol exists.

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

Yes, from source inspection: the packaged SetupEngine UI exposes forward/recovery controls but no general Back affordance in the installer setup flow. I did not run the Windows installer in this Linux read-only review.

Is this the best way to solve the issue?

Unclear: adding Back is directionally right for reversible setup pages, but the requested “each step” behavior is not automatically the safest solution for WSL progress or gateway-owned wizard steps.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• This review did not run the Windows installer; reproduction is source-level against current main and v0.6.3 provenance.
• A naive Back button could be unsafe for the Progress phase because WSL setup steps are stateful and partly irreversible once started.
• Gateway setup steps are server-controlled via wizard.start / wizard.next, so true previous-step navigation may require gateway protocol support or a defined restart/edit model.

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

Label changes

Label changes:

• add P2: Installer navigation is a normal-priority UX improvement with limited blast radius but real setup friction for affected users.
• add impact:other: The issue affects Windows installer/setup usability and recovery from setup mistakes, which is maintainer-visible but outside the specific owned impact categories.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: Installer navigation is a normal-priority UX improvement with limited blast radius but real setup friction for affected users.
• impact:other: The issue affects Windows installer/setup usability and recovery from setup mistakes, which is maintainer-visible but outside the specific owned impact categories.

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

What I checked:

• Installer ships the SetupEngine UI: The Inno installer requires and installs SetupEngine\OpenClaw.SetupEngine.UI.exe, so the reported installer setup flow maps to the SetupEngine UI surface rather than only the older tray setup window. (installer.iss:61, 99efc50cbc22)
• SetupEngine window exposes only forward page navigation helpers: SetupWindow has NavigateToCapabilities, NavigateToProgress, NavigateToWizard, NavigateToPermissions, and NavigateToComplete, with no shared Back or frame history handler. (src/OpenClaw.SetupEngine.UI/SetupWindow.xaml.cs:74, 99efc50cbc22)
• Gateway wizard page has recovery/skip/continue controls but no Back: The wizard page bottom bar contains Start over, Skip wizard, Skip/No, and Continue/Yes buttons; no Back button or previous-step command is present. (src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml:34, 99efc50cbc22)
• Capabilities page only proceeds forward: The capabilities step renders a single Continue button that calls Continue_Click, and the code-behind navigates directly to Progress. (src/OpenClaw.SetupEngine.UI/Pages/CapabilitiesPage.xaml:35, 99efc50cbc22)
• Docs describe a forward-only setup flow: The SetupEngine design doc lists Welcome → Capabilities → Progress → Permissions → Complete and describes Continue/Next behavior without a general Back path. (docs/SETUP_ENGINE_REDESIGN.md:258, 99efc50cbc22)
• Gateway wizard protocol is forward-oriented: The onboarding doc says the gateway controls the wizard via wizard.start / wizard.next, which supports the concern that Back semantics may need protocol/product design rather than a UI-only button. (docs/ONBOARDING_WIZARD.md:30, 99efc50cbc22)

Likely related people:

• Christine Yan: Current-line blame for the SetupEngine UI and installer packaging in the checked-out main points to the v0.6.3 commit authored by Christine Yan. (role: current-main implementation contributor; confidence: medium; commits: 85445c78066b; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml, src/OpenClaw.SetupEngine.UI/SetupWindow.xaml.cs, installer.iss)
• Ranjesh: Recent history shows wizard recovery work touching WizardPage.xaml, WizardPage.xaml.cs, and onboarding docs, which are central to any Back semantics in the gateway-controlled setup step. (role: recent gateway wizard contributor; confidence: high; commits: 9d304c110c0f; files: src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.xaml.cs, docs/ONBOARDING_WIZARD.md)
• Scott Hanselman: History shows earlier installer and setup wizard commits from Scott Hanselman, including the original installer path and the older tray setup wizard that already has Back navigation. (role: installer and earlier setup-flow contributor; confidence: medium; commits: 40e2064531f0, f235f3f999bd; files: installer.iss, src/OpenClaw.Tray.WinUI/Windows/SetupWizardWindow.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.

Good find — and worth clarifying which wizard is affected.

Which wizard: This is about the in-app setup wizard (the WizardPage.xaml.cs gateway-driven flow that runs after installation to configure your provider, channels, etc.), not the Inno Setup .exe installer. The Inno Setup installer already shows Back/Next/Cancel navigation on its own pages.

Technical constraint: The in-app wizard is fully driven by the gateway via wizard.start / wizard.next RPCs — each step's content, type, and options all come from the server. The client has no knowledge of previous steps; it just renders whatever payload the gateway sends. To support Back navigation, one of these would be needed:

1. Gateway wizard.back RPC — the server replays the previous step payload. This is the cleanest solution but requires gateway-side state management.
2. Client-side step history — the Windows client saves each step's payload locally and replays it on Back, re-sending the user's previous answer to skip forward. More complex and potentially inconsistent if gateway state diverges.

This is a meaningful UX improvement — especially since a mis-click or wrong choice currently means aborting and restarting the entire wizard. The clawsweeper:needs-product-decision label is appropriate since the fix requires gateway/product coordination. Happy to implement the client-side piece once the gateway API direction is decided.

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

[ranjeshj]

I think we should avoid solving this as only “add a Back button” on the current gateway-driven wizard protocol.

The current in-app setup wizard is effectively a linear RPC conversation: the client calls wizard.start, renders whatever step the gateway returns, then calls wizard.next with the selected answer. That model makes the Windows client a thin renderer for a gateway-owned state machine. Because the client does not know the full flow, previous steps, possible branches, or whether prior answers can be edited safely, it cannot implement normal Back/Forward navigation in a reliable UX-friendly way.

A wizard.back RPC would be an improvement, but it still keeps the flow imperative and server-driven. It also means every gateway implementation has to preserve enough session state to replay previous steps, handle changed answers, invalidate later answers, and define what “back” means after side effects. That may be workable, but it does not address the broader UX problem: the client cannot present a coherent setup experience because it only learns one step at a time.

A better direction may be to make the gateway provide a declarative wizard definition up front, and let the Windows setup UI own navigation and local draft state.

For example, the gateway could return a wizard manifest containing:

• Wizard id/version.
• All possible pages or steps.
• Field definitions, labels, help text, defaults, and required/optional state.
• Choice lists and branching/visibility rules.
• Validation schema or per-field validation metadata.
• Which steps are informational, editable, skippable, or irreversible.
• A final submit/commit action that sends the completed configuration back to the gateway.
• Optional validation RPCs for cases where a field must be checked against gateway state before the final commit.

With that model, the Windows client can show a normal setup UX:

• Back and Forward navigation.
• Preserve previously entered values.
• Allow review/edit before submit.
• Disable Back only for explicitly irreversible/committed phases.
• Show a progress/sidebar model if the flow has multiple sections.
• Support richer UX flows than a strict question/answer sequence.
• Avoid forcing users to cancel and restart because of one wrong choice.

The gateway would still own the provider-specific setup contract, but the client would own presentation and navigation. Instead of the gateway “driving” the wizard one step at a time, the gateway would describe the possible setup flow and receive the final result, or receive validation requests as needed.

There are a few possible implementation shapes:

1. Declarative upfront manifest, final submit

   • Gateway returns the complete wizard definition from wizard.start.
   • Client manages all navigation and draft answers locally.
   • Client sends one final payload to the gateway when the user clicks Finish/Apply.
   • Best UX and simplest Back/Forward behavior.

2. Declarative manifest with validation checkpoints

   • Same as above, but specific fields/steps can call gateway validation before proceeding.
   • Useful for tokens, URLs, credentials, provider connectivity, etc.
   • Still keeps navigation client-owned.

3. Gateway-owned session with wizard.back

   • Smaller protocol change.
   • Gateway remains the state machine.
   • Client asks the gateway to move backward/forward.
   • This is easier to retrofit but likely less flexible and more fragile long-term.

My recommendation would be option 1 or 2 rather than only adding wizard.back. The setup wizard is a UX surface, and users expect to be able to move around, review, correct mistakes, and understand what remains before committing. A one-step-at-a-time RPC protocol makes that hard even if we add a Back endpoint.

We should probably define the gateway wizard protocol around a client-rendered form/flow contract, with explicit commit boundaries. Irreversible operations should happen only after the user reaches a final confirmation step, or should be clearly marked as non-reversible in the manifest so the client can disable Back at that point.

This would also make the installer/setup UX easier to test because the Windows client could render a known wizard definition without requiring a live step-by-step gateway conversation for every navigation path.