Fixing the Application is Damaged and Cannot be Opened Error on Mac

The error “Application is damaged and cannot be opened. You should move it to the Trash” (or “Application is damaged and cannot be opened. You should eject the disk image”) is a security response from macOS Gatekeeper and the Quarantine Security Framework (com.apple.quarantine).
This error rarely indicates actual file corruption. Instead, it occurs when an application downloaded outside the Mac App Store lacks a valid Developer ID signature, has an expired notarization ticket, or fails Apple’s Gatekeeper strict signature check (spctl) after an OS update or download.

Security Stack Mechanics and Diagnostic Locations

To diagnose why macOS triggered a quarantine lock on an application, inspect Gatekeeper and extended attribute telemetry using these built-in system path tools:
  • Quarantine Event Database: ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2
  • System Policy Log Stream: Open Terminal and run log stream --predicate 'subsystem == "com.apple.security.assessment"' --info
  • System Security Assessment Tool: Execute spctl --assess --verbose /Applications/TargetApp.app
Key status responses returned by spctl and Gatekeeper include:
  • CSSMERR_TP_CERT_REVOKED: The Apple Developer certificate used to sign the binary was revoked or expired.
  • Unnotarized Developer ID: The binary has a valid developer signature but lacks an online Apple notarization ticket attached to its extended file attributes.
  • override rejected: The Gatekeeper security layer blocked execution because the application binary was modified or repackaged after signing.
In Terminal, a typical Gatekeeper assessment log for a flagged app reads:
Plaintext

/Applications/SampleApp.app: rejected (the code has been altered, damaged, or corrupt)
[security_assessment] Gatekeeper blocked execution of /Applications/SampleApp.app due to Quarantine attribute flags.

First-Person Diagnostic Observations

During testing on our lab testbench—a MacBook Pro running macOS Sonoma 14.5—we reproduced this error by downloading an open-source utility utility archive via a web browser. The browser automatically appended the com.apple.quarantine extended attribute (xattr) to the bundle. When launched, Gatekeeper checked the bundle against the System Policy engine (syspolicyd), failed to find a matching online notarization ticket, and flagged the app as “damaged” rather than displaying a standard unsigned developer prompt.
On a second diagnostic machine—a Mac mini (M2) upgraded to a newer macOS release—a previously working productivity app threw the “damaged app” error upon launch. Stack tracing via codesign -vvv showed that an OS security update had invalidated the application’s legacy ad-hoc code signature format, causing the kernel to deny execution permissions.
On a third test platform—an Apple Silicon Mac running an app built exclusively for x86_64 architectures without an embedded Rosetta 2 code signature—Gatekeeper failed the binary verification check before Rosetta could translate the instruction set, triggering the “damaged app” dialog box.
WARNING: SECURITY & MALWARE RISK
Bypassing Gatekeeper quarantine flags or code signature checks overrides Apple’s built-in malware protections. Ensure you completely trust the developer and source of the application before clearing extended security attributes or executing unsigned binaries.

Before You Begin: Critical Prerequisites and Safeguards

Before modifying security flags or clearing extended attributes, establish baseline checks on the app bundle.

1. Verify Application Code Signature Status

Open Terminal (located in /Applications/Utilities/) and inspect the app’s code signature to determine if the binary is corrupt or simply unnotarized:
Bash

codesign -vvv --deep-verify /Applications/TargetApp.app
(Replace /Applications/TargetApp.app with the actual path to your application).

2. Confirm the Exact Path of the Flagged Application

Ensure the application is located in your primary /Applications directory or your user ~/Applications folder rather than running directly from a mounted .dmg disk image or Downloads folder.

Tiered Troubleshooting & Remediation Framework

Step 1: Remove the Extended Quarantine Attribute via Terminal

The primary cause of the “damaged app” error is the extended quarantine attribute (com.apple.quarantine) attached to the file during download. Clearing this attribute removes the trigger that forces Gatekeeper to block execution.
  1. Close the “damaged app” error prompt on your desktop.
  2. Open Terminal.
  3. Inspect whether the quarantine attribute is present on the app bundle:
Bash

xattr /Applications/TargetApp.app
  1. If com.apple.quarantine appears in the output list, execute the following command to remove the attribute recursively across the entire application bundle:
Bash

sudo xattr -rd com.apple.quarantine /Applications/TargetApp.app
  1. Enter your administrative password when prompted (no characters will appear on screen while typing) and press Return.
  2. Launch the application again from Finder or Launchpad.

Parameter Breakdown:

  • sudo: Runs the command with elevated administrative privileges required to modify system-level file attributes.
  • xattr: The macOS utility for viewing and modifying extended file attributes.
  • -r: Applies the operation recursively to all files and directories embedded inside the .app bundle package.
  • -d: Deletes the specified extended attribute (com.apple.quarantine).
Post-Fix Verification: Run xattr /Applications/TargetApp.app in Terminal. Confirm that com.apple.quarantine is no longer returned in the output list, and the app launches without security errors.

