Download an app from outside the App Store, try to open it, and macOS interrupts with a prompt asking if you are sure. That prompt exists because of a single extended attribute, com.apple.quarantine, sitting on the file you just downloaded. It is not a virus scan, it is not macOS deciding the file is dangerous, and it was not even set by macOS itself in the way people often assume. It is a small piece of metadata written by whichever application handed the file to your Mac, and it exists purely to record that the file arrived from outside your machine. Understanding exactly what sets it, what reads it, and what removing it does and does not mean clears up a surprising amount of confusion about how Gatekeeper actually works.
Who actually sets the flag
The quarantine attribute is not applied by the operating system as a blanket policy on every new file. It is applied by the specific application responsible for bringing the file onto your Mac from an external source — your browser after a download completes, Mail after you save an attachment, Messages after you receive a file, an archive utility when it extracts a quarantined .zip. Each of these apps calls the same underlying mechanism to tag the file it just wrote, recording where it came from and roughly when. A file you create yourself in a text editor, or that already existed on your disk before any of this, never gets tagged this way, because nothing "brought it in" from outside.
This distinction matters: the quarantine flag is a statement about provenance — this file arrived from somewhere else — not a statement about content. Two files with identical bytes can differ only in whether one happens to carry this attribute, depending purely on how each one reached your disk.
What LaunchServices and Gatekeeper do with it
The first time you try to open a file carrying the quarantine attribute, LaunchServices checks for the flag before handing control to the app. If it is present, and the file being opened is executable (an app, a script, a disk image containing one), Gatekeeper's checks are invoked and macOS shows the familiar prompt asking you to confirm you want to proceed, sometimes alongside information about the file's developer if it is signed. Once you confirm, macOS does not re-prompt for that specific file on subsequent launches, because the quarantine attribute itself is typically cleared or updated as part of that first successful open.
This is the entire mechanism behind the "app can't be opened because it is from an unidentified developer" style of message and its calmer cousin, the plain "are you sure" dialog. Both are triggered by the same attribute, checked at the same moment: first launch.
It's metadata, not a scan result
It is worth being precise about what the flag is not. Setting com.apple.quarantine does not mean the file has been scanned by anything, and its presence or absence is not itself a verdict on whether a file is safe. It is closer to a customs stamp than an inspection report: it records that something crossed a boundary, and it triggers a checkpoint, but the checkpoint (Gatekeeper's own signature and notarization checks, run separately) is where any actual verification happens. A file with no quarantine attribute at all has not been "cleared" of anything; it simply never triggered that particular checkpoint, often because it was already present on the disk before you understood where it came from, or because whatever created it did not apply the flag.
Removing it deliberately
Because the flag is just an extended attribute, it can be removed the same way any extended attribute can, with the xattr command. To strip the quarantine flag recursively from a path — useful for something like an app bundle, where the flag may be set on multiple files inside it, not just the top-level .app:
xattr -dr com.apple.quarantine /path/to/SomeApp.app
This is something a user does knowingly, for a specific file or app they have already decided to trust — commonly after building something themselves, receiving a file through a channel that legitimately does not need re-verifying, or working around a case where a legitimately obtained file was flagged simply because of how it was transferred. It is not a blanket recommendation, and it is not a substitute for actually being confident about a file's origin. Running this command does not make a file any safer; it only stops macOS from asking about it. If you are not sure a file is trustworthy, removing its quarantine flag is the wrong response — not opening it at all is.
The -r flag matters specifically for anything that is really a folder pretending to be one item, like an app bundle. A single top-level xattr -d without the recursive flag would clear the attribute on the outer .app directory entry itself, while leaving it in place on the executable and resources nested inside, which is why the first-launch prompt can sometimes reappear even after you thought you had cleared it.
Why this occasionally causes confusion
Because the quarantine attribute is set per-application-that-downloaded-it rather than per-OS-policy, behaviour can look inconsistent across different download paths for what feels like the same file. A file transferred over one channel might carry the flag; the same bytes moved by a different route, one that does not apply the attribute, might not. Neither outcome is a bug — each app decides for itself whether and how to mark files it introduces to the disk, and not every transfer mechanism participates in the convention the same way.
Conclusion
The quarantine flag is a small, deliberate piece of bookkeeping — set by the app that brought a file in, read once at first launch, and otherwise invisible — and treating it as a scan result rather than a provenance marker is the most common misunderstanding about it.
Storage tools that walk your disk will encounter this attribute constantly without needing to act on it, and being straightforward about what it is and is not is part of the honesty we aim for with VolumeLens — a tool that reports what is actually on your disk rather than making claims about safety it has no basis for.