Best possible solution:

Have a release/workflow owner review the ClawHub upstream delta, add redacted real dry-run or publish proof, then merge the narrow pin update if the publisher behavior is verified.

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

Source-level yes, live no: current main points at the old ClawHub publisher SHA and the upstream target contains the detector fix, but no real workflow dry-run or publish dispatch was provided.

Is this the best way to solve the issue?

Yes for the OpenClaw code shape: updating the pinned reusable workflow SHA and its guard assertion is the narrow fix. It is not merge-ready until the upstream publisher delta is accepted and real dry-run proof is added or explicitly waived.

AGENTS.md: found and applied where relevant.

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

Label changes:

• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🧂 unranked krab, so this older rating label is no longer current.

Label justifications:

• P2: This is normal-priority release automation maintenance that affects plugin publishing but is not an immediate user-facing runtime outage.
• merge-risk: 🚨 automation: The diff changes the reusable workflow SHA used by plugin publishing, so merge affects release automation outside ordinary CI checks.
• merge-risk: 🚨 security-boundary: The called publisher workflow runs with id-token: write and executes ClawHub code from the new SHA, making the exact upstream pin a trust boundary.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body provides local checks only; it still needs a redacted workflow dry-run or publish log showing the new pinned publisher behavior before merge. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

PR surface:

Tests -3, Config 0. Total -3 across 2 files.

Security concerns:

• [medium] Review broad upstream publisher pin delta — .github/workflows/plugin-clawhub-release.yml:390
  The changed workflow line moves the ClawHub publisher to a SHA 346 upstream commits ahead of the old pin, and the called workflow runs with id-token: write; maintainers should accept that upstream code delta or request a narrower/proven pin before merge.
  Confidence: 0.86

What I checked:

• Current main still uses the older publisher pin: Current main calls openclaw/clawhub/.github/workflows/package-publish.yml@9d49df109d4ad3dc8a6ecf05d26b39f46d294721 from publish_plugins_clawhub. (.github/workflows/plugin-clawhub-release.yml:390, 82dfd8910743)
• PR changes the reusable workflow SHA: The PR diff changes only the ClawHub reusable workflow pin in the release workflow plus the matching acceptance-test string, from 9d49df... to 28409ee.... (.github/workflows/plugin-clawhub-release.yml:390, 887ba50631e0)
• Existing guard test watches the pin: The package acceptance workflow test reads the ClawHub release workflow and asserts the exact package-publish workflow pin alongside the dry-run and approval wiring. (test/scripts/package-acceptance-workflow.test.ts:2071, 82dfd8910743)
• Upstream fix exists at the target ClawHub merge commit: ClawHub PR fix(cli): prefer plugin manifests for code plugin detection clawhub#2931 is merged at 28409ee6ce9d088c9ddf0d6913cde6597f83f362; its detector now checks real bundle manifests first, then openclaw.plugin.json, then loose skills/ markers. (openclaw/clawhub:packages/clawhub/src/cli/commands/packages.ts:2137, 28409ee6ce9d)
• Upstream regression coverage matches the requested behavior: The upstream ClawHub test creates a package with both openclaw.plugin.json and skills/demo/SKILL.md and expects the publish payload family to be code-plugin. (openclaw/clawhub:packages/clawhub/src/cli/commands/packages.test.ts:2167, 28409ee6ce9d)
• Called workflow executes code from the reusable workflow SHA: At the target ClawHub SHA, the reusable workflow keeps id-token: write, resolves job_workflow_sha from OIDC claims, checks out that ClawHub source, and installs/runs the CLI from it. (openclaw/clawhub:.github/workflows/package-publish.yml:102, 28409ee6ce9d)

Likely related people:

• Patrick-Erichsen: Authored the upstream ClawHub package-family fix and prior merged OpenClaw ClawHub release workflow changes in the same workflow/test surface. (role: recent area contributor and upstream ClawHub fix author; confidence: high; commits: 28409ee6ce9d, 6cf06e8e7eb0, f05e9873c6d2; files: .github/workflows/plugin-clawhub-release.yml, test/scripts/package-acceptance-workflow.test.ts, openclaw/clawhub:packages/clawhub/src/cli/commands/packages.ts)
• onutc: Authored merged OpenClaw PR CI: add ClawHub plugin release workflow #59179, which added the ClawHub plugin release workflow and original publish automation surface. (role: introduced workflow; confidence: high; commits: fa9e1e3d8eb2; files: .github/workflows/plugin-clawhub-release.yml, scripts/plugin-clawhub-publish.sh, scripts/lib/plugin-clawhub-release.ts)
• vincentkoc: Recently changed the ClawHub release workflow behavior in commit f71ef47288739ef97e855f20e73ee79fc2ba2dbc, so he is a plausible release-workflow safety reviewer. (role: adjacent release workflow contributor; confidence: medium; commits: f71ef4728873, aa69b12d0086; files: .github/workflows/plugin-clawhub-release.yml, test/scripts/package-acceptance-workflow.test.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

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