macOS Clash Permissions Guide: Network Extension & Keychain Prompts

Why macOS shows several permission windows in a row

Installing a network tool on Windows usually needs just one "allow network access" prompt, but on macOS, Clash clients (ClashX Meta, Clash Verge Rev, or any other mihomo-core-based client) tend to trigger three types of prompts on first launch: network extension authorization, keychain access authorization, and sometimes an accessibility permission request as well. This isn't a bug in the client itself — it's the result of security mechanisms Apple has tightened progressively since Catalina.

Clash-style clients take over system-wide traffic mainly through two paths: modifying the system proxy settings (HTTP/HTTPS/SOCKS proxy fields), or creating a virtual network adapter via TUN mode that intercepts and forwards all outbound traffic at the network layer. TUN mode covers more ground — it handles UDP and traffic from apps that aren't proxy-aware — so most mainstream clients now recommend enabling it by default. On macOS, creating a virtual adapter must go through Apple's NetworkExtension framework, and Apple requires explicit user authorization for any program calling that framework — that's where the network extension prompt comes from. The keychain prompt usually appears when the client needs to write a local certificate, save a subscription password, or call low-level networking APIs; the system checks whether that access should be trusted. Understanding what each prompt actually does lets you make an informed choice instead of dismissing them blindly.

Network extension prompt: when it appears and how to handle it

The first time you try to enable TUN mode in a client (some UIs label it "virtual adapter," "enhanced mode," or "system proxy enhanced"), macOS shows a window titled something like "'Clash Verge' Would Like to Add Content Filters" or "System Extension Blocked." This plays out in two ways:

1. A direct confirmation dialog appears: it has "Allow" and "Don't Allow" buttons. Click "Allow," and the system loads the extension in the background — usually within a few seconds the TUN toggle in the client turns on normally.
2. A message saying "System extension blocked, enable it in System Settings": this is more common, especially on macOS Ventura and later. There's no direct allow button here — you need to open System Settings and confirm manually.

If you hit the second case, here's the path: open System Settings → Privacy & Security, and scroll down to the "Security" section. If an extension was blocked, you'll see a notice naming which app's system extension was blocked. Click "Allow" next to it, and the system will ask for your login password or Touch ID confirmation. Once confirmed, go back to the client and toggle TUN mode again — it should take effect. On some Macs this notice only appears briefly, and if it gets pushed off-screen by other Settings activity before you handle it, quit and relaunch the client — the notice usually reappears.

Keychain access prompt: what each option actually means

The standard keychain prompt text reads something like "'Keychain Access' wants to use your confidential information stored in your keychain," with the app name shown below, and three buttons at the bottom: "Deny," "Always Allow," and "Allow." The differences between these are easy to overlook:

• Allow: applies only to this one access; the next time the client restarts or accesses the keychain again, the prompt reappears. Useful if you want to confirm every access individually, but it becomes annoying for daily use.
• Always Allow: once granted, all future access by that app to this keychain item skips the prompt. This is the recommended choice for everyday use.
• Deny: blocks this access. The client may then fail to load certificates, fail to save a subscription password, or write incomplete system proxy settings.

If you accidentally clicked "Deny" and the client is now misbehaving, you don't need to reinstall it. Open Finder → Applications → Utilities → Keychain Access, search for the client's name in the search box, find the matching keychain item, right-click and choose "Get Info," and under the "Access Control" tab you can manually re-add the app to the allowed list — or simply delete the keychain item and restart the client so it goes through the full authorization flow again.

Accessibility and other background-related permissions

Some clients (especially versions with global hotkeys, floating overlays, or automation scripts) also request the "Accessibility" permission, used to listen for keyboard events or control other app windows. Not every client needs this — if a client asks for accessibility access without having any related feature visible in its UI, first confirm the build's source is legitimate before granting it. To grant it, go to System Settings → Privacy & Security → Accessibility, find the client in the list, and toggle it on. Below that in the same section is "Full Disk Access," mainly used when the client reads or writes a custom config directory. If you've placed your config files somewhere other than the system default location (like the Documents or Downloads folder), check this setting if you run into read failures.

Manual fixes in System Settings after a failed authorization

If TUN mode still won't turn on after following the steps above, or the client reports "Network extension installation failed," work through this checklist in order:

1. Open System Settings → Privacy & Security → VPN & Device Management (on some macOS versions this is merged into a subpage of Network settings), and confirm the client's network extension entry is listed and shows as "Enabled." If the entry exists but its status looks wrong, remove it and trigger the install again.
2. Confirm your macOS version meets the minimum requirement stated in the client's release notes. Older system versions have incomplete support for newer NetworkExtension APIs, a common cause of extension load failures.
3. Check whether other network tools are installed at the same time (other proxy clients, network management software) — multiple virtual adapter extensions occasionally conflict with each other. Remove old extension entries you no longer use in System Settings.
4. If everything above checks out and it still won't turn on, fall back to system proxy mode to restore usability while waiting for a compatibility fix in a future client release.

Separately, if launching the client shows "can't be opened because the developer cannot be verified," that's a different issue from network extension authorization. To fix it, open System Settings → Privacy & Security, scroll down to the "Security" section, find the app that was just blocked, click "Open Anyway," and enter your password in the confirmation dialog to launch it normally. This step usually only appears once, on first launch.

FAQ

I clicked "Allow," but the TUN toggle keeps flipping back to off. What's wrong?

This usually means the network extension didn't actually finish loading. Check its status under "VPN & Device Management" first — if it looks off, remove it, restart the client to trigger authorization again, and try enabling TUN once more.

Do I need to restart my Mac after finishing all the authorizations?

Usually not. On a few system versions, the extension only fully takes effect after you log out and back into your user account. If restarting the client still doesn't work, try logging out and back in before trying again.

Is it normal to be asked to re-authorize every time I start my Mac?

No, that's not normal. Authorization should only need to happen once. Repeated re-authorization prompts usually mean the app's signature or install path changed — check that you're using a consistent build source, and make sure you don't have multiple installs of the same client interfering with each other.