Clash Won’t Open on macOS: Fix “App Is Damaged” Warnings, Network Extension Permissions, and Keychain Prompts

First, identify the issue: launch blocking, network permissions, and Keychain access are separate problems

Clash clients for Mac typically include a graphical interface, a proxy core, and an optional background helper service. Some clients also use Network Extensions. An “app is damaged” warning appears during launch checks; Network Extension permissions control network routing; and Keychain prompts involve access to saved credentials. Each issue has a different fix—repeatedly entering your administrator password won’t resolve them all.

Before you start, note your macOS version, client name and version, core name, and the exact error message. The System Settings paths below refer to macOS 13, 14, and 15; labels may differ in other versions, so follow the options shown on your Mac. Don’t just write “Clash won’t open”—that doesn’t distinguish a blocked app from a core that fails to start.

Before installing, check your Mac’s chip and where the app is installed

Choose the right architecture before troubleshooting permissions

1. Open the Apple menu → About This Mac. If it lists an Apple M-series chip, choose an arm64 or aarch64 build. For an Intel processor, choose x64 or x86_64.
2. Apps labeled Universal usually include both architectures, but check the client’s minimum macOS requirement. System compatibility depends on the specific release, not on the name “Clash.”
3. Open the disk image, drag the app to Applications, eject the disk image, then launch the app from Applications. Don’t run it long-term from Downloads, an archive, or a mounted installer.
4. Quit other proxy clients to avoid multiple apps changing system proxy settings, routes, and DNS at the same time.

You can also open Terminal from Applications → Utilities and run these read-only commands to note your macOS version and the current terminal architecture:

sw_vers -productVersion
uname -m

A Terminal session running natively on Apple silicon usually reports arm64; on Intel, it usually reports x86_64. If Terminal is running under Rosetta, the result may reflect the translated environment, so use About This Mac as the source of truth. Apple silicon Macs may need Rosetta to run Intel apps, but installing Rosetta won’t fix a damaged signature or missing network permissions.

“App is damaged and can’t be opened”: check the source, then the quarantine attribute

Step 1: Download a trusted copy

Quit the app and download a fresh installer from the project maintainer’s release page. Avoid repackaged builds from unknown sources. If macOS says the app “will damage your computer” or detects malware, stop—don’t follow the steps for bypassing the standard developer verification warning.

“App is damaged” doesn’t necessarily mean the download was interrupted. It can also point to a signature issue, modified app contents, or a Gatekeeper assessment. Removing the quarantine attribute won’t repair the app or prove it’s trustworthy.

Step 2: Check whether macOS offers an option to allow the app

Try opening the app once, then go to the Apple menu → System Settings → Privacy & Security and scroll to the Security section. If you see an “Open Anyway” option for the app, verify its name and source before following the prompts to confirm. Not every blocked app will show this button. If it’s missing, don’t disable Gatekeeper system-wide to force the app to launch.

Step 3: Check the quarantine attribute only for an app you trust

The commands below assume the app is installed at /Applications/Clash Verge.app. If its name differs, confirm the actual path in Finder or drag the app into Terminal to insert its path. Don’t run a command as written if the path doesn’t match.

xattr -p com.apple.quarantine "/Applications/Clash Verge.app"
spctl --assess --type execute --verbose=4 "/Applications/Clash Verge.app"
codesign --verify --deep --strict --verbose=2 "/Applications/Clash Verge.app"

xattr checks for the quarantine attribute; a “no such attribute” message just means it isn’t set. spctl checks macOS’s launch assessment, and codesign checks signature integrity. Interpret the latter results in light of the release notes: a valid signature doesn’t prove the app is trustworthy, and a failed assessment doesn’t automatically mean you should remove the quarantine attribute.

xattr -d com.apple.quarantine "/Applications/Clash Verge.app"

This command removes the quarantine attribute from the specified app bundle only. It doesn’t recurse through the directory or change system-wide security settings. If the app still won’t open, check the release notes and signature results. Don’t extend the command to the entire Applications folder or add administrator privileges without a specific reason.

Where to allow a Network Extension: first check whether your client uses one

Clash is a common name for a client and proxy-core ecosystem; it doesn’t mean every app uses the same macOS networking technology. Some clients use Network Extensions, while other mihomo GUI clients create a TUN interface through a privileged helper service. If you can’t find a Network Extension switch in System Settings, that alone doesn’t mean the installation failed.

For clients that use Network Extensions

1. Enable the client’s VPN, network routing, or TUN feature to trigger the macOS permission request. You’ll see the corresponding prompt only if the client uses this mechanism.
2. On macOS 15, go to System Settings → General → Login Items & Extensions → Network Extensions and check whether the relevant developer or app is allowed.
3. On macOS 13 or 14, if macOS says system software was blocked, check for a related prompt in System Settings → Privacy & Security. You can also check VPN configurations in System Settings → VPN. The settings location varies by extension type.
4. Verify the developer’s name before allowing the extension. Restart only if macOS specifically asks you to. Then re-enable the feature in the client and check the logs for permission errors.

