release: repair npm Trusted Publisher configuration

[steipete]

Problem

The npm Trusted Publisher configuration for openclaw/clawpatch is not authorizing releases from the repository's canonical release workflow.

The v0.7.2 release run checked out the signed release tag, passed release metadata verification, completed the frozen install, and passed the full validation gate. npm publish --access public --provenance then created and submitted valid Sigstore provenance, but the registry package PUT to https://registry.npmjs.org/clawpatch failed with E404 (package not found or no permission). The GitHub Release step was consequently skipped.

This matches the pattern of failed tag-triggered release runs since v0.6.0:

• v0.6.0
• v0.7.0
• v0.7.1
• v0.7.2

Version 0.7.2 was recovered by publishing the clean, fully validated tagged build with the maintainer npm service account. It cannot be republished to test the trusted path.

Admin action needed

Repair the npm-side Trusted Publisher settings for package clawpatch, GitHub repository openclaw/clawpatch, and workflow .github/workflows/release.yml (including any configured npm environment constraint). Verify the repaired trusted path on the next releasable version.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 3, 2026, 11:41 AM ET / 15:41 UTC.

Summary
Keep open: current main still uses the canonical OIDC-based npm publish path, but the reported authorization failure is in npm package administration and cannot be repaired or verified by a repository-only change. An authorized npm administrator needs to correct the Trusted Publisher tuple and validate it on the next releasable version.

Reproducibility: unclear. the reported v0.7.2 run supplies a concrete historical failure path, and current source confirms the same OIDC publish route, but npm authorization cannot be exercised from this read-only checkout and that version cannot be republished.

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 authorized npm administrator restore Trusted Publisher trust for exactly .github/workflows/release.yml in openclaw/clawpatch and validate it on the next releasable version?	Repair the exact publisher binding: Configure npm Trusted Publisher for the canonical repository and release workflow, preserving the intended npm environment restriction, then validate the next release.

Why: The needed change is an external package-publishing authorization boundary; source inspection can confirm the workflow identity but cannot safely choose or mutate npm registry trust settings.

Next step
This requires an authorized external npm administration change and a future release verification, so no repository repair PR is safe to queue.

Security
Needs attention: The issue concerns an external npm publishing authorization boundary; repair should restore only the exact canonical workflow identity rather than broaden publisher trust.

Review details

Best possible solution:

Have an authorized npm package administrator configure the clawpatch Trusted Publisher to the exact openclaw/clawpatch release workflow identity, retain any intended environment constraint, and verify one new tagged release completes npm publication and GitHub Release creation.

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

Unclear: the reported v0.7.2 run supplies a concrete historical failure path, and current source confirms the same OIDC publish route, but npm authorization cannot be exercised from this read-only checkout and that version cannot be republished.

Is this the best way to solve the issue?

Yes: correcting the npm-side Trusted Publisher binding is narrower and safer than changing the repository workflow, which already requests the required OIDC token and publishes with provenance.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Until npm-side Trusted Publisher authorization is corrected, future release tags can pass local validation yet fail at package publication and skip GitHub Release creation.
• Broadening npm publisher trust beyond the canonical repository, workflow, and any intended environment constraint would weaken the package publishing boundary.
• The repaired path cannot be proven by rerunning v0.7.2 because npm versions are immutable; verification requires a new release version or an npm-approved safe validation path.

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

Label changes

Label justifications:

• P1: The canonical release path is currently unable to publish validated package releases, affecting the project's ability to ship fixes.
• impact:security: Trusted Publisher settings define the authorization boundary for who may publish the npm package.
• impact:other: The immediate user-visible impact is blocked release operations and skipped GitHub Release publication, outside the more specific owned impact categories.

Evidence reviewed

Security concerns:

• [medium] Confirm the exact npm publisher binding
  Trusted Publisher settings determine who can publish clawpatch; an npm administrator should bind the canonical repository and .github/workflows/release.yml precisely, including any intended environment constraint.
  Confidence: 0.93

What I checked:

• Canonical publish path remains on current main: The release job grants id-token: write, installs an OIDC-capable npm version, and invokes npm publish --access public --provenance; this matches the intended Trusted Publisher path and leaves no repository-side fallback or alternate publisher configuration to repair. (.github/workflows/release.yml:21, a81435d851e1)
• Release workflow provenance: Blame attributes the current trusted-publishing setup at lines 62-89 to the v0.7.2 release commit, and that commit is the merged release preparation associated with the reported failed tag run. (.github/workflows/release.yml:87, 3c2a1a4e2d04)
• Shipped release context: The v0.7.2 release commit is contained by the v0.7.2 tag, while the current workflow at that tag already used the same OIDC publisher command; the issue's described failure therefore cannot be fixed by republishing that immutable version. (.github/workflows/release.yml:88, 3c2a1a4e2d04)
• Related release preparation: The merged release preparation at chore(release): v0.7.2 #176 validated the tagged package before the registry authorization step described in this issue; it is related release context, not a fix for npm-side publisher settings. (package.json:3, 3c2a1a4e2d04)
• Maturity classification unavailable: The required shortlist helper could not locate qa/maturity-scores.yaml in this checkout, so no maturity label is applied rather than inferring one.

Likely related people:

• steipete: The related v0.7.2 release preparation was merged under this contributor identity, and the current workflow blame attributes the trusted-publishing segment to Peter Steinberger's release commit. (role: recent release workflow contributor; confidence: high; commits: 3c2a1a4e2d04; files: .github/workflows/release.yml, package.json)

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.