Clash Verge Rev Windows Service Security Check Failed?

Record the user identity when Windows reports “service core failed the security check; switched to ordinary mode (Sidecar).” Clash Verge Rev then starts the core as the current user. Networking may still work, but it no longer obtains elevated privileges through the system service; Sidecar under a standard user cannot use TUN.

The service runs the core with system privileges, so the project checks the ownership and access permissions of the core files, installation directory, and parent directories. If a standard account can replace any of them, the service must reject that elevated startup path.

Project issue #8073 documents one case on Windows 11 with v2.5.5 and v2.5.6: enabling TUN as a standard user triggered a rejection whose original error pointed to the C: drive root; TUN worked when the app ran as administrator. This is a specific report, not evidence that every Windows device has the same cause.

If the error concerns only DELETE permission on the C: drive root, follow the v2.5.7 branch below. Errors involving other paths, ownership, or unreadable ACL information still require checks of the named files and directories.

The official Windows FAQ says the pop-up gives only a shortened explanation. Right-click that notification in the app and copy the original error into Notepad. The word “Sidecar” alone does not tell you whether the service is missing, the configuration is wrong, or the whole C: drive is unsafe.

Find the core path, filename, and following reason in the error. If both core files are rejected, they may simply share an unsafe parent directory. Record the path before changing any ACL.

If the core path points to the C: drive root, the check reached the volume root; it does not mean the app was installed there. Issue #8073 reported this path even with the default Program Files installation.

Record the actual client version, install location, current execution identity, Service Mode state, and first permission-denied log line together. Logs or configs may contain subscription credentials and your local username; make a redacted copy before sharing them publicly.

Turn off TUN and confirm ordinary Windows networking works. If the Sidecar system proxy opens a real web page and its request appears in the connection records, use it temporarily. Do not repeatedly click Install Service before identifying the rejected path.

If you genuinely need TUN temporarily, the project FAQ describes an administrator-run workaround: fully quit the app from the tray, right-click its shortcut or clash-verge.exe and select “Run as administrator”, choose “Continue using Sidecar” if prompted to repair the service, then enable TUN as needed.

Running as administrator is a temporary workaround; it does not repair the service or directory permissions. You must launch as administrator each time you use this path. When TUN is unnecessary, return to running as a standard user with the verified system proxy.

If the original error points to the Desktop, Downloads, a user directory, or a manually extracted location, first save your configuration with “Settings → Verge Advanced Settings → Back Up Settings”, then fully quit the app from the tray. Use the project's official installer and the default C:\Program Files\Clash Verge path.

Do not carry custom permissions from the old directory into the new installation or grant standard users “Modify” or “Full control”. If the new directory is still rejected, check whether the error points to a core file, the installation directory, or a higher parent directory.

If the app is already in the default directory, follow the official FAQ: open “Properties → Security → Advanced” for the reported path in File Explorer and inspect the owner and permission entries. The core files and related directories should be owned by SYSTEM, Administrators, or TrustedInstaller; a standard account must not be able to modify the core, replace directories, or change permissions.

If the permissions come from a parent directory or the device is managed by an organization, have its administrator restore them according to the existing policy. Do not broaden permissions just to make the security check disappear. After confirming the path is safe, reinstall the service under “Settings → Service Mode”; uninstall the old service first if necessary, then check the home screen status.

If the original error's core path points to the C: drive root and shows only dangerous=0x00010000, the official FAQ treats it as a separate volume-root DELETE permission case. Do not change the C: drive root permissions yet.

Service repository commit e8f5279 adjusted the check: a volume root cannot be deleted or renamed like an ordinary folder, so this DELETE permission is ignored only at the volume root. Checks for other dangerous write permissions remain in place.

The official v2.5.7 release notes explicitly say they fixed an incorrect check of DELETE permission on the Windows system drive root that made Service Mode and TUN unavailable. Issue #8073 documents failures in v2.5.5 and v2.5.6; it does not show that v2.5.7 fixes every directory-permission or ownership error.

If the error concerns only DELETE permission at the volume root, back up your settings, fully quit the app, and get the official v2.5.7 installer for your system architecture from the project Release. After updating, reinstall the service once under Settings → Service Mode, copy the new verbatim error if any, and test TUN as a standard user. If access is still denied, do not repeatedly reinstall or change permissions across the drive; use the connectivity fallback above and investigate the new error.

If the new error also reports other dangerous permissions, an incorrect owner, or an unreadable ACL, the “DELETE only” exception does not apply. Ask an administrator to inspect the specific new path. Do not remove ordinary read access or the volume root's normal create-folder permission along with it.

Verify the fix while signed in as the standard user who originally saw the failure. Fully quit the administrator-run app, relaunch as a standard user, confirm the home screen says “Service Mode”, and make sure the core security check rejection no longer appears. TUN working only in an administrator window does not count as recovery.

Then enable TUN using the original Profile and node, request the same real HTTPS website, and confirm in the connection log and application logs that the request actually reaches the core. Turn TUN off again and confirm ordinary networking immediately returns.

Finally, fully quit and restart the app, then repeat the checks for the standard user, service mode, TUN, and web requests. If it returns to Sidecar after restarting, the problem still occurs after a restart. Keep the new error message exactly as reported for further investigation.

If the core is still rejected after an update or service reinstall, turn off TUN, fully quit the app, and restore the previously working system proxy or Windows direct connection. If moving the installation caused Profiles to disappear, restore your configuration from the backup. Do not loosen write access to core files just to clear a warning.

Do not make an older service version the default rollback: the available evidence does not show that it resolves this rejection. If you temporarily need TUN, use only the administrator-run approach from the project FAQ. When TUN is unnecessary, keep running as a standard user with the connectivity method you verified.

When reporting to a project issue, include the client version, installation path, results as a standard user versus administrator, original core path and dangerous field, new notification after reinstalling the service, and outcome of a real request. Remove subscription tokens, node passwords, personal paths, and other sensitive information first.

If the new error says is owned by, cannot read permissions, or names another writable ACE, investigate the new path rather than applying the volume-root DELETE workaround. Judge recovery from the new error and real requests made as a standard user.