chore(setup): bump gateway LKG to 2026.6.11

[github-actions]

Gateway LKG update

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

Registry verification

• npm view openclaw version: 2026.6.11
• npm dist-tag latest: 2026.6.11
• Package: https://www.npmjs.com/package/openclaw/v/2026.6.11
• Tarball: https://registry.npmjs.org/openclaw/-/openclaw-2026.6.11.tgz
• Integrity: sha512-T+P/g19IheeT1ckXMoPN61dYuE8vBF4MderI+kWkvpuFYxPkJxn8AXLpu9IXCnN9g36Acpm9+mMD/V+lsvOkyA==

Rebased onto current main, including the native onboarding wizard and Windows-to-WSL CA trust sync.

Validation

• Exact-head Windows CI: unit/tray tests, real-WSL setup/connect, network recovery, revocation recovery, x64, and ARM64

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 5, 2026, 7:43 PM ET / 23:43 UTC.

Summary
The PR updates GatewayLkgVersion.LkgVersion in src/OpenClaw.SetupEngine/GatewayLkgVersion.cs from 2026.6.10 to 2026.6.11.

Reproducibility: not applicable. this is a maintenance LKG bump, not a bug report. Source inspection and the PR diff show exactly how the setup default changes.

Review metrics: 2 noteworthy metrics.

• Diff scope: 1 file changed, +1/-1. The patch is constrained to the embedded setup LKG constant.
• Default gateway version: 2026.6.10 -> 2026.6.11. This is the setup-facing default maintainers need to validate before merge.

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 or link a Windows/WSL setup smoke showing 2026.6.11 installs and pairs correctly before merge.

Risk before merge

• [P1] Merging changes the gateway package installed by fresh/default setup from 2026.6.10 to 2026.6.11, so any upstream installer, WSL setup, pairing, or protocol regression in that candidate would affect new installs until the pin is rolled back.
• [P1] The registry metadata is verified, but package existence and integrity do not prove the candidate is known-good through the Windows/WSL setup path.

Maintainer options:

1. Validate The Candidate Then Merge (recommended)
   Confirm 2026.6.11 installs and runs through the supported Windows/WSL setup path before merging the default bump.
2. Merge As A Routine Standing Bump
   Maintainers can explicitly accept the compatibility risk if the standing automation and registry verification are sufficient for this release window.
3. Pause For The Next LKG
   Leave the branch open or let automation replace it if 2026.6.11 loses known-good confidence.

Next step before merge

• No automated repair is needed; maintainers need to validate and decide whether 2026.6.11 is known-good enough to promote as the setup default.

Maintainer decision needed

• Question: Should 2026.6.11 be promoted as the known-good gateway version for fresh/default setup installs?
• Rationale: Source inspection proves the patch is narrow, but deciding whether a new upstream gateway package is safe for setup, WSL, and pairing requires maintainer release judgment and runtime validation.
• Likely owner: shanselman — This user is tied to the LKG introduction as committer and the current file contents as author, making them the strongest routing candidate from available history.
• Options:
  • Validate And Promote 2026.6.11 (recommended): Run or link required repository validation plus a Windows/WSL setup smoke before merging the LKG bump.
  • Accept The Routine Bump: Maintainers may intentionally merge after deciding the standing automation and registry verification are enough for this candidate.
  • Wait For A Later Candidate: If 2026.6.11 is not known-good, leave the standing PR open for the updater to replace it with a later gateway version.

Security
Cleared: No concrete security or supply-chain regression was found in the diff; it only advances the official pinned gateway version constant while leaving installer URL, workflow permissions, and dependency sources unchanged.

Review details

Best possible solution:

Keep the single LKG constant as the setup source of truth and merge this PR only after maintainers accept 2026.6.11 as known-good with current-head setup validation.

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

Not applicable: this is a maintenance LKG bump, not a bug report. Source inspection and the PR diff show exactly how the setup default changes.

Is this the best way to solve the issue?

Yes: updating the single documented LKG constant is the narrowest maintainable path for this standing gateway LKG bump. The merge path should stay validation-gated rather than broadening setup code.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P3: This is a routine setup LKG maintenance bump with limited blast radius, not an urgent regression.
• merge-risk: 🚨 compatibility: Changing the embedded setup LKG can make fresh/default installs use a different gateway package than existing releases.
• 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 bot-generated standing maintenance PR, so the external-contributor real-behavior-proof gate is not applied; maintainers should still require setup validation before merge.

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 or link setup/gateway install validation for openclaw package 2026.6.11.

What I checked:

• Repository policy applied: AGENTS.md was read fully; its setup/proof guidance applies because this PR changes setup behavior, but this ClawSweeper run is read-only so validation commands were inspected as requirements rather than executed. (AGENTS.md:1, 919a8cef23ba)
• Current main pin: Current main still pins the setup gateway LKG to 2026.6.10, so this PR is not obsolete on main. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:6, 919a8cef23ba)
• Live PR diff: The live PR diff changes only the embedded LKG constant from 2026.6.10 to 2026.6.11. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:6, 4cdab8222038)
• Setup applies the LKG default: Setup applies GatewayLkgVersion.ApplyToConfig(config) after environment overrides, making the constant the default gateway version when config does not specify one. (src/OpenClaw.SetupEngine/Program.cs:51, 919a8cef23ba)
• Installer consumes configured version: The install step builds the installer command with ctx.Config.Gateway.Version, so changing the LKG changes the package fresh/default setup installs. (src/OpenClaw.SetupEngine/SetupSteps.cs:1439, 919a8cef23ba)
• Standing automation documented: Development docs identify GatewayLkgVersion.cs as the pinned setup source of truth and describe the standing automation branch for npm latest drift. (DEVELOPMENT.md:576, 919a8cef23ba)

Likely related people:

• ranjeshj: GitHub commit metadata shows this user authored the commits that introduced and hardened the gateway LKG pinning and updater path. (role: introduced LKG behavior; confidence: high; commits: 45df0763e1ca, dcc77f55e2c9; files: src/OpenClaw.SetupEngine/GatewayLkgVersion.cs, .github/workflows/gateway-lkg-update.yml, tests/OpenClaw.SetupEngine.Tests/GatewayLkgVersionTests.cs)
• shanselman: GitHub metadata lists this user as committer for the LKG introduction/hardening commits and author of the current release-tagged file contents. (role: LKG committer and recent file owner; confidence: high; commits: 45df0763e1ca, dcc77f55e2c9, 4166e0fd63f8; files: src/OpenClaw.SetupEngine/GatewayLkgVersion.cs, .github/workflows/gateway-lkg-update.yml)
• steipete: Recent main history includes Windows gateway onboarding work by this user, and the PR timeline shows this user force-pushed and marked the standing update ready for review. (role: recent adjacent setup contributor; confidence: medium; commits: adcb4c378f90; files: src/OpenClaw.SetupEngine.UI/SetupWindow.xaml.cs, src/OpenClaw.SetupEngine/SetupContext.cs, src/OpenClaw.SetupEngine/SetupReviewSummary.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.

Review history (4 earlier review cycles)

• reviewed 2026-07-03T08:35:35.928Z sha f962fea :: needs maintainer review before merge. :: none
• reviewed 2026-07-04T08:18:33.391Z sha 8fd6e00 :: needs maintainer review before merge. :: none
• reviewed 2026-07-05T08:29:04.106Z sha 10dc294 :: needs maintainer review before merge. :: none
• reviewed 2026-07-05T23:38:38.707Z sha 4cdab82 :: needs maintainer review before merge. :: none