Start / Poradniki / Rozwiązywanie problemów / Apple

„App is damaged and can't be opened” — Gatekeeper na macOS

macOS

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 1 września 2026

Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM

Komunikat błędu

"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.

Który to przypadek?

Jeśli widziszPrzyczyną jestPrzejdź do
„cannot be opened because the developer cannot be verified”Podpisany, ale nienotaryzowany — najłagodniejszy przypadekRozwiązanie 2: kliknij prawym przyciskiem → Otwórz
„is damaged and can't be opened. You should move it to the Bin.”Niepodpisany i w kwarantannie; treść komunikatu myli, plik zwykle jest nienaruszonyRozwiązanie 3: Otwórz mimo to, a jeśli nie pomoże — rozwiązanie 4
Plik CLI z archiwum wydania kończy się komunikatem „killed”Kwarantanna nałożona na wypakowany plikRozwiązanie 4: usuń atrybut wyłącznie z tej ścieżki
Pakiet Pythona wywraca się na dołączonym pliku .dylibBiblioteka dołączona do wheela niesie atrybut kwarantannyRozwiązanie 4, zawężone do katalogu pakietu
Nie potrafisz ustalić, skąd pochodzi pobrany plikW takim razie w ogóle nie powinieneś obchodzić dla niego GatekeeperaRozwiązanie 1: najpierw zweryfikuj albo nie uruchamiaj

Kiedy się pojawia

Słowo „damaged” wykonuje tu sporo mylącej roboty. W niemal każdym przypadku pobrany plik jest kompletny i nienaruszony — macOS mówi ci, że nie potrafi ustalić, kto go zrobił, i wybrał do tego najbardziej alarmujące sformułowanie, jakie miał pod ręką.

Co się właściwie dzieje

Wszystko, co pobierze przeglądarka, dostaje rozszerzony atrybut com.apple.quarantine, odnotowujący, że plik przyszedł z internetu. Przy uruchomieniu Gatekeeper sprawdza, czy kod jest podpisany przez zidentyfikowanego dewelopera i notaryzowany — czyli przeskanowany i ostemplowany przez Apple. Większość otwartych narzędzi AI nie jest ani jednym, ani drugim: notaryzacja wymaga płatnego konta deweloperskiego i osobnego kroku w wydaniu, który małe projekty często pomijają. Gatekeeper nie potrafi zweryfikować kodu i zgłasza to jako „uszkodzony”, co wprowadza w błąd, bo plik zwykle jest zupełnie w porządku. Ten sam atrybut sprawia, że wypakowany plik CLI zostaje ubity przy starcie i że dołączony do wheela pythonowego plik .dylib potrafi wywrócić import — kwarantanna dotyczy plików, a nie tylko pakietów .app.

Jak to naprawić

1. Zweryfikuj pobrany plik, zanim cokolwiek obejdziesz

Rób to najpierw, za każdym razem. Pobieraj wyłącznie z oficjalnej domeny projektu albo z jego strony wydań na GitHubie. Porównaj sumę SHA-256 z opublikowaną sumą kontrolną tam, gdzie projekt taką udostępnia. Sprawdź podpis poleceniem codesign — powie ci, czy plik jest w ogóle podpisany i przez kogo, a spctl poda własną ocenę Gatekeepera. Niepodpisane wydanie ze strony wydań samego projektu to normalny stan rzeczy; niepodpisane wydanie z linku, który ktoś wkleił, już nie.

⚠️ Wszystko poniżej usuwa albo obchodzi zabezpieczenie macOS. Jest to rozsądne przy pliku, który zweryfikowałeś, i lekkomyślne przy takim, którego nie zweryfikowałeś. Jeśli nie potrafisz ustalić pochodzenia pliku, właściwym działaniem jest go usunąć.

zsh
# 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.app
Czy zadziałało? Skrót zgadza się z opublikowaną sumą kontrolną, a codesign nazywa rozpoznawalnego sygnatariusza — albo projekt jest jawnie niepodpisany, a plik pobrałeś z jego własnej strony wydań.

2. Kliknij prawym przyciskiem → Otwórz — najwęższe działające rozwiązanie

Dla aplikacji, która jest jedynie niezweryfikowana, a nie „uszkodzona”, kliknij ją w Finderze prawym przyciskiem (albo z Control) i wybierz Otwórz, a potem potwierdź w oknie dialogowym. Tworzy to jednorazowy wyjątek dla tej konkretnej aplikacji i nie zmienia żadnego ustawienia systemu. Podwójne kliknięcie tego wyjątku nie zaproponuje; robi to menu kontekstowe. Na tej różnicy polega cała sztuczka i nie sposób jej odkryć samemu.

Czy zadziałało? Aplikacja się uruchamia, a kolejne uruchomienia działają już normalnie po podwójnym kliknięciu.
spctl --assess --type execute --verbose /Applications/LM\ Studio.app

3. Użyj „Otwórz mimo to” w Ustawieniach systemowych

Jeśli droga przez prawy przycisk nie proponuje opcji Otwórz, spróbuj uruchomić aplikację raz, żeby macOS odnotował blokadę, a potem wejdź w Ustawienia systemowe → Prywatność i ochrona, przewiń do sekcji Ochrona i kliknij Otwórz mimo to obok komunikatu z nazwą twojej aplikacji. Przycisk pojawia się dopiero po zablokowanej próbie — dlatego ci, którzy szukają go najpierw, go nie znajdują.

Czy zadziałało? Aplikacja się otwiera, a wpis znika z Prywatności i ochrony jako załatwiony.

