Add persistent Local Gateway setup card

[ranjeshj]

Summary

Adds a persistent Local Gateway setup card to the Settings page so users can always relaunch setup after installing a local WSL gateway. Previously, the setup/reconfigure affordance was hidden once an app-owned WSL gateway existed, making it harder to discover how to rerun setup or provider/model configuration.

The new card:

• Always appears in the Settings page's Local Gateway section.
• Uses clear copy explaining that it launches setup for a new app-owned OpenClawGateway WSL distro or reruns provider/model setup for an existing local gateway.
• Reuses the existing onboarding/setup command path instead of adding new setup logic.
• Keeps the destructive Remove Local Gateway management card conditional on an installed gateway.
• Adds localized strings for all current locales: en-us, fr-fr, nl-nl, zh-cn, and zh-tw.

Screenshot

Review

Ran the repo autoreview helper with a Hanselman-style high-signal prompt. The default Codex review engine was unavailable in this environment, so I used the installed Copilot engine with the helper's explicit unsandboxed-tools opt-in.

Command:

$env:PYTHONUTF8='1'; $env:AUTOREVIEW_ALLOW_UNSANDBOXED_TOOLS='1'; python .agents\skills\autoreview\scripts\autoreview --mode local --engine copilot --prompt "Hanselman-style review: be practical and high-signal. Focus only on correctness, maintainability, localization, UX discoverability, accessibility, and security issues that should block this small settings-page change. Do not nitpick style."

Result: autoreview clean: no accepted/actionable findings reported.

Validation

• ./build.ps1 ✅
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore ✅ 2074 total, 2045 passed, 29 skipped
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore ✅ 934 total, 934 passed

The first --no-restore test invocation hit the repo-documented fresh-worktree no-op behavior, so I ran both test projects once with restore enabled and then reran the required --no-restore commands successfully.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 3, 2026, 3:22 PM ET / 19:22 UTC.

Summary
The PR adds a persistent Local Gateway setup card to Settings, wires its button to the existing onboarding/setup command, and adds the new strings across the current locales.

Reproducibility: not applicable. for a PR review of a settings affordance change; source and docs show the current setup affordance is intentionally conditional when an app-owned local WSL gateway exists.

Review metrics: 2 noteworthy metrics.

• Diff surface: 7 files changed, 85 additions, 9 deletions. The change is limited to one Settings page, one code-behind handler, and locale resources.
• Locale coverage: 5 locale resource files updated. The new user-visible Settings strings are present for every current locale listed by the PR and onboarding docs.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit ✨ media proof bonus
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:

• none.

Risk before merge

• [P1] Read-only review did not rerun the Windows build or tests; the PR body reports the AGENTS-required build and both test projects passing.

Maintainer options:

1. Decide the mitigation before merge
   Land the persistent Settings affordance if maintainers accept the UX, while keeping the existing onboarding command path and confirmation before any local WSL gateway replacement.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P2] No repair lane is needed; maintainers can decide whether to merge this UX affordance after normal check review.

Security
Cleared: The diff only changes Settings UI and localization resources; it does not alter credentials, setup execution, dependency resolution, or CI/release code.

Review details

Best possible solution:

Land the persistent Settings affordance if maintainers accept the UX, while keeping the existing onboarding command path and confirmation before any local WSL gateway replacement.

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

Not applicable for a PR review of a settings affordance change; source and docs show the current setup affordance is intentionally conditional when an app-owned local WSL gateway exists.

Is this the best way to solve the issue?

Yes. Reusing IAppCommands.ShowOnboarding avoids duplicate setup logic, and the existing SetupEngine confirmation still guards the destructive replacement path.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P3: This is a low-risk Settings discoverability improvement rather than an urgent runtime regression.
• add proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes an inspected after-change Settings screenshot showing the added Local Gateway setup card and existing removal card.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body includes an inspected after-change Settings screenshot showing the added Local Gateway setup card and existing removal card.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The PR body includes an inspected after-change Settings screenshot showing the added Local Gateway setup card and existing removal card.

Label justifications:

• P3: This is a low-risk Settings discoverability improvement rather than an urgent runtime regression.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The PR body includes an inspected after-change Settings screenshot showing the added Local Gateway setup card and existing removal card.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes an inspected after-change Settings screenshot showing the added Local Gateway setup card and existing removal card.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body includes an inspected after-change Settings screenshot showing the added Local Gateway setup card and existing removal card.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its gateway/onboarding guidance applies to this Settings/local gateway UX review, while validation commands were not rerun because this review is read-only. (AGENTS.md:1, f839cf53aa0c)
• Current-main conditional setup affordance: The Connections page hides the local WSL setup card and item when WslKeepAlivePolicy reports a setup-managed local gateway. (src/OpenClaw.Tray.WinUI/Pages/ConnectionPage.xaml.cs:205, f839cf53aa0c)
• Current-main tray menu also hides setup entry: The tray menu snapshot sets ShowSetupMenuEntry to false when a setup-managed local WSL gateway exists. (src/OpenClaw.Tray.WinUI/App.xaml.cs:1117, f839cf53aa0c)
• PR diff adds persistent Settings card: The PR diff removes the Local Gateway header collapse, adds a setup card with Open setup button, adds OnOpenLocalGatewaySetup, and updates locale resources. (src/OpenClaw.Tray.WinUI/Pages/SettingsPage.xaml:251, 25fb591a86ed)
• Existing setup command is reused: Settings and Connection pages use IAppCommands.ShowOnboarding, whose App implementation launches SetupEngine.UI through ShowOnboardingAsync. (src/OpenClaw.Tray.WinUI/App.xaml.cs:2983, f839cf53aa0c)
• Replacement confirmation remains in setup flow: SetupEngine's Welcome page detects existing local gateway state and shows a confirmation dialog titled 'Replace existing WSL gateway?' before continuing. (src/OpenClaw.SetupEngine.UI/Pages/WelcomePage.xaml.cs:72, f839cf53aa0c)

Likely related people:

• ranjeshj: Current-main history shows this author recently hid the reconfigure/setup entry for setup-managed WSL gateways, which is the behavior this PR revisits. (role: recent adjacent contributor; confidence: high; commits: f4d4793f744f; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/Services/WslKeepAlivePolicy.cs, tests/OpenClaw.Tray.Tests/WslKeepAlivePolicyTests.cs)
• Régis Brid: Blame on the Settings local gateway XAML and visibility helper points to the commit that added the current Settings management card. (role: introduced Settings local-gateway surface; confidence: high; commits: 7d9152f427a3; files: src/OpenClaw.Tray.WinUI/Pages/SettingsPage.xaml, 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.