docs: propose OpenClaw MSIX packaging for Windows - #58
Open
xlinush wants to merge 12 commits into
Open
Conversation
Add proposal for a dedicated openclaw-msix-packaging repository that builds a package-specific host app and pinned OpenClaw payload into a signed MSIX, with the host app provisioning a dedicated agent user and session-isolated Agent Session to run the Gateway. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b33c00-2350-43f2-b727-43d5bdb7d057
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3cd24431-d6fe-4603-b495-c289228b4ccb
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6aa7eb66-af4f-44cd-a5a8-fe80ae9d0057
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6aa7eb66-af4f-44cd-a5a8-fe80ae9d0057
Clarify installation, preferred update behavior, package identity, and future PFN management while removing rollback from scope. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7b5e8cf9-246d-4f16-83d0-3abd731a0813
Track whether packaged OpenClaw should prevent command- and prompt-driven native updates and what enterprise enforcement is possible. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7b5e8cf9-246d-4f16-83d0-3abd731a0813
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: c4e24ce6-c557-4073-909c-b2e7615bd870
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
Codex review: needs real behavior proof before merge. Reviewed August 11, 2026, 9:57 PM ET / August 12, 2026, 01:57 UTC. ClawSweeper reviewWhat this changesThe PR adds a 418-line RFC proposing a separately maintained, signed MSIX packaging repository and Windows host lifecycle for OpenClaw Gateway deployments. Merge readinessThis is a coherent draft RFC for a new Windows distribution path, not an already-implemented change. Keep it open for an explicit maintainer product and ownership decision; it should remain unmerged while its RFC status is draft. Priority: P3 Review scores
Verification
How this fits togetherThis repository records OpenClaw design decisions before implementation. The proposed packaging path would transform a pinned OpenClaw revision into a signed Windows MSIX whose host stages the payload and prepares Gateway onboarding and lifecycle. flowchart LR
A[OpenClaw revision] --> B[Packaging build]
B --> C[Signed MSIX artifact]
C --> D[Windows host app]
D --> E[Payload staging]
E --> F[Gateway onboarding and lifecycle]
Decision needed
Why: The proposal introduces new distribution, package identity, signing, and host-lifecycle policy that cannot be selected by an automated documentation review. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Have a sponsoring maintainer accept, narrow, or defer the MSIX direction, then create a bounded implementation issue that owns package identity, signing, upgrade, reset, uninstall, and Gateway-state handling. Do we have a high-confidence way to reproduce the issue? Not applicable: this docs-only RFC proposes future packaging behavior and contains no runnable implementation to reproduce. Is this the best way to solve the issue? Unclear: a dedicated packaging repository is a plausible design, but its product scope and lifecycle policy require maintainer approval before implementation. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning high; reviewed against af708f0ddb6f. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (39 earlier review cycles; latest 8 shown)
|
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: c4e24ce6-c557-4073-909c-b2e7615bd870
clawsweeper
Bot
added
rating: 🐚 platinum hermit
xlinush
marked this pull request as ready for review
August 4, 2026 21:03
clawsweeper
Bot
added
rating: 🐚 platinum hermit
|
@RomneyDa, this is the MSIX PR that I was chatting with you about. Thanks, Mythili |
clawsweeper
Bot
added
rating: 🦐 gold shrimp
clawsweeper
Bot
added
the
merge-risk: 🚨 compatibility
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d5132745-7693-44d9-a132-e5f7d9568cfc
MythiliMur
reviewed
Aug 6, 2026
| payload and manages the Gateway lifecycle. | ||
| - Publish signed MSIX artifacts under a stable OpenClaw-controlled identity, | ||
| with checksums and source-version metadata, through GitHub Releases. | ||
| - Make a supported way to disable OpenClaw Gateway self-updates a hard |
There was a problem hiding this comment.
For disable /update, my comment would to be "Disable or modify to update via MSIX instead of git clone"
DrusTheAxe
reviewed
Aug 6, 2026
| prompting the Gateway, for managed MSIX installations? | ||
| - If Microsoft Store distribution is introduced later, packages that are released | ||
| from GitHub and those from the Store will have different PFNs. How will side-by-side | ||
| installation be handled? |
There was a problem hiding this comment.
For pre-Store, can you get your certificate from Azure Artifact Services in a way that's compatible with Store?
The certificate's SUBJECT must match the package's Publisher (<Package...><Identity...Publisher="...publisher...">). Normally, Store defines this value for your account, and likewise defines the package's Name for your package (e.g. PFN=37849OpenClaw_r91mwp1sztvzy).
Will AAS issue a certificate with this SUBJECT? This sounds like the cert issuer 'Doing Business As' (DBA) scenario (ie. provide appropos paperwork and your SUBJECT doesn't have to be CN=OpenClaw...)
If you can get a cert from AAS with info per Store's definition then you could...
- Create a Store account
- Define the OpenClaw offering
- Copy the Store defined 'product identity' information into your appxmanifest.xml
- Create the .msix
- Sign the .msix with the AAS cert
and later, if/when you decide to start publishing to Store...
- Bump package version
- Build package
- Submit .msix to Store
- Once certified, download the Store signed package and post on GitHub for non-Store distribution
5+9 have same package identity
The only difference between 5 + 9 is the installed package's PackageOrigin = Store vs not.
DrusTheAxe
reviewed
Aug 6, 2026
DrusTheAxe
reviewed
Aug 6, 2026
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: a34648ae-920d-4b39-9726-00a1a63cfe9d
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
Define the unchanged Gateway protocol and pairing boundary, document app execution alias installation, and separate package removal from administrator-managed decommissioning and reset. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: f06e6164-8cba-4365-8596-3cc422dbd189
clawsweeper
Bot
added
status: 👀 ready for maintainer look
Author
|
Hi @RomneyDa, could you please take a look at this RFC when you have a chance? I’ve been working with Mythili on the proposal, and MSIX packaging is an important part of supporting enterprise OpenClaw scenarios on Windows. Any feedback would be greatly appreciated. The immediate need is a standalone repository under the OpenClaw organization where I can check in the initial scaffolding and set up the build pipeline. I believe only OpenClaw organization owners can create it, so I’d appreciate your help with that as well. Thank you! |
clawsweeper
Bot
added
rating: 🐚 platinum hermit
Member
|
@xlinush my only feedback is can this live in the openclaw/openclaw-windows-node repo? Seems closely attached and would like to avoid double permissions etc |
Author
@RomneyDa thanks so much for reviewing and for the feedback! We did discuss internally whether the packaging code should need a dedicated repository. We concluded that a separate repo offers the best balance as it avoids blurring the responsibilities of existing repositories while giving the packaging implementation a clear home. A few key considerations led us to this:
Here is a comparison of the other possible homes for the MSIX work:
Based on this, I think the right model is to keep the implementation in a new dedicated openclaw/openclaw-msix-packaging repo. If the additional repo overhead is considered too high, placing it in the Please let me know your thoughts 😄! |
This was referenced Aug 18, 2026
paulcam206
added a commit
to paulcam206/rfcs
that referenced
this pull request
Aug 19, 2026
The previous revision had OpenClaw core owning the seam that contains the Gateway, which contradicts the RFC's own threat model: if the Gateway is the component treated as compromised, a containment decision it makes is a decision the attacker makes. A check inside the process can be patched, configured away, or never reached, and by the time it would run the untrusted code is already executing with the identity the check was supposed to remove. The same applies to plugins, which load into the process being contained. The boundary is now established before the Gateway exists, by a small trusted launcher outside it: - The launcher owns the ContainmentProvider seam, provider selection, the fail-closed rule, and posture reporting. It probes, provisions, stages, and starts the Gateway inside the boundary. - The Gateway is unchanged and unaware. It has no uncontained mode to reach because it is never started outside the boundary, so phase 1 requires no change to OpenClaw core at all. - On Windows the launcher is the packaged host app already proposed in openclaw#58 rather than a new component: openclaw#58 defines it as the packaged entry point behind an openclaw.exe execution alias whose job is launching or stopping the packaged Gateway. - Adds bypass resistance. openclaw#58 already requires that native `openclaw gateway` commands cannot bypass staged-payload activation; the same requirement extends to containment. Because the Gateway cannot be trusted to refuse to start, this comes from the deployment shape rather than a check inside it. - The threat model now names the launcher as the trusted computing base, so anything added to it is added to the TCB, and package integrity becomes a dependency of this design. - Posture reported by the Gateway is explicitly not evidence, since a compromised Gateway can claim to be contained. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: ccc616c5-8e0a-4098-b8ef-c19695e5c27b
paulcam206
added a commit
to paulcam206/rfcs
that referenced
this pull request
Aug 19, 2026
Full rewrite. Same argument and same design, ~35% shorter: drops the repetition and hedging that accumulated across revisions, uses plainer language, and merges the migration, phasing, and rollback material into a single Rollout section instead of three. Adds crosslinks throughout to openclaw#58, #42026, openclaw#55, RFC 0025, the public microsoft/mxc backend docs, and the Windows Insider build that gates the primitive. Fixes two defects found while rewriting: a typo in the summary, and a capability named hostPathSharing in the Windows section that no longer matched the descriptor table after it was split into hostPathProjection and stagingChannel. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: ccc616c5-8e0a-4098-b8ef-c19695e5c27b
paulcam206
added a commit
to paulcam206/rfcs
that referenced
this pull request
Aug 19, 2026
Fixes several factual errors, verified against microsoft/mxc at 0aaa2afa (2026-08-18). The earlier draft was written against a clone that was eight days stale, and the preview API had changed underneath it. Corrections: - Lifecycle was wrong. The real phases are provision, start, exec, stop, deprovision. The draft omitted exec and invented an attach phase the provider explicitly defers. - "Every operation is idempotent" was false and dangerous: provision mints a fresh identity on every call, so a naive retry leaks accounts. Replaced with per-operation semantics and a durable pre-provision record. - Detached execution is deferred upstream and a spawned process stays tethered to its caller, so the launcher cannot exit. It is a long-lived supervisor, not a bootstrapper, and that cost is now stated. - The caller-supplied identity bundle was removed upstream. Dropped the workloadIdentity capability and the claim built on it; appId is now described as inert forward-compatibility metadata rather than a mechanical link to package identity. - PR openclaw#55 was mischaracterized. It also contains the long-lived Gateway, and brokers model credentials so neither Gateway nor worker holds provider values, which solves a residual risk this RFC cannot. Now positioned as complementary and the better answer where available, differing by deployment context rather than by scope. - openclaw#58 proposes a launcher, it does not already build one. #42026 would make the unit of containment a live question, not a drop-in swap. - AppContainer dismissal was too glib. It is MXC's default Windows backend; the real objection is that it is an allowlist over the same token, and its universally available tier enforces filesystem policy by mutating DACLs on host paths. - The downgrade requirement was impossible as written. An older launcher cannot be taught to reject config it never knew; this needs a minimum version enforced by packaging. - Fallback no longer contradicts fail-closed: it means another provider of equal or greater strength, never uncontained. Threat model restructured around the right baseline. Several residual risks are unchanged from an uncontained Gateway rather than regressions - shared-ACL reach, local IPC, egress, and persistence, which is now confined to a throwaway account instead of the user's profile. Separated from the risks containment actually shifts or introduces: the host-side state store, the staging channel, and the launcher. Added a TCB table covering the SDK, the SYSTEM service, and the kernel, and noted that a compromised Gateway commanding an authorized desktop node is not contained by this boundary. Also drops the claim that the Gateway is unaffected. It needs no containment code, but a new principal means a different profile, registry hive, and credential store, and whether the Docker and SSH sandbox backends survive that is now an explicit phase 2 question. All MXC citations pinned to a commit with a verification date, since a load-bearing claim went stale within a week. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: ccc616c5-8e0a-4098-b8ef-c19695e5c27b
Author
|
I'm currently working on this draft PR (openclaw/openclaw-windows-node#1186) to implement the packaging logic in openclaw-windows-node repo. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Problem This Solves
Enterprise administrators need a consistent way to identify, inventory,
approve, deploy, update, and remove OpenClaw on managed Windows devices.
Why This Change Was Made
This RFC proposes a dedicated OpenClaw MSIX packaging repository,
reproducible signed builds from pinned OpenClaw revisions, and a package-specific
host app that manages payload staging and the Gateway lifecycle. Runtime
isolation and Microsoft Store distribution remain outside the initial scope.
User Impact
This RFC has no immediate user-visible impact. If accepted and implemented,
Windows users and enterprise administrators would gain a stable, signed, and
manageable OpenClaw installation path.
Evidence
installation, onboarding, updates, repair, reset, and uninstall behavior.
main.