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 August 23, 2026, 8:20 AM ET / 12:20 UTC.

Summary
Keep open. Current main deliberately installs only a reviewed, evidence-gated Gateway release and rejects the requested 2026.7.1 candidate; the remaining thin runtime-update integration needs a Core-contract and product-scope decision, while related same-author PRs remain open.

Reproducibility: not applicable. as a current defect reproduction. Source confirms the observed non-latest release selection is intentional policy, not an unverified failure path.

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.

Maintainer decision needed

Question	Recommendation
Should the Companion remain limited to the current evidence-gated install policy until OpenClaw Core accepts a managed-Gateway update contract, with any later Windows work restricted to a thin integration?	Defer runtime update until Core contract: Keep the reviewed release policy and accept only a small Windows integration after the Core contract is accepted and proven.

Why: Current source establishes the install-time policy, but it cannot determine whether or when a persistent runtime-update experience should exist or which Core contract it may invoke.

Next step
A maintainer must confirm the Core contract and the permissible thin-integration scope; the linked same-author PRs already contain investigation that should not be independently dispatched.

Review details

Best possible solution:

Keep the evidence-gated install policy, then land only a narrowly scoped Windows adapter after OpenClaw Core accepts a managed-Gateway update contract and the adapter proves target selection, health, and node reconnection.

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

Not applicable as a current defect reproduction. Source confirms the observed non-latest release selection is intentional policy, not an unverified failure path.

Is this the best way to solve the issue?

No, automatic alignment to every upstream stable or beta is not the current supported design. The evidence-gated promotion path plus a Core-approved thin integration is the narrower maintainable solution.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Automatically tracking every stable or beta would bypass the existing exact-version Windows proof and provenance gate.
• The open implementation branches contain broader package and recovery designs that the discussion says must not become a parallel Windows-owned lifecycle.

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

Label changes

Label justifications:

• P2: This is a bounded but unresolved release-alignment and upgrade-policy decision without evidence that current users are blocked.
• impact:other: The issue concerns managed Gateway release alignment and upgrade ownership, which is a concrete operational impact outside the more specific owned impact labels.

Evidence reviewed

What I checked:

• Current release policy: Current main sets the recommended release to 2026.6.34, treats npm tags as discovery only, and marks 2026.7.1 runtime-rejected after a Windows setup failure. (src/OpenClaw.SetupEngine/GatewayReleasePolicy.cs:123, ccd64bbb7d68)
• Policy contract tests: Tests require the default to resolve to the embedded validated recommendation and keep the runtime-rejected release ineligible even when candidate execution is allowed. (tests/OpenClaw.SetupEngine.Tests/GatewayReleasePolicyTests.cs:58, ccd64bbb7d68)
• Accepted promotion boundary: The ADR requires exact-version Windows setup, pairing, reconnect, recovery, and Gateway-to-node proof before promotion; it states that the guarded 2026.7.1 recovery path does not itself promote that release. (docs/adr/0001-gateway-release-policy.md:22, ccd64bbb7d68)
• Candidate automation preserves review: The scheduled workflow creates evidence-only candidate PRs and explicitly does not update the installed recommendation without the promotion gate. (.github/workflows/gateway-release-candidate.yml:171, ccd64bbb7d68)
• Feature provenance: Blame attributes the release-policy surface to Scott Hanselman in commit 4206611, which is contained by the shipped v2026.7.1 tag. (src/OpenClaw.SetupEngine/GatewayReleasePolicy.cs:123, 4206611f2b2e)
• Discussion and linked work: The July 30 discussion records the Core-owned lifecycle and thin Windows-integration boundary; the linked Windows PRs remain open and the Core managed-Gateway contract issue remains open.

Likely related people:

• Scott Hanselman: Current release-policy lines blame to Scott's shipped commit, and the issue discussion attributes the Core-owned lifecycle boundary to his review. (role: release-policy author and decision participant; confidence: high; commits: 4206611f2b2e; files: src/OpenClaw.SetupEngine/GatewayReleasePolicy.cs, docs/adr/0001-gateway-release-policy.md)

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.

[TheAngryPit]

Direction update: Core-owned lifecycle, thin Windows integration

This comment supersedes the implementation sequence described in the issue
body and in the earlier beta.2 update. It preserves that history as useful
investigation, but does not treat those branches as release commitments.

Maintainer confirmation

Scott explicitly confirmed this direction after reviewing both PRs:

• Core owns the cross-platform Gateway package lifecycle, backup, recovery,
  retention, and rollback contracts.
• Native apps prove ownership, select a reviewed target, invoke Core's official
  update or repair flow, and verify health as macOS does.
