Keep Windows Companion aligned with current OpenClaw stable and beta releases

[TheAngryPit]

Problem

The Windows Companion and OpenClaw core are separate products, but the Companion owns the supported Windows installation path for the core.

The current Companion Setup Engine still defaults to OpenClaw 2026.6.11, while the current official releases are:

• stable: 2026.7.1
• beta: 2026.7.2-beta.1

This leaves Windows users on an older core when they install through the Companion-owned flow. Avoiding a current stable release because it has a core regression is not a sustainable synchronization strategy: compatibility work and core defects should be tracked and fixed in the repository that owns each behavior.

Goal

Keep the Windows Companion's supported install and upgrade path aligned with current OpenClaw releases:

• update the Companion's default stable OpenClaw version;
• validate the Companion against the current stable core;
• identify compatibility changes needed for the active beta before it becomes stable;
• keep Companion/Windows Node fixes in this repository;
• report and fix OpenClaw core regressions in openclaw/openclaw, rather than carrying Companion workarounds.

Proposed Sequence

1. Land the bounded stable-alignment change in fix(setup): validate current OpenClaw package lifecycle #999:
   • invariant compact-number formatting for pt-PT and other decimal-comma locales;
   • update the Setup Engine LKG from 2026.6.11 to stable 2026.7.1;
   • no unrelated session or /new behavior changes.
2. Prove the current-head Companion installer against stable 2026.7.1 through the real Companion-owned setup path.
3. Classify every reproduced failure by product ownership:
   • Companion/Windows Node defects stay here;
   • OpenClaw core defects move to openclaw/openclaw with independent reproduction.
4. Validate the active 2026.7.2-beta.1 line early enough to prepare compatible Companion changes before the next stable release.
5. Keep version pins, tests, setup documentation, and release evidence synchronized.

Acceptance Criteria

• The Companion no longer defaults to the stale 2026.6.11 core.
• The stable version selected by the Setup Engine is covered by exact tests.
• A real Windows Companion install/upgrade proof exists for the selected stable version.
• Beta compatibility findings are recorded before beta promotion, with fixes made in the owning product.
• No custom OpenClaw fork or silent core workaround is bundled into the Companion.
• Known regressions remain explicit and do not get misrepresented as Companion compatibility fixes.

First PR

• fix(setup): validate current OpenClaw package lifecycle #999 updates invariant pt-PT formatting and the Setup Engine LKG to OpenClaw 2026.7.1.
• The PR remains draft while its current-head installer/runtime proof is completed.
• Known OpenClaw 2026.7.1 startup regression: [Bug]: update to openclaw 2026.7.1: gateway fails to start w/ error openclaw#108435

Current Status

The first PR has now exercised the real GitHub Actions setup path:

• the main build/test job passed, including Shared, Tray, Connection, Setup Engine, UI, accessibility, and related suites;
• all three setup E2E shards installed OpenClaw 2026.7.1 and then failed before their scenario logic because the Gateway repeatedly reported an active startup-migration lock for the fresh state directory;
• this confirms the version alignment itself and exposes a current OpenClaw core/runtime compatibility blocker;
• fix(setup): validate current OpenClaw package lifecycle #999 remains draft and should not work around that core failure inside the Companion.

Agent Transcript

Sanitized operator/agent decision record

• The operator identified that the Windows Companion had fallen behind the OpenClaw release it is expected to install.
• We confirmed from the official upstream sources that Windows Companion main is currently bf0fa8a9bde433db9f6758cc89723bf9bfdd06c0, OpenClaw stable is 2026.7.1, and beta is 2026.7.2-beta.1.
• We separated product ownership: the Companion should track current stable; known core regressions should be fixed in the OpenClaw repository rather than used to keep the Companion indefinitely pinned.
• We reduced the first PR to the bounded pt-PT formatting and stable LKG update. An earlier unrelated /new experiment was explicitly removed.
• This issue records an extended operator/agent compatibility and recovery effort, with isolated branches, full test gates, scoped Auto-review, and explicit proof gaps rather than a quick unverified version bump.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 16, 2026, 4:46 AM ET / 08:46 UTC.

Summary
The release-alignment work remains necessary: current main still carries the older Setup Engine pin, while the linked same-author draft pull request is the active implementation candidate but has not passed the repository-required real setup proof.

Reproducibility: not applicable. as a conventional bug reproduction. The underlying release drift is directly verifiable from the checked-in LKG, and the candidate version's setup failure is documented by three real E2E shards.

Root-cause cluster
Relationship: canonical
Canonical: #1000
Summary: This issue is the umbrella tracker for release alignment, and the linked draft pull request is the bounded candidate for the immediate stable-pin portion.

Members:

• fixed_by_candidate: fix(setup): validate current OpenClaw package lifecycle #999 - The draft pull request implements the immediate stable LKG update but remains unmerged and lacks successful real setup proof.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Do not queue a second repair because the same-author draft pull request already owns the bounded stable update; maintainers should resolve the release choice and review that candidate.

Maintainer decision needed

• Question: Should the Companion wait for the upstream startup-migration regression to be fixed before promoting 2026.7.1, or intentionally ship that stable pin with failed setup E2E?
• Rationale: The existing drift policy favors current stable, but repository policy requires successful real setup proof; accepting a known fresh-install failure is a release decision automation cannot make safely.
• Likely owner: shanselman — Recent merged setup stabilization work makes shanselman the strongest available human routing candidate for the release-safety choice.
• Options:
  • Require green setup proof (recommended): Keep the draft update blocked until the upstream regression is fixed and fresh-install plus upgrade proof succeeds, then promote the fixed stable promptly.
  • Ship the known failure: Promote 2026.7.1 now and explicitly accept that some fresh Companion installs may fail during gateway startup.
  • Skip to the next fixed stable: Retain 2026.6.11 until a later stable contains the upstream fix, then validate and promote that version instead of 2026.7.1.

