[install] Name quarantine as the wedge cause, not /Applications - #27
Merged
Conversation
The message a user sees when the installed bundle never starts told them the wrong thing. It blamed "Gatekeeper assessment on a bundle in /Applications" and called ~/Applications "known-good", which is backwards: a quarantined bundle hangs in ~/Applications identically, and an unquarantined one runs fine in /Applications. The variable is the xattr, not the directory. Isolating #25 established that. Acting on the old advice also cost you the recovery. It sent people to reinstall elsewhere without saying that the first blocked launch wedges the path, so deleting the xattr or replacing the bundle in place looks like it should work and does not. The detail block bypasses err(), which prefixes every line with ERROR:. Fifteen of those is a wall, and this is read by someone already stuck. Solves: #25 follow-up — the diagnostic contradicted the isolation Tests: new assertion pins the message to com.apple.quarantine and a working recovery, and rejects the disproved advice returning; mutation-checked by restoring the old wording, which fails it
Contributor
Author
|
reopening to re-fire the pull_request event — CI did not trigger on open |
drycode
added a commit
that referenced
this pull request
Aug 7, 2026
Ships the corrected wedge diagnostic, and is the first release cut by the workflow rather than by hand. Solves: release vehicle for #27 Tests: release workflow asserts the tag matches this value before signing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The error a user sees when the installed bundle never starts was telling them the wrong thing.
Before
Both claims are wrong. Isolating #25 showed a quarantined bundle hangs in
~/Applicationsidentically, and an unquarantined one runs fine in/Applications. The variable iscom.apple.quarantine, not the directory.Worse, following the advice loses you the recovery: the first blocked launch wedges the path, so deleting the xattr or replacing the bundle in place looks like it should work and doesn't. The old message never mentioned that.
After
Names quarantine, gives the check (
xattr -p), says plainly that removing it does not recover the path, and gives a recovery that works. Also notes the cask strips quarantine from 0.1.2 on, so a currentbrew installshouldn't reach the message at all.The detail block bypasses
err()— it prefixes every line withERROR:, and fifteen of those is a wall for someone already stuck.Tests
New assertion pins the message to
com.apple.quarantineplus a working recovery, and fails if the disprovedknown-goodadvice returns. Mutation-checked: restoring the old wording fails it (AssertionErrorat line 89), restoring the fix passes. 112 tests pass, shellcheck clean.