• fix(setup): validate current OpenClaw package lifecycle #999 stops the contributor-fork package-composition path; only small Windows
  setup fixes using official Core artifacts may be extracted.
• feat: update Companion-owned Gateway safely in place #1049 stops the Windows-specific recovery design; any successor must be a
  thin Windows integration over the shared Core managed-Gateway contract.

This is maintainer-approved product direction. It does not approve a
replacement PR, a release commitment, or an implementation without a separately
scoped and accepted extraction. Both branches remain valuable investigation and
retain contributor credit. Future public updates will distinguish contributor
proposals from maintainer-approved roadmap items or release blockers.

Maintainer review of:

• fix(setup): validate current OpenClaw package lifecycle #999
• feat: update Companion-owned Gateway safely in place #1049

clarified the product boundary:

• OpenClaw Core owns the cross-platform managed-Gateway update, repair, backup,
  recovery, retention, and rollback contracts.
• Windows Companion should remain a thin integration: prove ownership of the
  managed Gateway, select a reviewed official Core target, invoke Core's
  supported update or repair path under WSL, then verify Gateway identity,
  health, and Windows Node reconnection.
• Windows Companion must not create a parallel package lifecycle, backup
  catalog, VHD recovery model, retention policy, or rollback authority.

Fresh reconciliation against current source confirms that Core main already
provides the shared foundation:

• Gateway update.run and update.status;
• a managed-service handoff that runs openclaw update --yes --json outside
  the live Gateway process;
• openclaw update repair;
• package version and post-restart health verification;
• openclaw backup create --verify and verified SQLite snapshot commands; and
• explicit code rollback and offline state-restore guidance.

Core intentionally does not make broad state restore, automatic package
rollback, backup retention, or VHD recovery implicit. Those remain explicit
operator or future Core product decisions, not Windows Companion contracts.

The investigation exposed real Windows setup issues and contributed evidence
that helped drive these merged Core fixes:

• fix(gateway): hosted setup exits no longer stop the gateway openclaw#115671
• fix(gateway): prevent overlapping setup after wizard cancellation openclaw#115856

Existing work

• fix(setup): validate current OpenClaw package lifecycle #999 remains valuable
  investigation, but the contributor-fork package-composition path will stop.
  The potentially reusable Windows work is limited to exact reload-mode
  preservation and the terminal-wizard disconnect investigation. Each requires
  a fresh fail-before/pass-after proof against current main and official Core
  artifacts. Existing pairing endpoint provenance checks must be preserved.
• feat: update Companion-owned Gateway safely in place #1049 remains valuable
  investigation, but its Windows-owned package, backup, VHD, retention,
  recovery, rollback, coordinator, and transaction design will not continue.
  Only thin UI, target-selection, invocation, health, and reconnection behavior
  may be reused behind an accepted Core-owned contract.
• Keep the local WSL OpenClawGateway version in lock-step with the Windows Tray app #901 continues to
  record the user-facing alignment/update problem, but its proposed
  implementation must be reconciled with the Core-owned lifecycle boundary.

Reconciliation before replacement PRs

Each change from the investigation branches will be classified as:

1. already resolved upstream;
2. a narrow Windows integration fix using an existing official Core contract;
3. a missing shared Core contract that requires owner/maintainer alignment;
4. reusable reproduction, test, or proof evidence; or
5. rejected or superseded design.

Replacement PRs will be opened only for category 2. Category 3 stays in
issue/design discussion until Core provides or accepts the required contract.
Categories 4 and 5 remain linked here so the investigation history and
contributor credit are preserved without carrying rejected architecture
forward.

Proposed next sequence

1. Treat the Core-owned lifecycle and thin-integration boundary as confirmed;
   do not reopen the rejected Windows-owned designs.
2. Extract reload-mode preservation as one small Windows setup PR only if
   current main still reproduces the bug with official Core artifacts.
3. Resolve the terminal-wizard disconnect semantics in Core before extracting a
   Windows workaround.
4. Design the thin Companion adapter using existing ownership, health, and
   reconnect paths only after that category-2 scope is separately accepted.
5. Link extracted work here, preserve contributor credit, and then close the
   investigation branches without presenting them as release candidates.
   Current refs for this reconciliation:

• OpenClaw Core main: c63fdc631f0
• Windows Node main: 9acafa606a4d863f1f62058364bb2f64625a8cca
• official npm stable: 2026.7.1-2
• official npm beta: 2026.7.2-beta.5

This is a contributor execution plan derived from maintainer feedback. It is
not a claim that any replacement item is an approved roadmap commitment or
release blocker.