fix(release): trust downloaded Dev MSIX certificates machine-wide

[RomneyDa]

Summary

• import downloaded Dev MSIX signer certificates into LocalMachine\\TrustedPeople, matching the proven build/export path and documented install path
• remove only certificates imported by the release job from that same store
• guard the release workflow against regressing to CurrentUser\\TrustedPeople

Follow-up to #1600. The first tagged releases exercising its new publication path, v2026.9.5-alpha.88 and .89, reached final staging and failed because Get-AuthenticodeSignature reported the downloaded self-signed package as untrusted. The package's embedded signer thumbprint exactly matches the published certificate; the release job imported that certificate into a different trust scope from the build path.

Required proof pools

• none: release-workflow trust validation only; no product runtime or UI behavior changes

Validation

• git diff --check: passed
• focused release workflow tests: in progress
• required Windows build, Shared tests, and Tray tests: in progress

Real behavior proof

Alpha release run 37013791671 reproduced the failure twice at Stage signed Dev MSIX release assets. Independent inspection confirmed the x64 package's embedded signer SHA-1 thumbprint and the published OpenClaw-Dev.cer thumbprint are both 6F6D57C5A3205FC1D9A09375A055B57D797F15F5, isolating the failure to trust-store scope rather than artifact substitution.

Current-head tagged release proof will be attached after merge because the publication job runs only for release tags.

[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 October 2, 2026, 10:12 AM ET / 14:12 UTC.

ClawSweeper review

What this changes

The PR imports downloaded development-signed Windows package certificates into machine-wide trust, cleans them up from the same store, and adds workflow regression assertions.

Merge readiness

✅ Ready for maintainer review

This remains a useful, narrow release fix: current main still imports the certificates into the mismatched user trust store. No introduced correctness or security defect was found.

Priority: P2
Reviewed head: 54930b4143288fe20abae05ef0da183d55691f4f

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused repair follows the existing trust contract and preserves validation and cleanup invariants.
Proof confidence	🌊 off-meta tidepool	Not applicable: This MEMBER-authored workflow repair is exempt from the external-contributor proof gate. The linked run proves the prior staging failure; current-head tagged-release success is explicitly deferred. No unresolved authority-chain violation was identified, and no product stored-data contract changes.
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 workflow repair is exempt from the external-contributor proof gate. The linked run proves the prior staging failure; current-head tagged-release success is explicitly deferred. No unresolved authority-chain violation was identified, and no product stored-data contract changes.
Evidence reviewed	7 items	Pinned introduced change: The exact base-to-head diff changes only the import and cleanup trust-store paths plus comments and two test assertions. Still necessary on main: The fetched main release job still imports into CurrentUser TrustedPeople and cleans up there; it does not contain this repair. Existing machine-trust contract: Certificate provisioning already imports the public development certificate into LocalMachine TrustedPeople, and exported installation instructions specify the same store. This concerns this repository's Companion package, not Gateway MSIX packaging.
Findings	None	None.
Security	None	None.

How this fits together

The release workflow downloads signed Windows packages from its build jobs, validates their provenance and signatures, and publishes release ZIPs. Temporary certificate trust enables Windows to validate the self-signed development packages.

flowchart LR
  A[Tagged release] --> B[Signed package build jobs]
  B --> C[Download packages and certificates]
  C --> D[Temporary machine trust]
  D --> E[Validate provenance and signatures]
  E --> F[Publish release ZIPs]
  E --> G[Remove imported certificates]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

None.

Technical review

Best possible solution:

Keep release validation aligned with the existing machine-trust contract while preserving exact signer checks and selective cleanup.

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

Yes: main's release job uses a different trust scope from the successful build path, and the linked Actions run confirms staging failure. The reviewer did not execute Windows signature validation.

Is this the best way to solve the issue?

Yes: changing both trust and cleanup to the existing machine-wide store is the narrowest repair and leaves publication checks intact.

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add P2: This repairs a demonstrated tagged-release staging failure with a narrowly scoped workflow change.
• 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 workflow repair is exempt from the external-contributor proof gate. The linked run proves the prior staging failure; current-head tagged-release success is explicitly deferred. No unresolved authority-chain violation was identified, and no product stored-data contract changes.

Label justifications:

• P2: This repairs a demonstrated tagged-release staging failure with a narrowly scoped workflow change.
• 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 workflow repair is exempt from the external-contributor proof gate. The linked run proves the prior staging failure; current-head tagged-release success is explicitly deferred. No unresolved authority-chain violation was identified, and no product stored-data contract changes.

Evidence

What I checked:

• Pinned introduced change: The exact base-to-head diff changes only the import and cleanup trust-store paths plus comments and two test assertions. (.github/workflows/ci.yml:1384, 54930b414328)
• Still necessary on main: The fetched main release job still imports into CurrentUser TrustedPeople and cleans up there; it does not contain this repair. (.github/workflows/ci.yml:1381, bb4ac510c6e4)
• Existing machine-trust contract: Certificate provisioning already imports the public development certificate into LocalMachine TrustedPeople, and exported installation instructions specify the same store. This concerns this repository's Companion package, not Gateway MSIX packaging. (scripts/setup-dev-msix-cert.ps1:141, 54930b414328)
• Authority and publication boundary: The tag-only release job uses a GitHub-hosted Windows runner and same-run artifact downloads. Staging retains source, allocation, architecture, hash, identity, and exact signer checks before producing ZIPs. Cleanup runs on failure and removes only recorded newly imported thumbprints; pre-existing certificates are retained. No new reachable unauthorized publication path was identified. (scripts/Stage-DevMsixReleaseAssets.ps1:103, 54930b414328)
• Observed release failure: The GitHub jobs endpoint confirms https://github.com/openclaw/openclaw-windows-node/actions/runs/37013791671 failed in the release job at Stage signed Dev MSIX release assets. The captured PR body reports matching package and certificate thumbprints; this is before-fix evidence, not observed after-fix success.
• Related merged work and routing: fix(release): publish signed MSIX downloads #1600 (fix(release): publish signed MSIX downloads) is merged and established the publication path this PR repairs. Recent main history records several related release contributions by Dallin Romney, and GitHub maps the merged commit author to RomneyDa. Older blame/follow inspection encountered unavailable promisor objects, so no source-line introduction attribution is asserted. (.github/workflows/ci.yml, 8d6da8a59a87)

Likely related people:

• RomneyDa: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.