OpenClaw Mac Release

Use with $release-openclaw-maintainer, $release-openclaw-ci, $one-password, and $release-private if it exists when stable macOS assets, release-ops mac preflight, notarization, appcast promotion, or mac release recovery is involved.

This is a regular stable-release skill. Do not invoke it for extended-stable; that track's GitHub Release carries shared validation evidence but does not inherit macOS assets or appcast promotion.

Release authorization

An explicit stable or full release request includes macOS publication unless the operator limits its scope. Continue through validation, signing, notarization, promotion, and verification without asking for separate macOS consent. Keep the exact release identity and all artifact checks. macOS publication runs in parallel with npm and never blocks it; a mac failure does not hold the npm/ClawHub release, GitHub release finalization, or main closeout. Fix it in parallel.

Follow the current owner-configured environment policy. Do not invent an extra reviewer requirement or recreate an obsolete one. If GitHub still enforces an approval, report the actual rule and resolve it through its owner; policy changes require explicit organization-owner direction and verified active admin membership. Never impersonate a reviewer, fabricate approval, or use another signing path to bypass an enforced rule.

Credentials

• Resolve Peter-owned ASC item refs, key ids, issuer ids, and service-token provenance from $release-private.
• Fields: private_key_p8, key_id, issuer_id.
• Stale/revoked key symptom: xcrun notarytool submit fails with HTTP status code: 401. Unauthenticated.
• Validate candidate ASC credentials with xcrun notarytool history before setting GitHub secrets.

1Password

• Use $one-password: all op work inside one persistent tmux session, no secret output.
• Use the service-token guidance from $release-private when available.
• If a service token fails, run status-only checks: token present/length and op whoami; never print token values.
• If desktop app auth is needed but Touch ID is unavailable, set OP_BIOMETRIC_UNLOCK_ENABLED=false for the manual op account add --signin path.

GitHub Secrets

Target release-ops repo environment: openclaw/releases, env mac-release.

Set only after local notary auth validation:

• APP_STORE_CONNECT_API_KEY_P8
• APP_STORE_CONNECT_KEY_ID
• APP_STORE_CONNECT_ISSUER_ID

Do not update these from mixed sources. All three ASC fields must come from the same 1Password item.

Workflow Shape

• openclaw/openclaw is the public product repo. Its GitHub Releases page is where macOS assets are ultimately attached.
• openclaw/openclaw macos-release.yml is public handoff validation only. It never signs, notarizes, or uploads macOS assets, regardless of preflight_only.
• openclaw/releases is the restricted release-ops repo. Its macOS workflows sign, notarize, validate, and promote assets onto the openclaw/openclaw GitHub release.
• Public release branch may carry mac-only packaging fixes after the stable tag/npm are already live.
• Use source_ref=release/YYYY.M.PATCH for release-ops mac preflight/validation when building that branch variation.
• Keep tag=vYYYY.M.PATCH pointing at the original stable release commit.
• Real mac publish must reuse:
  • a successful release-ops mac preflight run for the same tag/source SHA
  • a successful release-ops mac validation run for the same tag/source SHA
• Release-ops preflight and real publish use the mac-release environment for signing and promotion secrets and its main-only deployment policy. The authorized release operator continues under that environment's current rules.
• If preflight source SHA differs from tag SHA, validation must also use the same source_ref; promotion rejects mismatched proof.

Notarization

• OpenClaw uses scripts/notarize-mac-artifact.sh.
• xcrun notarytool submit should use --no-s3-acceleration; accelerated upload can surface misleading 401s even when notarytool history succeeds.
• If signing succeeds but notarization fails immediately with 401, check ASC key freshness first.
• If notarization stays in progress for several minutes after key-file write, that is normal Apple wait time; do not edit blindly.

Dispatch

The public handoff workflow validates the tag, source, build, and package metadata before publication. It does not require a GitHub release page because it does not upload assets. Keep this validation before the real publish workflow. The core publisher owns GitHub release finalization; macOS promotion attaches its verified assets to that release whether it is still a draft or already public, so it never waits for the npm flip.

Public handoff validation:

gh workflow run macos-release.yml --repo openclaw/openclaw \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=true \
  -f public_release_branch=release/YYYY.M.PATCH

• Use the public release branch as the workflow ref so the Actions list displays release/YYYY.M.PATCH, matching prior stable macOS handoff runs.
• Do not use --ref main or --ref vYYYY.M.PATCH for this public handoff validation. The workflow checks out the tag from the tag input internally.

Release-ops preflight:

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH \
  -f preflight_only=true \
  -f smoke_test_only=false \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

Follow the run through signing and notarization under the configured environment policy. Record the successful preflight run id; an approval pause is not a successful preflight.

Resume is the default. Re-dispatching the same preflight command after a failure (notary outage, DMG packaging, collector) resumes every variant from the newest checkpoint left by a failed or cancelled main dispatch for the same tag and source SHA; only variants without a checkpoint rebuild. The run log prints Resuming <variant> from run <id> attempt <n> or Building <variant>. ignore_checkpoints=true forces fresh builds. Pass resume_notarization_run_id, resume_notarization_run_attempt, and resume_notarization_variant only to pin one specific run, or for checkpoints made before the resume index existed (macos-resume-<tag>-<variant>-<sha> artifacts). Prefer gh run rerun <run-id> --failed --repo openclaw/releases when the failed job is still in the current run.

Release-ops validation for a branch-variation preflight:

gh workflow run openclaw-macos-validate.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH

Record the successful validation run id.

Real publish:

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=false \
  -f smoke_test_only=false \
  -f preflight_run_id=<successful-preflight-run> \
  -f validate_run_id=<successful-validation-run> \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

Follow promotion through asset upload and appcast publication under the same release authorization and current environment policy.

• Release-ops openclaw/releases publish/validate workflows run from their own trusted main workflow ref. Real publish has a guard that rejects any other workflow ref. That displayed main ref is expected; the public OpenClaw source is selected by tag and optional source_ref.

Verify

• gh release view vYYYY.M.PATCH --repo openclaw/openclaw shows zip, dmg, dSYM zip; once the npm publisher has flipped it: not draft, not prerelease.
• Public main appcast.xml points at OpenClaw-YYYY.M.PATCH.zip.
• Appcast entry has sparkle:version, sparkle:shortVersionString, length, and sparkle:edSignature.