macOS
作者： Jakub Rusinowski · 最后更新： 2026年9月1日
AI 教育者、本地 LLM 部署工作坊讲师
"LM Studio" is damaged and can't be opened. You should move it to the Bin.
"llama-cli" cannot be opened because the developer cannot be verified.
Apple could not verify "Jan" is free of malware that may harm your Mac or compromise your privacy.| 如果你看到 | 原因是 | 前往 |
|---|---|---|
| "cannot be opened because the developer cannot be verified" | Signed but not notarised — the mildest case | Fix 2: right-click → Open |
| "is damaged and can't be opened. You should move it to the Bin." | Unsigned and quarantined; the wording is misleading, the file is usually intact | Fix 3: Open Anyway, then Fix 4 if that fails |
| A CLI binary from a release archive dies with "killed" | Quarantine applied to the extracted file | Fix 4: remove the attribute from that path only |
| A Python package fails on a bundled .dylib | The wheel's bundled library carries the quarantine attribute | Fix 4, scoped to the package directory |
| You cannot verify where the download came from | You should not be bypassing Gatekeeper for it at all | Fix 1: verify first, or do not run it |
The word "damaged" is doing a lot of misleading work here. In almost every case the download is complete and intact — macOS is telling you it cannot establish who made it, and has chosen the most alarming phrasing available to say so.
Anything a browser downloads gets an extended attribute, com.apple.quarantine, recording that it came from the internet. When you launch it, Gatekeeper checks that the code is signed by an identified developer and notarised — scanned and stamped by Apple. Most open-source AI tooling is neither: notarisation requires a paid developer account and a release step that small projects often skip. Gatekeeper cannot verify the code, and reports that as "damaged", which is misleading because the file is usually perfectly intact. The same attribute is why an extracted CLI binary is killed on launch and why a Python wheel's bundled .dylib can fail at import — quarantine applies to files, not just to .app bundles.
Do this first, every time. Download only from the project's official domain or its GitHub releases page. Compare the SHA-256 against the published checksum where the project publishes one. Check the signature with codesign — it tells you whether the binary is signed at all and by whom, and spctl tells you what Gatekeeper's own assessment is. An unsigned build from the project's own release page is a normal state of affairs; an unsigned build from a link someone posted is not.
⚠️ Everything below removes or bypasses a macOS safety check. That is reasonable for a binary you have verified and reckless for one you have not. If you cannot establish where the file came from, the correct action is to delete it.
# zsh
shasum -a 256 ~/Downloads/LMStudio.dmg
# Is it signed, and by whom?
codesign -dv --verbose=4 /Applications/LM\ Studio.app 2>&1 | head -12
# What does Gatekeeper itself say?
spctl --assess --type execute --verbose /Applications/LM\ Studio.appcodesign names a signer you recognise — or the project is openly unsigned and you fetched it from its own release page.For an app that is merely unverified rather than "damaged", right-click (or Control-click) the app in Finder and choose Open, then confirm in the dialog. This creates a one-off exception for that specific app and changes no system setting. Double-clicking will not offer the exception; the context menu is what does it. That difference is the whole trick and it is not discoverable.
spctl --assess --type execute --verbose /Applications/LM\ Studio.appIf the right-click route does not offer an Open option, try to launch it once so macOS records the block, then go to System Settings → Privacy & Security, scroll to the Security section, and click Open Anyway next to the message naming your app. The button appears only after a blocked attempt, which is why people who go looking for it first do not find it.
When the first two do not work — commonly for CLI binaries and .dylib files rather than .app bundles — remove the attribute directly. Scope it as tightly as you can: name the single file where you can, and the specific app or package directory otherwise. Check first with xattr -l that quarantine is actually the attribute present, so you know this is the right tool.
⚠️ xattr -dr com.apple.quarantine strips the OS safety check from everything under the path you give it. Never run it against your Downloads folder, your home directory, or /Applications as a whole — only against the one app or file you have verified.
# zsh — what attributes does the file actually carry?
xattr -l /Applications/Jan.app
# Remove quarantine from ONE verified app
xattr -dr com.apple.quarantine /Applications/Jan.app
# A single CLI binary from a release archive
xattr -d com.apple.quarantine ./llama-clixattr -l no longer lists com.apple.quarantine for that path, and the binary runs.xattr -l /Applications/Jan.app; ./llama-cli --versionInstalling through brew install --cask avoids the majority of these prompts, because Homebrew fetches the file itself rather than a browser and handles quarantine as part of the install. It also gives you a maintained upgrade path, which matters for fast-moving projects where you would otherwise re-download and re-bypass every few weeks. This is the better default for anything Homebrew packages.
# zsh
brew install --cask lm-studio
brew install ollama
# Keep them current without repeating the whole dance
brew upgrade --caskbrew list --cask | grep -i studioA Python package can install cleanly and then fail at import because a bundled .dylib inside the wheel is quarantined — the error mentions the library rather than anything about security, so the connection is not obvious. Find the quarantined files under the package directory and clear those specific ones. If a package repeatedly needs this, prefer a wheel built for your architecture from the project's own index, which usually does not.
# zsh — find quarantined libraries inside a virtualenv
find .venv -name "*.dylib" -exec xattr -l {} ; -print 2>/dev/null | grep -B1 quarantine
# Clear them for that package only
xattr -dr com.apple.quarantine .venv/lib/python3.12/site-packages/<package>xattr -l on the library reports no quarantine attribute.python3 -c "import <package>; print('ok')"If the app opens and then fails for a different reason, the next questions are whether your Mac meets its requirements at all — several tools now require Apple Silicon — and whether the model you are loading fits your memory.
上报问题时请附上这些信息
codesign -dv --verbose=4 and spctl --assess --verbose on the appxattr -l on the fileAlmost never. macOS says "damaged" when Gatekeeper cannot verify the code signature or notarisation of a quarantined file. The bytes are usually intact — the app is simply unsigned, which most small open-source projects are.
Because the context-menu Open path offers a one-time exception for that specific app, while a double-click just enforces the block. It changes no system setting and is the narrowest of the fixes, which is why it is the one to try first.
It is safe for a binary you have verified and dangerous as a habit, because it strips the OS check from everything under the path you give it. Scope it to a single app or file. Never run it against Downloads, your home directory, or all of /Applications.
Because quarantine applies to files, not only to .app bundles. A wheel containing a bundled .dylib downloaded through a browser carries the attribute, and the import fails with an error about the library rather than about security, which hides the cause.
Largely, yes: install through Homebrew where the project is packaged. Homebrew fetches the file itself rather than a browser and handles quarantine during installation, and it gives you an upgrade path so you are not repeating the bypass on every release.