macOS Clash Permission Issues? Network Extension & Keychain Authorization Guide
Clash on macOS often stalls on permissions: how to approve the network extension, handle Keychain prompts, and fix the "file is damaged" error.
Why Clash on macOS keeps triggering permission prompts
For the Clash client to work properly on macOS, it relies on two categories of system-level authorization. The first is the Network Extension, which the client uses to take over system traffic and implement transparent proxying under TUN mode; the second is Keychain Access, which the client needs to read and write local credentials or configuration to keep the proxy service running reliably. Both operations touch the low-level network stack and sensitive data storage, and by design Apple requires explicit user approval before an app can proceed. This isn't a flaw in the Clash client itself — it's a consequence of macOS's security model.
On top of that, most Clash clients aren't distributed through the Mac App Store but as third-party installer packages, which triggers extra checks from Gatekeeper (Apple's notarization and source-verification mechanism). The typical result is a "file is damaged and can't be opened" or "can't verify developer" message. Understanding which system mechanism each of these three prompts maps to will keep your troubleshooting on the right track.
Network extension approval: where to find it in System Settings
The first time the Clash client enables TUN mode or the system proxy, macOS pops up a system notification saying something like "a new network extension needs approval." This notification is easy to dismiss or swipe away by accident, and once missed, the client will appear "connected" while none of the traffic actually goes through the proxy — without popping up again on its own.
- Open "System Settings" (called "System Preferences" on older macOS versions).
- Go to the "Privacy & Security" section and find "Network Extensions" or "VPN & Network Extensions" (the exact wording varies slightly by macOS version).
- Locate the corresponding Clash client entry in the list and confirm the toggle is switched on.
- If the entry appears greyed out and unclickable, you usually need to click the lock icon in the bottom-left corner and enter your system password before you can toggle it.
- After toggling, it's best to fully quit the client (not just close the window) and relaunch it so the extension reloads properly.
If the Clash client entry doesn't show up in the "Network Extensions" list at all, it's likely the initial authorization prompt was dismissed or declined. Fully quit the client and relaunch it — macOS will typically trigger the authorization prompt again.
Some macOS versions split the network extension entry into two separate sections, "VPN" and "Network Extensions." If you don't find it in one, check the other. Once approval takes effect, the menu bar icon or the client's main connection status usually switches from "Not Connected" to "Connected" within a few seconds.
Keychain prompts: when to allow and when to deny
When the system proxy is enabled or local credentials are saved, macOS shows a prompt like '"Clash" wants to use your confidential information stored in Keychain' and asks for your password. This prompt exists so the client can read or write the Keychain entry it created itself — not to access passwords saved by your other apps.
- If the app name shown in the prompt matches the Clash client you're running, click "Always Allow" so you don't need to re-enter the password every time you launch it.
- If you're just testing temporarily, "Allow" works too — it only applies to this session, and the prompt may appear again next time.
- Repeatedly clicking "Deny" will prevent the client from saving proxy configuration, which typically shows up as the system proxy toggle resetting to off every time the client restarts.
If you're unsure whether a prompt is trustworthy, open the "Keychain Access" app (in Applications › Utilities), search for the client's name, and check the creation time and access control list of the matching entry to confirm no unexpected source is reading it.
Keychain prompts only request access to entries the client created itself — they're isolated from other passwords saved in your browser or elsewhere on the system. Choosing "Always Allow" doesn't broaden that scope.
What causes "file is damaged, can't be opened" and how to fix it
This message doesn't actually mean the installer is corrupted — it means macOS's Gatekeeper mechanism has blocked an app that either isn't notarized by Apple or has its source flagged as "untrusted." When a third-party Clash installer is downloaded, the browser tags the file with a quarantine attribute, which tells macOS the file came from the internet and needs extra signature verification. When that verification process runs into an issue (for example, the installer was re-packaged by a compression tool, or the attribute got lost during transfer), the system shows this misleading "damaged" message instead of the real cause.
The fix is to remove the quarantine attribute so the system skips this check and proceeds straight to the normal app launch flow:
xattr -cr /Applications/YourClashClient.app
Replace the app name in the command with the actual install path. You can type xattr -cr /Applications/ into Terminal first, then drag the app icon from Finder directly into the Terminal window to auto-complete the path and avoid typos. No output after running the command means it succeeded — double-click the app icon again and it should open normally.
If Terminal shows "Operation not permitted," Terminal itself hasn't been granted "Full Disk Access" yet. Go to System Settings › Privacy & Security › Full Disk Access, add Terminal to the list and enable it, then run the command again.
A more direct but not recommended long-term option is to find the "Open Anyway" button at the bottom of System Settings › Privacy & Security — macOS shows this exception shortly after the app is first blocked, and clicking it once allows that particular launch. This may need to be repeated after each client update, so the Terminal command is the more thorough fix.
Advanced permission checks for TUN mode
If the client has already been approved through the network extension but TUN mode still fails to connect or traffic isn't routing through it, work through these steps:
- Confirm the toggle in the "Network Extensions" list is switched on, and that it's not conflicting with another VPN tool that also relies on system extensions (two tools that both depend on network extensions usually can't be active at the same time).
- Check whether the TUN mode toggle in the client's settings is actually enabled — some clients treat TUN mode and system proxy mode as two separate options, and enabling both at once can cause them to override each other.
- Restart the Mac. In rare cases the network extension can end up "approved but not loaded" due to a system cache issue, and a restart is the most direct fix.
- Confirm your current macOS version meets the client's minimum system requirement — an outdated OS version may not support the newer kernel's network extension API calls.
After these steps, check the client's connection status or log panel to confirm the TUN interface has been established. It usually shows a virtual network adapter name starting with utun, which confirms the system-level takeover succeeded.
A few preventive steps before installing
Rather than troubleshooting each permission prompt as it appears, it's simpler to avoid the common triggers before you even install:
- Get the installer from an official source — re-packaging or passing it through cloud storage can corrupt the quarantine attribute.
- After installing, walk through network extension approval and Keychain authorization completely before configuring a subscription or rules, so permission issues and configuration issues don't get tangled together.
- After a major client update, make it a habit to recheck the relevant "Privacy & Security" toggles — system updates sometimes reset an extension's approval status.
Keeping the permission flow separate from subscription setup makes it much easier to figure out whether an issue sits at the system authorization layer or the client configuration layer, and cuts down significantly on "it's installed but won't work" troubleshooting time.