chore(release): prepare Gateway MSIX v2026.9.4-msix.1

[RomneyDa]

Summary

• prepare a packaging-only rebuild of the approved OpenClaw Gateway v2026.9.4 payload
• increment the MSIX revision to publish v2026.9.4-msix.1
• include the session-containment changes now merged on packaging main through improve: stage session dependencies for local development builds #54

Validation

• git diff --check
• Windows release/versioning tests run in repository CI

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 17, 2026, 5:50 PM ET / 21:50 UTC.

ClawSweeper review

What this changes

Increment the Windows package revision to prepare v2026.9.4-msix.1 using the approved Gateway payload and packaging changes already on main.

Merge readiness

✅ Ready for maintainer review

This release preparation remains necessary: current main and the latest published release still use revision 0. The revision bump follows the existing release contract, with no introduced correctness defect found.

Priority: P3
Reviewed head: 53fda94e26d40a718dce1aff3863b83951f82e63

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused release-policy update that follows the existing contract and has no identified patch defect.
Proof confidence	🌊 off-meta tidepool	Not applicable: This MEMBER-authored revision-only PR is exempt from contributor runtime proof; the existing Windows workflow selects candidate install-and-upgrade validation, whose completion is not claimed here.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This MEMBER-authored revision-only PR is exempt from contributor runtime proof; the existing Windows workflow selects candidate install-and-upgrade validation, whose completion is not claimed here.
Evidence reviewed	7 items	Exact introduced change: The pinned base-to-head diff changes only msixRevision from 0 to 1; the Gateway tag, approved commit, payload version, and publisher remain unchanged. The read-only whitespace check passed. Supported rebuild identity: The documented packaging-only rebuild convention increments the revision for the same Gateway tag. The existing calculation maps this input to package version 2026.9.4.1001 and release tag v2026.9.4-msix.1; existing tests cover revision increments and release ordering. Current main still requires the bump: The fetched main policy contains msixRevision 0. A live GitHub main lookup returned the same pinned main SHA.
Findings	None	None.
Security	None	None.

How this fits together

The Windows packaging pipeline reads release-policy.json to derive package versions and release tags. It composes architecture-specific packages and a bundle, validates signing inputs, and publishes through the protected official release workflow.

flowchart LR
  A[Approved Gateway payload] --> C[Windows packaging pipeline]
  B[Gateway tag and package revision] --> D[Release identity calculation]
  D --> C
  C --> E[Packages and bundle]
  E --> F[Install and upgrade validation]
  E --> G[Protected signing and publication]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

None.

Technical review

Best possible solution:

Use the existing deterministic revision mechanism and protected release pipeline to publish the updated packaging with the unchanged approved Gateway payload.

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

Not applicable: this is release preparation, not a bug report; source inspection establishes the resulting package identity.

Is this the best way to solve the issue?

Yes: changing only the revision is the documented, narrow path for repackaging the same approved Gateway release.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against e8c1e7de54b3.

Labels

Label changes:

• add P3: This is a routine one-value release preparation using an established versioning mechanism.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This MEMBER-authored revision-only PR is exempt from contributor runtime proof; the existing Windows workflow selects candidate install-and-upgrade validation, whose completion is not claimed here.

Label justifications:

• P3: This is a routine one-value release preparation using an established versioning mechanism.
• 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 MEMBER-authored revision-only PR is exempt from contributor runtime proof; the existing Windows workflow selects candidate install-and-upgrade validation, whose completion is not claimed here.

Evidence

What I checked:

• Exact introduced change: The pinned base-to-head diff changes only msixRevision from 0 to 1; the Gateway tag, approved commit, payload version, and publisher remain unchanged. The read-only whitespace check passed. (release-policy.json:4, 53fda94e26d4)
• Supported rebuild identity: The documented packaging-only rebuild convention increments the revision for the same Gateway tag. The existing calculation maps this input to package version 2026.9.4.1001 and release tag v2026.9.4-msix.1; existing tests cover revision increments and release ordering. (scripts/Get-MSIXReleaseIdentity.ps1:55, e8c1e7de54b3)
• Current main still requires the bump: The fetched main policy contains msixRevision 0. A live GitHub main lookup returned the same pinned main SHA. (release-policy.json:4, e8c1e7de54b3)
• Latest published release: GitHub reports v2026.9.4-msix.0 as the latest non-prerelease, published at 2026-09-17T07:13:11Z from 685ee93. (685ee93b7ebb)
• Existing upgrade and signing safeguards: Changes to release-policy.json select the versioning lane, which builds the candidate with its derived release identity and runs installed-package upgrades from four pinned standalone/bundle baselines plus fresh installs. Official signing remains restricted to a main-branch manual dispatch and the protected release-signing environment. These are existing CI gates; this review did not execute Windows tests. (.github/workflows/gateway-msix.yml:610, e8c1e7de54b3)
• Merged packaging context: The supplied GitHub context verifies improve: stage session dependencies for local development builds #54 merged at the pinned main SHA. Its discussion records integrated live x64 session evidence and signed-package fresh-install and upgrade validation. That work supplies the packaging changes for this release; it did not increment the release revision. (e8c1e7de54b3)

Likely related people:

• Dallin Romney: Raw commit 685ee93 adds scripts/Get-MSIXReleaseIdentity.ps1:55 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 685ee93b7ebb; files: scripts/Get-MSIXReleaseIdentity.ps1)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

• 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.