4. Usuń atrybut kwarantanny — wyłącznie dla zweryfikowanego pliku

Kiedy dwa pierwsze sposoby nie działają — najczęściej przy plikach CLI i .dylib, a nie przy pakietach .app — usuń atrybut wprost. Zawęź to najbardziej, jak potrafisz: tam, gdzie się da, wskaż pojedynczy plik, a poza tym konkretny katalog aplikacji albo pakietu. Najpierw sprawdź poleceniem xattr -l, czy kwarantanna faktycznie jest obecnym atrybutem, żeby wiedzieć, że sięgasz po właściwe narzędzie.

⚠️ xattr -dr com.apple.quarantine zdejmuje systemowe zabezpieczenie ze wszystkiego pod podaną ścieżką. Nigdy nie uruchamiaj tego na folderze Pobrane, na katalogu domowym ani na całym /Applications — wyłącznie na jednej zweryfikowanej aplikacji lub jednym pliku.

zsh
# 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-cli
Czy zadziałało? xattr -l nie wypisuje już com.apple.quarantine dla tej ścieżki, a plik binarny się uruchamia.
xattr -l /Applications/Jan.app; ./llama-cli --version

5. Wybieraj cask-i Homebrew, które omijają większość tego Najczęstsze rozwiązanie

Instalacja przez brew install --cask oszczędza większość tych monitów, bo Homebrew pobiera plik samodzielnie, a nie przeglądarką, i obsługuje kwarantannę w ramach instalacji. Daje też utrzymywaną ścieżkę aktualizacji, co ma znaczenie przy szybko zmieniających się projektach, gdzie inaczej pobierałbyś i obchodził blokadę co kilka tygodni. To lepszy domyślny wybór dla wszystkiego, co Homebrew pakuje.

zsh
# zsh
brew install --cask lm-studio
brew install ollama

# Keep them current without repeating the whole dance
brew upgrade --cask
Czy zadziałało? Aplikacja uruchamia się prosto z /Applications, bez żadnego monitu Gatekeepera.
brew list --cask | grep -i studio
Sprawdź, co zmieści się na twoim sprzęcie — wybierz model dopasowany do twojego Maca, gdy aplikacja już się otworzy
Otwórz kalkulator VRAM →

6. Zajmij się przypadkiem Pythona i plików dylib

Pakiet Pythona potrafi zainstalować się czysto, a potem wywrócić przy imporcie, bo dołączony w wheelu plik .dylib jest w kwarantannie — komunikat błędu wspomina bibliotekę, a nie cokolwiek związanego z bezpieczeństwem, więc związek nie jest oczywisty. Znajdź pliki w kwarantannie w katalogu pakietu i wyczyść właśnie te. Jeśli któryś pakiet wymaga tego regularnie, wybierz wheel zbudowany dla twojej architektury z własnego indeksu projektu — takie zwykle tego nie wymagają.

zsh
# 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>
Czy zadziałało? Import przechodzi, a xattr -l na bibliotece nie zgłasza atrybutu kwarantanny.
python3 -c "import <package>; print('ok')"

Jeśli nic z tego nie pomogło

Jeśli aplikacja się otwiera, a potem zawodzi z innego powodu, kolejne pytania brzmią: czy twój Mac w ogóle spełnia jej wymagania — kilka narzędzi wymaga dziś Apple Silicon — i czy ładowany model mieści się w twojej pamięci.

Dołącz to, zgłaszając problem

Powiązane

Model, który mieści się na większości zestawów:
Zobacz model i wymagania →

Najczęstsze pytania

Czy mój pobrany plik naprawdę jest uszkodzony?

Prawie nigdy. macOS mówi „uszkodzony”, gdy Gatekeeper nie potrafi zweryfikować podpisu kodu ani notaryzacji pliku w kwarantannie. Bajty zwykle są nienaruszone — aplikacja jest po prostu niepodpisana, a taka jest większość małych projektów open-source.

Dlaczego kliknięcie prawym i wybranie Otwórz działa, a podwójne kliknięcie nie?

Bo ścieżka Otwórz z menu kontekstowego proponuje jednorazowy wyjątek dla tej konkretnej aplikacji, podczas gdy podwójne kliknięcie po prostu egzekwuje blokadę. Nie zmienia to żadnego ustawienia systemu i jest najwęższym z rozwiązań — dlatego warto zacząć właśnie od niego.

Czy xattr -dr com.apple.quarantine jest bezpieczne?

Jest bezpieczne dla pliku, który zweryfikowałeś, i niebezpieczne jako nawyk, bo zdejmuje systemową kontrolę ze wszystkiego pod podaną ścieżką. Zawęź je do jednej aplikacji albo jednego pliku. Nigdy nie uruchamiaj go na Pobranych, katalogu domowym ani całym /Applications.

Dlaczego trafia na to pakiet Pythona?

Bo kwarantanna dotyczy plików, a nie tylko pakietów .app. Wheel zawierający dołączony plik .dylib pobrany przez przeglądarkę niesie ten atrybut, a import wywraca się z komunikatem o bibliotece, a nie o bezpieczeństwie — co ukrywa przyczynę.

Da się tego uniknąć w całości?

W dużej mierze tak: instaluj przez Homebrew tam, gdzie projekt jest spakowany. Homebrew pobiera plik samodzielnie, a nie przeglądarką, i obsługuje kwarantannę w trakcie instalacji, a przy okazji daje ścieżkę aktualizacji, więc nie powtarzasz obejścia przy każdym wydaniu.