packages/coding-agent: prepare Gatekeeper-clean macOS releases for official Homebrew submission

[fettpl]

Summary

The runtime blocker from #754 appears fixed, but the official Homebrew path is still blocked by macOS distribution/signing state.

As of April 24, 2026, the latest macOS arm64 release binary from v14.2.1 now runs successfully with --version, so the earlier exit 137 problem is gone.

However, the macOS asset still does not appear to be Gatekeeper-clean enough for an official Homebrew submission.

Current state

What now works:

curl -fL https://github.com/can1357/oh-my-pi/releases/download/v14.2.1/omp-darwin-arm64 -o /tmp/omp-darwin-arm64
chmod +x /tmp/omp-darwin-arm64
TMP_HOME=$(mktemp -d)
HOME="$TMP_HOME" /tmp/omp-darwin-arm64 --version

Observed:

omp/14.2.1

What still looks wrong for distribution quality:

spctl -a -t exec -vv /tmp/omp-darwin-arm64

Observed on this machine:

internal error in Code Signing subsystem

codesign -dv --verbose=4 on the same binary reports an ad-hoc signature rather than a normal Developer ID distribution signature.

Why this matters for Homebrew

Homebrew policy still makes this relevant even though the binary now launches:

• homebrew/cask rejects software that fails with Gatekeeper enabled on Apple Silicon Macs.
• Open-source CLI-only software should still try homebrew/core first.
• But even if homebrew/core ends up being rejected for source-build/distribution reasons, the fallback homebrew-cask route still needs macOS assets that are clean under Gatekeeper.

So the next real blocker is no longer runtime correctness. It is release signing/notarization quality.

What upstream likely needs to do

1. Use a real Apple Developer distribution identity

   • obtain or use a Developer ID Application certificate
   • if a .pkg installer is used, also use a Developer ID Installer certificate

2. Sign the shipped macOS artifacts properly

   • sign omp-darwin-arm64 and omp-darwin-x64 with Developer ID
   • include hardened runtime
   • include secure timestamps
   • if sidecar .node files remain part of the macOS release story, sign those too

3. Ship a notarization-friendly macOS deliverable

   • ideally a .pkg
   • otherwise a .zip or .dmg
   • a raw standalone executable is awkward here because stapling is not available for standalone binaries

4. Notarize the macOS deliverable

   • submit with xcrun notarytool submit ... --wait
   • staple when the format supports it (.pkg, .dmg, .app)

5. Add release validation in CI

   • verify signature with codesign --verify --strict --verbose=4
   • verify Gatekeeper assessment with spctl -a -t exec -vv or spctl -a -t install -vv depending on artifact type
   • verify actual launch on a clean runtime home with --version

Suggested acceptance criteria

• The latest macOS arm64 release artifact passes codesign --verify --strict --verbose=4.
• The latest macOS arm64 release artifact has a clean spctl assessment on Apple Silicon.
• A clean download of the shipped macOS artifact runs omp --version successfully.
• The release workflow documents or automates signing + notarization.
• We can make a credible official Homebrew attempt afterward.

Maintainer feedback wanted

The remaining work looks like Apple Developer signing/notarization setup rather than application logic. Are you open to adding Developer ID signing + notarization to the macOS release workflow so the project can move forward with an official Homebrew submission?

References

• Apple: Notarizing macOS software before distribution
• Apple: Customizing the notarization workflow
• Apple: Signing your apps for Gatekeeper / Developer ID
• Homebrew: Acceptable Casks
• Homebrew: Acceptable Formulae

[fettpl]

@can1357 maintainer feedback would help here.

The runtime failure from #754 looks resolved in v14.2.1, but the next Homebrew blocker appears to be Developer ID signing / notarization / Gatekeeper cleanliness for the macOS assets. If you're open to that release-workflow work, I can help break it down further into concrete CI steps.

[can1357]

For the immediate Homebrew work, I think the better path is a source-built formula. This is an open-source CLI, and I don't really wanna purchase a Developer ID just to get it through there.

I removed nightly rust usage in my latest few commits so this should be pretty easy now I believe, perhaps something like:

class Omp < Formula
  desc "AI coding agent CLI with multi-model support"
  homepage "https://github.com/can1357/oh-my-pi"
  url "https://github.com/can1357/oh-my-pi/archive/refs/tags/vNEXT.tar.gz"
  sha256 "0000000000000000000000000000000000000000000000000000000000000000"
  license "MIT"
  head "https://github.com/can1357/oh-my-pi.git", branch: "main"

  depends_on "rust" => :build
  depends_on "zig" => :build
  depends_on "oven-sh/bun/bun" // blocker for homebrew/core

  def install
    ENV["CI"] = "1"
    ENV["PUPPETEER_SKIP_DOWNLOAD"] = "1"
    ENV["PUPPETEER_SKIP_CHROMIUM_DOWNLOAD"] = "1"
    ENV["PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD"] = "1"
    ENV["BUN_INSTALL_CACHE_DIR"] = buildpath/".bun-cache"
    ENV["CARGO_TARGET_DIR"] = buildpath/"target"

    if Hardware::CPU.intel?
      ENV["TARGET_VARIANT"] = "baseline"
      ENV["RUSTFLAGS"] = "-C target-cpu=x86-64-v2"
    end

    system "bun", "install", "--frozen-lockfile"
    system "bun", "--cwd=packages/natives", "run", "build"
    system "bun", "--cwd=packages/stats", "run", "build"

    prebuild_os = OS.mac? ? "darwin" : "linux"
    prebuild_arch = Hardware::CPU.arm? ? "arm64" : "x64"
    host_prebuild = "#{prebuild_os}-#{prebuild_arch}"
    Dir["node_modules/**/prebuilds/*", "node_modules/.bun/**/prebuilds/*"].uniq.each do |prebuild|
      rm_r prebuild if File.directory?(prebuild) && File.basename(prebuild) != host_prebuild
    end

    libexec.install "bun.lock", "package.json", "node_modules", "packages"

    (bin/"omp").write <<~EOS
      #!/bin/bash
      exec "#{Formula["oven-sh/bun/bun"].opt_bin}/bun" "#{libexec}/packages/coding-agent/src/cli.ts" "$@"
    EOS
    chmod 0755, bin/"omp"
  end

  test do
    assert_match "omp/#{version}", shell_output("#{bin}/omp --version")
    assert_match "USAGE", shell_output("#{bin}/omp --help")
  end
end

[fettpl]

@can1357 I checked the source-built route against current main locally on macOS arm64, and the basic build path looks much better now: bun install --frozen-lockfile, bun --cwd=packages/natives run build, bun --cwd=packages/stats run build, and bun packages/coding-agent/src/cli.ts --version / --help all passed.

The remaining blockers for an official homebrew/core attempt seem to be:

• depends_on "oven-sh/bun/bun" is still a homebrew/core blocker, since core formulae cannot rely on another tap for dependencies.
• rust-toolchain.toml on main still pins nightly-2026-03-27, so the stable-Rust story does not look fully settled yet.
• We still need confidence beyond macOS arm64, especially Intel macOS and x86_64 Linux, because homebrew/core will build/test there too.

If you are open to it, could you help on the upstream side with one or both of these?

1. Clarify the Bun plan for a core-compatible formula, i.e. whether you see a path that avoids a tap dependency at build/runtime.
2. Either remove the nightly pin or confirm in CI that the formula path builds cleanly with stable Rust on the Homebrew target platforms.

If those are resolved, the source-formula route looks like the right official path.