“Allow VPN configurations” and “Allow system extensions” are different permissions. Don’t lower startup security, disable SIP, or install an unknown kernel extension just to use Clash TUN. These aren’t normal requirements for modern user-space proxy clients.

Managed Macs may require an administrator to approve the request

If a switch is disabled or marked as managed by your organization, check device management details in System Settings. MDM policies can restrict VPNs, system extensions, and background services. Ask your device administrator to handle these restrictions; reinstalling the client repeatedly won’t bypass them.

Installing service mode: an administrator password isn’t a Keychain password

Desktop clients that use mihomo may run a privileged helper in service mode to configure TUN, routes, or related network settings. Installing service mode doesn’t turn on TUN—it grants the client the permissions needed to perform those operations.

1. Make sure the app is in Applications and launch it from there.
2. In the client’s Settings, look for “Service Mode,” “Install Service,” or “Repair Service.” For example, Clash Verge Rev usually has this option under Settings → Service Mode. The exact button name depends on the version you installed.
3. When macOS asks for administrator approval, verify the app’s name. Enter the password for an account with administrator privileges on this Mac—not your subscription password or Apple Account password.
4. After installation, check the service status, then enable TUN. Review the client logs for permission errors, core startup failures, or address conflicts.

If an upgrade makes the client ask to reinstall the service every time it starts, quit any old instances, then use the client’s own uninstall and reinstall service options. Don’t follow unfamiliar instructions to manually delete files from /Library/LaunchDaemons; removing another app’s service can cause new problems.

A service installation can also fail because of an outdated helper, a change in the app’s location, or a management policy. Note when it failed and save the error logs instead of repeatedly entering your password. The system proxy may still work with TUN off, which can help you distinguish a privileged-service issue from a subscription or node problem.

Keychain prompts: check who’s requesting access before allowing it

“An app wants to use confidential information stored in your keychain” usually means the app is trying to read saved credentials or an app key. The request depends on how the client is built, and not every Clash client shows this prompt. Keychain access is separate from administrator authentication for installing a background service.

When a prompt appears, check these details in order

• Check the requester: It should be the client you just opened or a component you recognize. If the name or path is unfamiliar, choose “Deny” and verify the source.
• Check the item name: It should relate to the app you’re using or the feature you’re trying to use. Don’t allow access to credentials for an unrelated browser, email app, or other software.
• Check which password it asks for: The login Keychain usually uses your Mac login password. If you’ve reset your account password, the Keychain may still use your old password.
• Try allowing access once: After confirming the feature works, decide whether to choose “Always Allow.” Don’t add every app to the access list for a sensitive Keychain item.

What if the prompt keeps appearing even when the password is correct?

Use Spotlight to search for Keychain Access. Select the login Keychain and look for an item related to the client. If the Keychain is locked, unlock it and try again. If the issue started after a client update, the app’s signing identity or the item’s access controls may have changed; check the release notes first.

Consider deleting a single item related to the app only if you know what it’s for and can sign in again or reimport your configuration. Back up any exportable settings first. Don’t reset the entire default Keychain as a first step, or you could lose passwords saved by other apps.

After granting permissions, test the system proxy and TUN separately

Don’t turn on both the system proxy and TUN and then guess which one is working. Test the system proxy first, then turn it off and test TUN. Change one thing at a time to pinpoint the issue.

Round 1: Check the system proxy port

Check the active mixed proxy port in the client. The example below uses 127.0.0.1:7890; replace it with the port shown in your client. Turn on the system proxy, then run these commands in Terminal:

scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com

scutil --proxy checks the system proxy settings, and lsof checks whether a port is listening. The last command explicitly sends a request through an HTTP proxy. An HTTP response confirms that this request got a response, but it doesn’t mean every app uses the system proxy. Terminal tools may not automatically follow macOS’s graphical proxy settings either.

Round 2: Test TUN on its own

1. Temporarily turn off the system proxy and clear any proxy environment variables set in the current Terminal session.
2. Turn on TUN and check the logs for interface creation, route setup, and DNS initialization.
3. Send the request again without --proxy, then check the client’s connection log for the destination, matched rule, and outbound policy.

unset http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY
curl -I --connect-timeout 10 --max-time 20 https://example.com

This unset command affects only the current Terminal session. A regular website may load directly, so “the website opens” isn’t enough to confirm TUN is working—check the connection log. Seeing a utun interface on your Mac doesn’t prove it belongs to Clash; other VPNs and system features can create one too.

If some domains become unreachable after you enable TUN, check DNS, rules, and conflicts with other VPNs. Permission problems usually produce a clear error during startup. If only one site times out, investigate the node, matched rule, and DNS results instead of troubleshooting the app’s quarantine attribute again.

Common issues and how to fix them

Work through these steps in order: trusted installer → correct architecture → allow app to open → authorize the service or extension → Keychain access → network tests. Retest after each step and keep the exact error message. This avoids repeating steps and makes it easier to explain exactly where things went wrong if you need help.