Fix macOS release: remove invalid stapling of bare CLI binary

[Copilot]

xcrun stapler (Error 73) does not support stapling notarization tickets onto raw Mach-O executables — only .app, .pkg, and .dmg containers. Notarization was succeeding; only the staple step was broken, causing every Apple-target release job to fail.

Changes

• .github/workflows/release.yml — remove the xcrun stapler staple call from the macOS notarization step

The binary remains code-signed (Developer ID + hardened runtime) and notarized. Gatekeeper verifies notarization online without a stapled ticket, so there is no regression in user trust experience. Stapling would only matter for offline verification, which is not a requirement here.

The tar.gz artifact name and format are unchanged, so the Zed extension requires no updates.

Original prompt

Create a pull request in AJenbo/phpantom_lsp to fix the macOS release workflow for Apple targets.

Background

The 0.8.0 release failed for Apple targets in the Release workflow. The workflow is in .github/workflows/release.yml.

Observed behavior from the failing release run:

• The binary is signed with codesign.
• A zip containing the binary is submitted for notarization with xcrun notarytool submit ... --wait.
• Notarization is accepted.
• The workflow then attempts to staple the notarization ticket onto the bare executable at target/${{ matrix.target }}/release/phpantom_lsp.
• The job fails at stapling with: The staple and validate action failed! Error 73.

Goal

Fix the workflow so macOS release builds succeed while keeping the distributed artifact usable by the Zed extension in this repository.

Constraints / decision guidance

• It is acceptable to skip stapling only if users will still avoid Gatekeeper/notarization warnings when installing/running the macOS release artifact.
• If skipping stapling would still lead to warnings or a degraded user experience, then change the distributed container/artifact format to a suitable notarization-friendly format and ensure the result is still compatible with the Zed extension in the repo.
• If the artifact/container format changes for macOS, update any related code or configuration in the repository that downloads, locates, or expects the release assets so the Zed extension continues to work.
• Prefer the smallest correct fix that preserves a good macOS user experience.

Required work

1. Inspect .github/workflows/release.yml and any repo code/config related to the Zed extension release asset format expectations.
2. Determine whether the minimal correct fix is:
   • removing the invalid stapling of the raw CLI binary while keeping existing artifacts, or
   • changing macOS packaging/notarization/stapling to a different distributable artifact format and updating consumers accordingly.
3. Implement the fix.
4. Ensure the workflow YAML stays valid and the change is narrowly scoped.

Acceptance criteria

• Apple target release jobs no longer fail due to stapling a standalone CLI binary.
• macOS users should not have a worse trust/notarization experience than necessary.
• If macOS artifact naming or format changes, the Zed extension in the repo is updated so it still works with released assets.
• The PR is narrowly scoped to this release workflow / asset compatibility fix.
• Include a concise explanation in the PR description of why the previous stapling step failed and how the new approach addresses it.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: The AJenbo/phpantom_lsp 0.8.0 release failed for apple targets, I think because it was unable to stable the binery, but how else should we sign the release?

Assistant: Yes — the failure looks like the stapling step, not the signing step.

From the failed Release run:

• Workflow run: Release #25859786920
• Workflow file: .github/workflows/release.yml
• Failing lines are the stapling step in release.yml lines 127–128

The key error in the logs is:

• The staple and validate action failed! Error 73.

Your workflow currently does:

1. codesign the raw binary
2. zip it only for notarization submission
3. notarize that zip
4. try to staple the notarization ticket onto the bare executable

That last part is the problem.

Why it failed

For macOS distribution, stapling a standalone CLI Mach-O binary is generally not the right target. stapler is meant for supported distributable containers like:

• .app
• .pkg
• .dmg

A raw Unix executable typically isn’t something you “staple” in the same way, even if notarization succeeds. That matches your failure: notarization was accepted, then stapling failed.

So how should you sign the release?

For a CLI tool like phpantom_lsp, the normal approach is:

Good baseline

• Sign the binary with Developer ID Application
• Submit for notarization
• Distribute the notarized archive
• Do not staple the bare binary

In other words, for your current tar.gz release artifacts, the practical fix is:

• keep codesign
• keep notarytool submit
• remove xcrun stapler staple target/.../phpantom_lsp

Recommended release strategy

Option A — simplest, likely best for this repo

For tar.gz CLI releases:

• sign the binary before archiving
• archive it
• notarize a zip/dmg/pkg if you choose to produce one
• if continuing to ship just tar.gz, you can still ship the signed binary, but stapling the raw binary is not needed

Option B — bes...

This pull request was created from Copilot chat.