Install Clash Nyanpasu on macOS: Network Extension Permissions and Keychain Prompts

Identify the four types of permission prompts

On macOS, launch blocks, administrator authorization, Network Extension permissions, and Keychain access are separate security mechanisms. When troubleshooting, note the exact prompt, requesting process, time, and action that triggered it. Don’t assume every prompt means “insufficient TUN permissions,” and don’t keep entering passwords to see what works.

Install locations and “app can’t be opened” warnings

Check your macOS version and processor

1. Open the Apple menu → About This Mac and note the macOS version and the Chip or Processor entry. Apple M-series Macs use Apple Silicon builds; choose the x86_64 build for Intel Macs.
2. Choose the macOS build for your processor architecture on the download page. If a universal build is available, still check its minimum macOS requirement. Don’t rely on the filename alone to determine compatibility.
3. Open the disk image and copy the app to Applications. Quit any older instance running from the disk image, eject the image, then launch the app from Applications.
4. Quit the client before upgrading. Keep your existing configuration and note the current version, selected core, and listening ports. Don’t delete the entire configuration directory as your first troubleshooting step.

Running the app from Downloads or a disk image long-term can lead to changing paths and duplicate copies. Once it’s installed in a fixed location, open Applications in Finder and make sure you’re launching the copy you intend to use. An architecture mismatch, an outdated macOS version, and a signature block are different problems; one command won’t fix them all.

Follow the system prompt to decide whether to allow the app to open

On macOS 13 Ventura, 14 Sonoma, and 15 Sequoia, check for security alerts under Apple menu → System Settings → Privacy & Security. Try opening the app once, then look near the bottom of the page for a block notice about it. Verify the source and app name before using Open Anyway, if that option is available, and follow the prompts to authenticate. macOS 15 applies stricter checks to some unsigned or unnotarized apps; right-clicking the app in Finder and choosing Open is not a universal workaround.

• “Unable to verify developer” prompt: Verify the download source and release notes first, then decide whether to use the exception offered by macOS.
• “App is damaged” prompt: Quit any running instance, download the build for your architecture again, and copy it to Applications. This warning can also indicate a signing issue or changed app contents; it doesn’t necessarily mean the download was interrupted.
• “Will damage your computer” or malware warning: Stop and verify the release details. Don’t force the app to launch by removing its quarantine attribute.
• No option to allow the app on a managed device: Ask your organization’s administrator to check the device management policy. Don’t change system security settings.

If you need to share signature details with the maintainer, run these read-only checks in Terminal. The paths assume the app is installed under this name in Applications; if its name differs, confirm the path in Finder first.

sw_vers
uname -m
codesign --verify --deep --strict --verbose=2 "/Applications/Clash Nyanpasu.app"
spctl --assess --type execute --verbose=4 "/Applications/Clash Nyanpasu.app"

uname -m typically returns arm64 in a native Apple Silicon terminal. On Intel or under Rosetta, it may return x86_64, so use About This Mac to confirm your architecture. Signature check results are clues for troubleshooting, not a complete security review of the app. Don’t disable Gatekeeper or System Integrity Protection just to install the client.

Test the system proxy before enabling the service and TUN

Start with a minimal working configuration

On first launch, import a working Clash YAML configuration, confirm it’s selected and the core starts successfully, then test the standard system proxy. The client UI can change between versions, so use the feature names “System Proxy,” “Service Mode,” and “TUN Mode” as landmarks rather than assuming every version has the same menu layout.

1. Select the configuration you want to use on the Profiles page, then check the core logs for YAML parsing errors or port conflicts.
2. Note the actual HTTP or mixed listening port. For example, use 127.0.0.1:7890 only if the configuration specifies mixed-port: 7890. Port 7890 is not a universal default.
3. Enable the system proxy and test the connection in a browser. Leave TUN off for now to avoid changing the traffic entry point, routing, and DNS all at once.
4. Once the standard proxy works, decide whether to enable TUN based on whether the apps you use follow the system proxy settings.

# Only applies when mixed-port is actually set to 7890
lsof -nP -iTCP:7890 -sTCP:LISTEN
scutil --proxy

Use lsof to check which process is listening, and scutil --proxy to view the current system proxy settings. A listening port doesn’t guarantee that proxy groups, remote nodes, or DNS are working. If the log says address already in use, identify the process using the port, quit duplicate clients, or change the port. Don’t terminate every process with a similar name.

Use your administrator password only for a specific service action

Creating a TUN interface or changing routes may require a privileged service. If your version offers an option to install or repair the service, start it from the client and check the app or helper name shown in the system password prompt. A normal administrator authorization and a subsequent Keychain access prompt are separate: the first approves a privileged action; the second grants access to a specific secret.