Review details

Best possible solution:

Keep a tested stable LKG pin, promote each stable only after fresh-install and upgrade E2E pass through the Companion-owned path, and add a non-promoting beta compatibility job that records failures in the repository that owns them.

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

Not applicable as a conventional bug reproduction. The underlying release drift is directly verifiable from the checked-in LKG, and the candidate version's setup failure is documented by three real E2E shards.

Is this the best way to solve the issue?

Partly. The bounded pin update and exact tests are appropriate, but promotion without successful real setup proof is not; stable promotion and beta observation should remain separate gated activities.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Changing the supported pin before the real Companion setup path succeeds could make fresh Windows installation fail during gateway startup.
• Leaving the supported pin on 2026.6.11 indefinitely creates growing compatibility drift and prevents the Companion path from receiving current upstream fixes and behavior.

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

Label changes

Label changes:

• add P2: This is a concrete setup and release-alignment improvement with meaningful but currently bounded user impact and an active implementation path.
• add impact:ux-friction: The supported Windows setup path either installs an older core or requires maintainers to navigate a known compatibility blocker, creating avoidable setup and support burden.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a concrete setup and release-alignment improvement with meaningful but currently bounded user impact and an active implementation path.
• impact:ux-friction: The supported Windows setup path either installs an older core or requires maintainers to navigate a known compatibility blocker, creating avoidable setup and support burden.

Evidence reviewed

What I checked:

• Current pin remains stale: At the reviewed main SHA, the Setup Engine LKG source still selects OpenClaw 2026.6.11 rather than the reported current stable 2026.7.1. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:7, bf0fa8a9bde4)
• Version contract has focused coverage: The repository has dedicated GatewayLkgVersion tests, making the selected setup version an explicit tested contract rather than incidental installer behavior. (tests/OpenClaw.SetupEngine.Tests/GatewayLkgVersionTests.cs:1, bf0fa8a9bde4)
• Stable drift already has automation: The scheduled Gateway LKG Update workflow compares the checked-in pin with npm latest and maintains a draft update pull request when they differ. (.github/workflows/gateway-lkg-update.yml:1, bf0fa8a9bde4)
• Open candidate has incomplete runtime proof: The linked draft pull request updates the pin to 2026.7.1, but all three real setup E2E shards fail after installation because the gateway reports an active startup-migration lock. (src/OpenClaw.SetupEngine/GatewayLkgVersion.cs:7, 953c7cc52f74)
• Repository policy requires setup proof: AGENTS.md requires automated validation and current-head real setup or gateway proof for setup and onboarding changes; the linked pull request explicitly records that proof as blocked. (AGENTS.md:1, bf0fa8a9bde4)

Likely related people:

• TheAngryPit: Authored the exact linked draft implementation at commit 953c7cc, including the Setup Engine pin change and focused version coverage. (role: current implementation proposer; confidence: high; commits: 953c7cc52f74; files: src/OpenClaw.SetupEngine/GatewayLkgVersion.cs, tests/OpenClaw.SetupEngine.Tests/GatewayLkgVersionTests.cs)
• shanselman: Authored the recently merged identity-path and setup-keepalive stabilization work in Stabilize dev identity paths #933, making this a strong routing candidate for setup and release behavior. (role: recent setup stabilization contributor; confidence: medium; files: src/OpenClaw.Shared, src/OpenClaw.SetupEngine, tests/OpenClaw.SetupEngine.Tests)
• bkudiess: Authored the substantial setup and connection recovery work in Improve remote gateway setup and connection error recovery #828, including user-facing setup guidance and failure recovery. (role: recent setup recovery contributor; confidence: medium; files: src/OpenClaw.Tray.WinUI/Pages/ConnectionPage.xaml.cs, tests/OpenClaw.Tray.Tests, docs)

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.

[TheAngryPit]

Current beta.2 integration update:

• Windows Companion PR fix(setup): validate current OpenClaw package lifecycle #999 now targets official OpenClaw 2026.7.2-beta.2 and has passed its local build, focused suites, Companion-owned WSL revocation/reconnect proof, and strict Gateway -> Windows Node -> MXC proof when paired with the isolated Gateway wizard correction.
• The unmodified official beta.2 package still loses the Gateway during the native wizard in all three hosted setup E2E shards (setup-connect, revocation-recovery, and network-recovery).
• The remaining owner boundary is now explicit: the Companion installs and starts the managed Gateway service before invoking wizard.start, while the Gateway RPC wizard currently inherits standalone CLI exit behavior and cannot accept installDaemon: false from its caller.
• OpenClaw PR #110382 is the active core candidate. OpenClaw PR #109412 covers the complementary daemon-control projection and will be consolidated into #110382 rather than maintained as a competing patch.

Planned landing sequence:

1. Track the embedded wizard lifecycle/ownership defect in canonical OpenClaw issue [Bug]: Gateway RPC wizard inherits CLI process and service lifecycle openclaw#110545.
2. Consolidate the non-exiting runtime and caller-controlled installDaemon contract in OpenClaw #110382, with focused tests and exact-head Gateway runtime proof.
3. Update Windows Companion fix(setup): validate current OpenClaw package lifecycle #999 to send exactly installDaemon: false from both wizard entry paths, rebase on current Windows Node main, and preserve the current Tailscale/setup pipeline work.
4. Require a clean disposable Windows installation against an official OpenClaw package containing the core fix before claiming the Companion path is complete.

This keeps one issue and one implementation PR per repository, with no private core workaround shipped in the Companion.