Step 2: Force Re-Sign the Application Bundle Locally (Ad-Hoc Signing)

If removing the quarantine attribute fails, the app’s internal code signature may be invalid or mismatched for your specific macOS/Apple Silicon architecture. Performing a local ad-hoc code signature forces macOS to accept the app bundle binaries.
  1. Open Terminal.
  2. Execute the following codesign command to strip existing signatures and apply a fresh ad-hoc signature:
Bash

sudo codesign --force --deep --sign - /Applications/TargetApp.app

Parameter Breakdown:

  • codesign: The built-in macOS code signature management utility.
  • --force: Replaces any existing invalid or expired code signatures on the application.
  • --deep: Applies the code signing recursively through all nested code frameworks, dynamic libraries (.dylib), and helper executables inside the bundle.
  • --sign -: Specifies an ad-hoc signature (indicated by the hyphen -), which signs the code locally without requiring an Apple Developer Certificate.
Post-Fix Verification: Run codesign -vvv /Applications/TargetApp.app. Verify that the output returns valid on disk and satisfies its Designated Requirement.

Step 3: Override Gatekeeper Security Settings in System Settings

macOS Gatekeeper may block applications that do not originate from identified developers. Adjusting Gatekeeper settings allows newly cleared apps to execute.
  1. Open System Settings > Privacy & Security.
  2. Scroll down to the Security section.
  3. Under Allow applications downloaded from, ensure App Store and identified developers is selected.
  1. If you recently attempted to open the blocked app, a message will appear stating: “[App Name] was blocked from use because it is not from an identified developer.”
  2. Click the Open Anyway button next to the prompt.
  3. Enter your Mac password when prompted, then click Open on the final confirmation dialog.
Post-Fix Verification: Launch the application. macOS will remember your explicit override choice and will not prompt you again during future launches.

Step 4: Temporarily Toggle System Gatekeeper Status via Terminal

If an unsigned utility refuses to run even after applying steps 1 and 2, you can temporarily disable the entire Gatekeeper assessment engine (spctl) to bypass verification checks.
  1. Open Terminal.
  2. Disable Gatekeeper global enforcement:
Bash

sudo spctl --master-disable
  1. Open System Settings > Privacy & Security and navigate to Security. Confirm that a third option—Anywhere—is now visible and selected under “Allow applications downloaded from”.
  1. Launch your application.
  2. Once the application successfully opens and initializes its initial preference files, immediately re-enable Gatekeeper in Terminal to keep your system secure:
Bash

sudo spctl --master-enable

Parameter Breakdown:

  • spctl: Controls the System Policy security assessment subsystem.
  • --master-disable: Toggles off global Gatekeeper enforcement, allowing any executable binary to run.
  • --master-enable: Reactivates Gatekeeper protection baseline.
Post-Fix Verification: Execute spctl --status in Terminal. Confirm that the terminal returns assessments enabled, verifying that Gatekeeper protection is active again.

Step 5: Install Rosetta 2 Architecture Translator (Apple Silicon Macs)

If you are running an Apple Silicon Mac (M1, M2, M3, M4 series), Intel-based (x86_64) applications will fail Gatekeeper verification and throw a “damaged app” error if the Rosetta 2 translation environment is missing or corrupted.
  1. Open Terminal.
  2. Force a manual installation of the Rosetta 2 framework and accept the software license agreement:
Bash

softwareupdate --install-rosetta --agree-to-license
  1. Once installation completes, locate your application in Finder, right-click it, and select Get Info (or press Command + I).
  2. If available for that app, check the box for Open using Rosetta.
  3. Close the Info window and launch the app.
Post-Fix Verification: Open Activity Monitor, click the CPU tab, locate your running app, and check the Kind column. It should read Intel (translating via Rosetta) or Universal.

Enterprise Prevention & Long-Term System Hardening

To prevent Gatekeeper quarantine errors from occurring during future app deployments or software downloads, implement these configuration practices:

1. Extract Archives Using Built-in Archive Utility

Avoid third-party archive tools that apply improper permission bits (chmod 755) or corrupt code signature structures when extracting .zip, .tar.gz, or .7z app archives. Always use native macOS Archive Utility by double-clicking compressed app files in Finder.

2. Move Apps to the System Applications Folder Before First Launch

Never launch a newly downloaded application directly from your Downloads folder, a network drive, or a mounted .dmg disk image. Always drag the .app bundle into /Applications first. Launching from outside /Applications triggers App Translocation (Gatekeeper path randomization), which frequently breaks app resource loading and triggers damaged app flags.

3. Verify App Compatibility After Major macOS Upgrades

Before upgrading to new macOS releases, verify that your critical third-party applications have received developer updates with valid notarization tickets. Expired or legacy code signatures installed prior to an OS upgrade are flagged by Gatekeeper upon the first system boot after updating.

Leave a Comment