Skip to content

No known way to clear a quarantine-wedged path #28

Description

@drycode

Split out of #25, which is closed — the cause and the fix are settled, this is the one part that is not.

What is known

A bundle carrying com.apple.quarantine blocks in _dyld_start when exec'd directly. That first blocked launch then wedges the path, not the file. Verified 2026-08-06 on macOS 26.6 (25G72), Apple Silicon, against the published v0.1.1 artifact:

action on the wedged path result
xattr -dr com.apple.quarantine still rc=124
rm -rf + fresh unquarantined copy at the same path still rc=124
lsregister -u still rc=124
identical bytes at a sibling path (/Applications/TacetProbe3.app) runs, rc=2

So the only known recovery is to install somewhere else, which is what install-server.sh now tells the user (install-server.sh:546).

Why it still matters

The cask strips quarantine in postflight from 0.1.2, so new installs should not reach this. But anyone who hit it on 0.1.1 has a permanently wedged /Applications/Tacet.app and no documented way back other than a different path. If /Applications is where they want it, we have no answer.

Worth trying

  • Reboot (untested — the isolation session never rebooted)
  • sudo spctl --reset-default / other syspolicyd cache resets
  • Inspecting what syspolicyd actually keys on: log show --predicate 'process == "syspolicyd"' during a wedged launch. A first attempt at this returned nothing, but the predicate was probably wrong rather than the events absent.

Low priority — no known user is affected.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions