[macOS 27] --restart-service removes working registration, then SMAppService re-registration fails code-sign validation

[TyceHerrman]

Describe the bug

With skhd.zig v0.2.0 installed through the Homebrew cask, --restart-service removed an existing working com.jackielii.skhd registration but failed to register the bundled LaunchAgent again.

Subsequent --start-service / --install-service attempts fail with:

SMAppService.register failed:
Codesigning failure loading plist: com.jackielii.skhd.plist
code: -2147409622

The machine is then left without a registered or running service. Before the restart, the daemon was running and hotkeys worked.

To reproduce

1. Install jackielii/tap/skhd-zig through Homebrew.

2. Have an existing com.jackielii.skhd service registration.

3. Run:

   /Applications/skhd.app/Contents/MacOS/skhd --restart-service

4. Registration fails with the code-signing error above.

5. Running --start-service again produces the same failure.

I have not reproduced this with a clean macOS user account; this occurred while reconciling an existing registration.

Current status

Service installed:    No
Registration status:  bundled plist not found
Daemon running:       No (LaunchAgent not loaded)

The bundled plist is present and valid:

$ plutil -lint /Applications/skhd.app/Contents/Library/LaunchAgents/com.jackielii.skhd.plist
/Applications/skhd.app/Contents/Library/LaunchAgents/com.jackielii.skhd.plist: OK

The unmodified Homebrew app does not pass strict signature verification:

$ codesign --verify --deep --strict --verbose=4 /Applications/skhd.app
/Applications/skhd.app: CSSMERR_TP_NOT_TRUSTED
In architecture: arm64

Relevant signature details:

Identifier=com.jackielii.skhd
Authority=(unavailable)
TeamIdentifier=not set

Gatekeeper assessment also reports:

/Applications/skhd.app: internal error in Code Signing subsystem

Expected behavior

--restart-service should either successfully restore the registration or preserve the existing working registration when re-registration fails.

Is the Homebrew-distributed app expected to register through SMAppService without users locally re-signing it? If local self-signing is required, could that requirement be automated or documented for Homebrew installations and upgrades?

I saw that PR #42 explicitly accepted the lack of Developer ID signing/notarization. Developer ID signing may be one long-term solution, but I am primarily reporting the failure of the currently documented service flow rather than requesting a particular implementation.

Related:

• Accessibility permission fails on macOS 26 because skhd-zig signed as „adhoc“ without Info.plist #15
• grabber: harden vhidd recovery + switch tap to cask #42

Environment

• macOS 27.0 beta, build 26A5388g
• Apple Silicon
• Homebrew cask: skhd-zig 0.2.0
• skhd.zig: v0.2.0-7e95d99 (fast)
• No skhd-grabber, .remap, or .taphold configuration

[jackielii]

hmm, the same thing worked in macos26 just fine. ok, could you try

zig build install-local -Doptimize=ReleaseFast
skhd --start-service

This will replace the /Applications/skhd.zpp with your local dev cert (auto created).

From what I see, the proper solution is to get a $99 apple dev account, which I'm not willing to spend at this point. Let me know if there are other workarounds you see.

oh, use zig 0.16 to build

[TyceHerrman]

Tested commit e4770df on macOS 27 with Zig 0.16.0, using the exact requested flow.

PATH="/Users/tyceherrman/.local/share/mise/installs/zig/0.16.0/bin:$PATH" \
  zig build install-local -Doptimize=ReleaseFast
skhd --start-service

install-local first exited 1 during automatic certificate creation. openssl resolved to stock /usr/bin/openssl (LibreSSL 3.3.6), whose pkcs12 command rejects the helper's -legacy option. After manually creating the documented skhd-cert identity in the login Keychain, the identical command exited 0. The installed v0.2.1-dev-e4770df (fast) bundle passed strict/deep signature verification. This manual self-signed certificate worked and didn't require a paid Developer ID, but the automatic path needs a LibreSSL-compatible fallback or OpenSSL detection.

skhd --start-service exited 0 and reported Service registered with macOS / Status: enabled, but launchd had no PID, last exit 78: EX_CONFIG, and needs LWCR update. Re-adding Accessibility and Input Monitoring didn't clear that state; logout/login did.

After login, --status reported an active event tap and granted Input Monitoring, but physical Command-Space still didn't do anything. Direct F19 synthesis and synthetic Command-Space worked, isolating the failure to physical-event delivery. Resetting ListenEvent, re-adding /Applications/skhd.app under Input Monitoring, and relaunching the daemon restored physical hotkeys. Thus --status didn't prove physical-event delivery during this certificate transition.

Finally:

$ skhd --restart-service
Service restarted (registration preserved).
exit=0

PID changed 4684 -> 28186, runs increased 2 -> 3, and the BTM UUID remained 25FD3649-3E3C-4587-8E63-35CCA9A461A6. The daemon stayed healthy with no exit failure or needs LWCR update, and physical Command-Space continued to work.

So the exact install/start flow wasn't command-only success on this machine, but the issue #53 restart regression passed once the one-time signing/TCC/LWCR transition was complete.