Cask-installed bundle hangs at _dyld_start when run from /Applications

[drycode]

The v0.1.1 cask installs correctly — signed, notarized, stapled, spctl accepts it — but the binary never executes a single line of its own code when run from /Applications. It blocks in the dynamic loader.

Reproduced on macOS 25.5.0 (Darwin), Apple Silicon, 2026-08-05.

Symptom

$ timeout 8 /Applications/Tacet.app/Contents/MacOS/tacet
$ echo $?
124        # timed out; expected 2, after printing "usage: tacet <serve|agent>"

main.swift cannot hang there — with no arguments it writes usage to stderr and exit(2) before touching AppKit. A sample of the hung process confirms it never gets that far:

Call graph:
    1597 Thread_163286913: Main Thread   DispatchQueue_<multiple>
      1597 _dyld_start  (in dyld) + 0  [0x10273c9c0]

The whole stack is _dyld_start. Same result for tacet serve under launchd: state = running, never binds its port, nothing in the log.

The bundle is fine — it is the path

The identical bundle, ditto'd elsewhere, runs instantly:

location	result
/Applications/Tacet.app	hangs, rc=124
/tmp/tt/Tacet.app (ditto of the above)	usage: tacet <serve|agent>, rc=2
~/Applications/Tacet.app (same copy)	usage: tacet <serve|agent>, rc=2

Same bytes, same xattrs (com.apple.macl, com.apple.provenance on both), same signature.

Ruled out, each by test

• Signature / notarization. spctl -a -vvv → accepted / source=Notarized Developer ID. stapler validate passes. And the same bytes run elsewhere.
• Quarantine. Homebrew applies com.apple.quarantine to casks by default. Removing it with xattr -dr did not change the hang.
• Online Gatekeeper check. A copy runs fine, and the ticket is stapled, so no network is needed.
• Contention from KeepAlive respawns. Hung instances pile up because launchd restarts them. Booting the service out entirely and killing every process still reproduced it.

Why this matters

tacet is never double-clicked — launchd starts it. A first-launch consent dialog, if that is what this is, has nobody to click it, so the app deadlocks instead of failing. Whatever the cause, an app that hangs in dyld gives an operator nothing: no log line, no exit code, no error.

It also makes the installers' verification step hang forever. install-server.sh runs the installed binary to prove it works:

usage_out="$("$APP_DST/Contents/MacOS/tacet" 2>&1 || true)"

With no timeout, that blocked for 10+ minutes before being killed by hand. That check needs a timeout regardless of what causes the hang — it is the difference between a diagnosable failure and a wedged install.

Not yet tried

• Replacing /Applications/Tacet.app with a freshly written copy (new inode) to see whether the path or the specific file is at fault.
• Whether this reproduces on a machine other than the author's. CI installs and uninstalls the cask but never executes it, so it provides no evidence either way.

Impact

The cask (drycodeworks/tap) should not be recommended until this is understood. Installing from source to ~/Applications is unaffected and works.

[drycode]

Root cause: the quarantine xattr, not the path

Reproduced and isolated on macOS 26.6 (25G72), Apple Silicon, 2026-08-06, against the published v0.1.1 Tacet.zip.

/Applications was never the variable. A quarantined bundle hangs identically in ~/Applications. The "same bytes run elsewhere" observation held only because those copies were never quarantined — ditto from a source without the xattr produces a copy without it.

What actually happens

1. The Homebrew cask stages Tacet.app with com.apple.quarantine (casks quarantine by default).
2. tacet is only ever exec'd directly — by launchd, and by install-server.sh's verification step. It never goes through LaunchServices.
3. Direct-exec'ing a quarantined bundle blocks in _dyld_start waiting on a first-launch consent decision that has no UI to answer it. Notarization and stapling are irrelevant here: the gate is consent, not assessment. spctl -a -vvv says accepted / Notarized Developer ID on the exact bundle that hangs.
4. That first blocked launch wedges the path, not the file. The wedge survives removing the xattr, survives rm -rf plus a fresh copy at the same path, and survives lsregister -u. A sibling path in the same directory with identical bytes runs instantly.

Evidence

bundle	path	quarantine	result
v0.1.1	scratchpad	no	usage:, rc=2
v0.1.1	/Applications/Tacet.app	no	usage:, rc=2
v0.1.1	~/Applications/TacetV011.app	no	usage:, rc=2
same copy as row 2	/Applications/Tacet.app	set	rc=124, whole stack _dyld_start
v0.1.1	~/Applications/TacetQ.app	set	rc=124
same copy	/Applications/Tacet.app	xattr -dr'd	rc=124
fresh copy, no xattr	/Applications/Tacet.app	no	rc=124
fresh unzip	scratchpad	no	usage:, rc=2
fresh copy, no xattr	/Applications/TacetProbe3.app	no	usage:, rc=2

Rows 5 and 9 are the two that settle it: quarantine hangs the app outside /Applications, and /Applications runs it fine at an unwedged path.

The hung stack matches the original report exactly:

Call graph:
    1591 Thread_1976761: Main Thread   DispatchQueue_<multiple>
      1591 _dyld_start  (in dyld) + 0  [0x1046089c0]

For contrast, a healthy run of a post-3aac02a build (no arguments now starts the agent) samples as a full AppKit stack through main.swift:53 → NSApplication.run() → __CFRunLoopServiceMachPort. If you sample a "hung" tacet and see AppKit frames, it is a running agent, not this bug.

Fix

Strip quarantine in the cask, before anything can exec the binary:

postflight do
  system_command "/usr/bin/xattr",
                 args: ["-dr", "com.apple.quarantine", "#{appdir}/Tacet.app"]
end

postflight runs after staging and long before launchd or install-server.sh touch the binary, so the first exec is never a quarantined one. This is the right layer: the app is inherently headless, so there is no launch path that could ever present the consent dialog.

Independently, install-server.sh's verification still needs a bounded timeout so a wedge fails diagnosably instead of blocking for 10+ minutes.

Still open

What clears an already-wedged path, short of installing to a different one. xattr -dr, file replacement, and lsregister -u all fail to. A reboot is untested. Anyone already affected can be unblocked today by removing /Applications/Tacet.app and installing to a fresh path.

[drycode]

Fixed in DRYCodeWorks/homebrew-tap#6, shipped alongside v0.1.2. The cask now strips com.apple.quarantine in postflight, before launchd or install-server.sh can exec the binary.

Leaving one thing on record rather than reopening later: what clears an already-wedged path is still unknown. xattr -dr, replacing the file, and lsregister -u all fail to; only installing to a different path works. Anyone who hit this on v0.1.1 should rm -rf /Applications/Tacet.app before reinstalling.