chore(setup): bump gateway LKG to 2026.6.1

[github-actions]

Gateway LKG update

• Previous pinned LKG: 2026.5.28
• Candidate latest: 2026.6.1
• Updated file: src/OpenClaw.SetupEngine/GatewayLkgVersion.cs

This is the standing automation PR used to review and validate gateway LKG bumps before merge.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 7, 2026, 4:36 AM ET / 08:36 UTC.

Summary
The PR changes src/OpenClaw.SetupEngine/GatewayLkgVersion.cs so the embedded setup gateway LKG moves from 2026.5.28 to 2026.6.1.

Reproducibility: not applicable. this is a setup version-bump PR, not a reported bug. Source inspection gives a high-confidence path showing how the pin reaches default setup, but there is no failure to reproduce.

Review metrics: 2 noteworthy metrics.

• Diff size: 1 file changed, +1/-1. The code patch is mechanically small, so the merge decision is dominated by runtime compatibility rather than implementation complexity.
• Default setup entry points: 2 production callers apply the LKG. Both CLI and UI setup call GatewayLkgVersion.ApplyToConfig, so this version bump affects default setup broadly.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
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:

• [P2] Run ./build.ps1, the required shared and tray test projects, and a setup/E2E smoke with Gateway.Version unset against gateway 2026.6.1.

Risk before merge

• [P1] Merging promotes gateway 2026.6.1 as the default setup install when Gateway.Version is unset and the default installer URL is used; a bad candidate would break first-run gateway install or runtime startup.
• [P1] This review verified the npm package exists and is the current latest tag, but it did not run the Windows build, required shared/tray tests, or a live setup/E2E smoke proving 2026.6.1 is actually last-known-good for this repo.

Maintainer options:

1. Validate the candidate LKG before merge (recommended)
   Run the required build/tests plus a setup or E2E smoke with Gateway.Version unset, then merge only if gateway 2026.6.1 behaves as the new known-good default.
2. Hold the current default if validation fails
   If the candidate fails setup or compatibility smoke, close or refresh this PR and leave 2026.5.28 as the default LKG until a working release is available.

Next step before merge

• [P2] Maintainers need to validate and accept the gateway candidate; there is no narrow code repair for automation to apply.

Security
Cleared: The diff only changes the existing first-party gateway version pin and does not alter workflows, permissions, secrets handling, dependency manifests, or install-script logic.

Review details

Best possible solution:

Land the bump only after required repo validation and a setup or E2E smoke confirm 2026.6.1 works as the new LKG; otherwise keep 2026.5.28 or regenerate for a later known-good release.

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

Not applicable; this is a setup version-bump PR, not a reported bug. Source inspection gives a high-confidence path showing how the pin reaches default setup, but there is no failure to reproduce.

Is this the best way to solve the issue?

Yes, if maintainers accept 2026.6.1 as the intended known-good gateway release, the one-line constant bump is the narrowest implementation. The remaining blocker is runtime validation of the external candidate, not a code-shape issue.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P2: This is a normal setup maintenance update with limited code scope but real first-run setup impact if the candidate gateway is bad.
• merge-risk: 🚨 compatibility: The PR changes the default gateway runtime installed by setup for users who leave Gateway.Version unset.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a standing repository automation bot PR, so the external contributor real-behavior proof gate does not apply.

Evidence reviewed

Acceptance criteria:

• [P1] ./build.ps1.
• [P1] dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore.
• [P1] Run a setup or E2E smoke with Gateway.Version unset and the default install URL to prove gateway 2026.6.1 installs and starts successfully.

What I checked:

• PR diff: The PR head changes only GatewayLkgVersion.LkgVersion, replacing 2026.5.28 with 2026.6.1. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:6, 5fe21602e184)
• Current base pin: Current master still embeds 2026.5.28, so the requested bump is not already implemented on the default branch. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:6, 4be005707f44)
• Default setup injection: ApplyToConfig writes the embedded LKG only when Gateway.Version is blank and the install URL is blank or the default installer URL. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:10, 4be005707f44)
• Setup consumption path: CLI setup applies the LKG config path, and InstallCliStep passes ctx.Config.Gateway.Version into the install command. (src/OpenClaw.SetupEngine/Program.cs:51, 4be005707f44)
• Automation contract: Repository docs say the pinned gateway setup version lives in this constant and setup/E2E consume it when Gateway.Version is not explicitly set. (DEVELOPMENT.md:541, 4be005707f44)
• Updater workflow: The standing LKG workflow resolves openclaw/latest from npm, writes the constant, and creates or updates the automation PR. (.github/workflows/gateway-lkg-update.yml:43, 4be005707f44)

Likely related people:

• ranjeshj: Git and GitHub API history show this handle authored the LKG pinning workflow, hardening change, and adjacent manual LKG update work. (role: feature-history owner; confidence: high; commits: 45df0763e1ca, dcc77f55e2c9, ca8c6772db81; files: src/OpenClaw.SetupEngine/GatewayLkgVersion.cs, .github/workflows/gateway-lkg-update.yml, DEVELOPMENT.md)
• shanselman: GitHub commit metadata lists this handle as committer for the LKG introduction, hardening, and adjacent manual version update commits. (role: merger/committer in LKG history; confidence: medium; commits: 45df0763e1ca, dcc77f55e2c9, ca8c6772db81; files: src/OpenClaw.SetupEngine/GatewayLkgVersion.cs, .github/workflows/gateway-lkg-update.yml, DEVELOPMENT.md)
• bkudiess: Recent setup wizard work touched SetupSteps.cs and related runtime setup behavior that would be exercised by an LKG setup smoke. (role: recent setup/wizard contributor; confidence: low; commits: 8f134b354df0; files: src/OpenClaw.SetupEngine/SetupSteps.cs, src/OpenClaw.SetupEngine.UI/Pages/WizardPage.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.