remindctl ships arm64-only — "Bad CPU type in executable" on Intel Macs

[lolomaraboo]

On Intel (x86_64) Macs, installing remindctl via Homebrew (brew install steipete/tap/remindctl) produces a binary that fails at runtime with:

Bad CPU type in executable

The release artifact (remindctl-macos.zip, v0.3.1) is arm64-only — file $(which remindctl) reports Mach-O 64-bit executable arm64 on an Intel machine.

The source builds fine for x86_64. On an Intel Mac with Swift 6.1 (Command Line Tools), swift build -c release produces a working x86_64 binary. After an ad-hoc codesign --force --sign - --identifier com.steipete.remindctl, remindctl list and remindctl search … work correctly (the Info.plist is already embedded via the SwiftPM linker -sectcreate __info_plist, so Reminders permission prompts as expected).

Request: ship a universal binary in the releases (and Homebrew bottle) so both architectures work out of the box — e.g.

swift build -c release --arch arm64 --arch x86_64

(or build each arch separately and lipo -create -output remindctl <arm64> <x86_64>), then codesign/notarize as today.

Environment: macOS 15.7 (Sequoia), Intel Core i9, Homebrew, remindctl 0.3.1.

[clawsweeper]

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

Summary
Keep open: current main and the latest v0.3.1 release still publish the Homebrew-consumed macOS zip from a single default-architecture build, and the linked universal-artifact fix is an open, unmerged PR.

Reproducibility: no. high-confidence end-to-end reproduction was possible in this Linux review because it requires the shipped artifact on Intel macOS. The source-level release path is reproducible: current main and v0.3.1 build and zip one default-architecture binary, matching the reporter's Intel Mac failure evidence.

Root-cause cluster
Relationship: canonical
Canonical: #57
Summary: This issue is the canonical report for the Intel Mac arm64-only release artifact problem, and the open PR is the candidate fix.

Members:

• fixed_by_candidate: Build universal macOS release artifact #58 - The PR uses closing syntax for this issue and changes the macOS release artifact path to build and check a universal binary.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
No new repair lane is queued because #58 already owns the implementation candidate; maintainers should review, land, or replace that PR.

Review details

Best possible solution:

Land #58 or an equivalent shared universal packaging path, verify the generated zip reports both x86_64 and arm64, then ship a release and Homebrew tap update.

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

No high-confidence end-to-end reproduction was possible in this Linux review because it requires the shipped artifact on Intel macOS. The source-level release path is reproducible: current main and v0.3.1 build and zip one default-architecture binary, matching the reporter's Intel Mac failure evidence.

Is this the best way to solve the issue?

Yes: changing the release packaging to produce and verify a universal macOS artifact is the narrow maintainable fix. The linked PR appears to be the active implementation path, so this issue should stay open until that PR merges or is replaced.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• The issue should not close before Build universal macOS release artifact #58 merges or an equivalent fix lands, because current main still has the reported release packaging path.
• The open PR proof covers generated universal artifact inspection, but not physical Intel Mac execution or a notarized release upload.

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

Label changes

Label changes:

• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P2: The shipped CLI artifact blocks Intel Mac users from running the Homebrew-installed binary, but the fix is bounded to macOS release packaging.
• impact:other: The impact is binary distribution compatibility for macOS users, which is maintainer-visible but outside the specific data, message, session, auth, crash, and security labels.

Evidence reviewed

What I checked:

• Current main release packages one default-architecture binary: The tag release workflow runs swift build -c release --product remindctl, signs .build/release/remindctl, and zips that single output as remindctl-macos.zip without an architecture matrix or lipo step. (.github/workflows/release.yml:53, 4e8643ff0ed9)
• Universal helper exists outside the publishing path: Current main has dual-arch and lipo logic only in scripts/sign-and-notarize.sh; rg found no shared universal packaging/check script in the release workflow or Makefile. (scripts/sign-and-notarize.sh:33, 4e8643ff0ed9)
• Release docs confirm the workflow publishes the zip: The release guide says pushing v* tags runs .github/workflows/release.yml, builds remindctl-macos.zip, creates or updates the GitHub Release, and dispatches the Homebrew tap updater; it also says the notarization helper remains for local builds. (docs/RELEASING.md:18, 4e8643ff0ed9)
• Latest release provenance still matches the reported path: At tag v0.3.1, the release workflow uses the same single-build packaging lines, and GitHub release v0.3.1 publishes a single remindctl-macos.zip asset. (.github/workflows/release.yml:53, 04fbfd02e76f)
• Release history ties the packaging path to the v0.3.1 release-prep commit: git blame attributes the release build/package lines and the dual-arch notarization helper to 04fbfd02e76f6cb60c1db52a5ed85068895dcf0f, which git tag --contains shows is in v0.3.1. (.github/workflows/release.yml:53, 04fbfd02e76f)
• Open PR owns the candidate fix: Build universal macOS release artifact #58 is open, unmerged, mergeable, uses closing syntax for this issue, and its body reports after-fix macOS artifact checks showing both x86_64 and arm64 slices. (458c13cd3329)

Likely related people:

• Peter Steinberger: Current-main blame and file history attribute the release workflow packaging lines, release docs, and notarization helper to the v0.3.1 release-preparation commit. (role: release workflow author; confidence: high; commits: 04fbfd02e76f; files: .github/workflows/release.yml, scripts/sign-and-notarize.sh, docs/RELEASING.md)
• TurboTheTurtle: The open linked PR implements the universal macOS artifact path and provides macOS artifact proof for this issue. (role: candidate fix author; confidence: high; commits: 458c13cd3329; files: .github/workflows/release.yml, Makefile, scripts/build-macos-universal.sh)

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.

[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/27731230828