v0.12.4 hasn't been released

[mkaput]

Hey! I don't know your workflow, but I'd love to get fixes landed in 0.12.4 and it appears it hasn't be released anywhere. Not sure if this is overlooking or not, but maybe this issue will be a good ping 🙃 Thx!

[steipete]

Thanks for the ping. v0.12.4 is tagged and prepared, but publication is currently blocked because the pinned signing key is on hardware that is offline. We expect to publish it when that host wakes up.

[clawsweeper]

🦞⚠️
Automatic implementation stopped before completion.
Reason: The automatic implementation worker stopped before all deterministic gates completed. Open the workflow run for the exact blocker.
Worker: https://github.com/openclaw/clawsweeper/actions/runs/30459944389

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 31, 2026, 8:53 AM ET / 12:53 UTC.

Summary
Keep this issue open: the release is prepared but the official latest release remains v0.12.3, and a collaborator confirmed on July 25, 2026 that publication is blocked by the offline host holding the pinned signing key. This is an active release-operations and trust-boundary task, not a source-tree repair. Likely related people: steipete (high confidence, provided the current release and signing context).

Reproducibility: not applicable. this is not a software behavior report. The supplied release state and collaborator confirmation establish that publication, rather than a failing runtime path, is the outstanding action.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Include the exact command, prompt, or workflow that triggered it.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should v0.12.4 wait for the pinned hardware signing key to return, or should a release owner approve a replacement trusted signing path for this publication?	Wait for the pinned signer: Publish the prepared release when the offline signing host is available again, preserving the existing release trust path.

Why: Choosing or replacing a signing path changes the release trust boundary and cannot be safely inferred from a source-tree review.

Next step
This requires release-owner action on signing hardware or trust policy; there is no safe autonomous source repair to queue.

Review details

Best possible solution:

Publish the existing prepared v0.12.4 artifact once the release owner can use the pinned signing key or has explicitly approved a replacement trusted signing path, then confirm the public release is installable.

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

Not applicable: this is not a software behavior report. The supplied release state and collaborator confirmation establish that publication, rather than a failing runtime path, is the outstanding action.

Is this the best way to solve the issue?

Yes: restoring the existing signing path or explicitly approving a trusted replacement is the narrowest safe solution. A repository code change would not publish the prepared release or safely bypass the signing boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Publication cannot proceed until the release owner restores access to the pinned signing hardware or explicitly approves another trusted signing path; changing repository code would not resolve that boundary safely.

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

Label changes

Label justifications:

• P2: The issue blocks a normal version publication but does not show a current security bypass, data loss, or unusable runtime.
• impact:other: This is a concrete release-publication operations problem outside the specialized impact categories.

Evidence reviewed

What I checked:

• Maintainer release status: A collaborator stated that v0.12.4 is tagged and prepared, but publication is blocked because the pinned signing key is on offline hardware.
• Current release baseline: The supplied repository state identifies v0.12.3 at f20febe as the latest public release, so the requested publication has not yet occurred. (f20febe322b6)
• Current branch context: The review context identifies current main as 7259c8c; no source-level fix can safely substitute for the required signing operation. (7259c8c2c9b0)

Likely related people:

• steipete: Provided the authoritative issue discussion describing the prepared v0.12.4 tag and the hardware-backed signing blocker. (role: release context contributor; confidence: high)

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.