• Install the service with an administrator account. A standard account will need help from an administrator.
• If the service and client versions no longer match after an upgrade, use the management option in the current version to repair the service, then restart the client.
• If macOS says a background item was disabled, check System Settings → General → Login Items on macOS 13 or 14, or General → Login Items & Extensions on macOS 15. Allow only items whose source you’ve verified.
• If service installation fails, save the exact error message. Don’t recursively change permissions on the entire app directory or use sudo to run the graphical client long-term instead of installing its service properly.

Network Extension and VPN configuration permissions

Use this section only if the prompt explicitly mentions a system extension, Network Extension, or VPN configuration. Other VPNs, security software, and traffic filters can produce similar prompts. Check which process is requesting permission; don’t assume every network prompt that appears while installing Clash Nyanpasu is related to it.

Follow the system prompt to determine whether a restart is required after allowing an extension. If TUN is enabled but no Network Extension is listed, that alone doesn’t mean the installation failed. Check whether the core created a TUN interface, updated routes, and reported DNS errors. Conversely, allowing an extension doesn’t mean nodes in your subscription are reachable.

How to handle repeated Keychain prompts

Check the requester and item first

A Keychain prompt usually names an app that wants to access sensitive data in the “login” keychain. Note the app and item names. Subscription credentials, proxy authentication, or passwords saved by another VPN may be accessed during network activity. A prompt appearing at the same time as an action doesn’t prove that Clash Nyanpasu requested it. If the action doesn’t involve signing in or reading credentials, choose Deny first and check where the request came from.

Allow usually approves access just this once. Always Allow saves permission for that item, but the result depends on the item’s access controls and the app’s identity. Don’t grant unrestricted access to every item just to get rid of the prompt. An app update, signature change, or launch from a different copy can make existing permissions no longer match.

Check the status of the “login” keychain

1. Use Spotlight to find and open Keychain Access. macOS 15 also includes the Passwords app, but check keychain item access controls in Keychain Access.
2. Select the “login” keychain and check whether it’s unlocked. If prompted for a password, enter the keychain password—not your subscription password or Apple Account password.
3. If an administrator recently reset your local account password, the old “login” keychain may still use your previous password. If you know it, use the password change option in Keychain Access to update the keychain password to your current login password.
4. Search for the exact item name shown in the prompt and open its information. If there’s an Access Control tab, check whether the permitted app points to the copy you’re currently using.
5. Quit copies running from other locations, relaunch the app from Applications, then repeat the action that triggered the prompt and see if it appears again.

If you don’t know the old keychain password, don’t keep trying your account password. Resetting the default keychain creates a usable new one, but it won’t decrypt old items; you may need to re-enter saved passwords, certificates, or other credentials. Confirm your backup and recovery options first. Ask an administrator for help with company certificates or managed device identities.

Don’t delete items in bulk

Repeated prompts can also happen when an app can’t save permission, the login keychain locks automatically, or each request comes from a different path. First check which app copy is running and the item’s access controls. Only then consider recreating credentials that are clearly related to the issue and can be retrieved again. Don’t delete every item containing “proxy” or “VPN,” and don’t move the entire keychain directory.

Before sharing a screenshot, hide account names, server addresses, and tokens in keychain items. Never show item passwords. Troubleshooting normally requires only the requesting app, item name, and error text—not your subscription URL.

Verify permissions and recover from failures

Verify each layer in order: app launch → core running → standard proxy → service → TUN. Change one setting at a time and record the result before and after. Base these checks on the actual configuration, not the color of a UI toggle.

• Launch: The app opens from Applications and doesn’t show the same launch block again after you quit and reopen it.
• Core: Logs show no configuration parsing failures, port conflicts, or repeated crashes and restarts.
• System proxy: The enabled settings, address, and port shown by scutil --proxy match the client’s records.
• TUN: Check the logs for successful virtual interface creation. The interface may be named utun, but other system services can create similar interfaces, so the presence of utun alone does not confirm success.
• Credentials: Repeat the same subscription update or authentication action and confirm that no unexplained Keychain prompt appears.

If the network stops working after enabling TUN, turn TUN off in the client first, then disable the system proxy and check whether the regular connection returns. Don’t repeatedly toggle Wi-Fi before you know the current state. If the app quits unexpectedly, check System Settings → Network → your current network service → Details → Proxies for settings that still point to a local port. Remove only the proxy setting added by this client; keep any existing corporate proxy settings.

When reporting an issue, include your full macOS version, processor architecture, client and core versions, installation path, steps to reproduce, and logs from the same time period. Redact subscription URLs, access tokens, authentication passwords, and personal domains from logs first. For an explanation of configuration fields, see the YAML Configuration Guide. To set up a working configuration for the first time, start with Getting Started.