[Bug]: WinGet Disable CLI policy not bypassed

[A55imilat0r]

The problem

We are trying to prevent interactive users from running WinGet via CLI with this ADMX/CSP by setting this to Disabled.
./Device/Vendor/MSFT/Policy/Config/DesktopAppInstaller/EnableWindowsPackageManagerCommandLineInterfaces

However for obvious reasons this breaks the fundamental behaviour of Winget-Autoupdate scheduled tasks.

What do we need to do here to keep the CLI disabled for interactive users but allow Autoupdate scheduled tasks to function?

What version of WAU has the issue?

2.3.1

What version of Windows are you using (ex. Windows 11 22H2)?

Windows 11 25H2

What version of winget are you using?

1.28.240

Log information

#################################################################
#    11/05/2026 - CHECK FOR APP UPDATES (System context - Connected user)
#################################################################
09:20:02 - Reading WAUConfig
09:20:02 - Notification Level: SuccessOnly. Notification Language: English
09:20:02 - Checking internet connection...
09:20:02 - Connected!
09:20:03 - Checking prerequisites...
09:20:03 - VC++ x64 already installed (14.50.35719.0)
09:20:08 - WinGet installed version: This operation is disabled by Group Policy: Enable Windows Package Manager command line interfaces | WinGet available version: 1.28.240
09:20:09 - Prerequisites check failed
09:20:09 - Selected winget instance: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.28.240.0_x64__8wekyb3d8bbwe\winget.exe
09:20:09 - WAU current version: 2.11.0
09:20:09 - WAU AutoUpdate is Disabled.
09:20:09 - WAU uses White List config
09:20:09 - -> Successfully loaded local included apps list.
09:20:10 - Checking application updates on Winget Repository named 'winget' ..
09:20:10 - No update found. 'Winget upgrade' output:
This operation is disabled by Group Policy: Enable Windows Package Manager command line interfaces
09:20:10 - No new update.
09:20:10 - End of process!
10:33:49 - Rerun WAU in system context with ServiceUI

Additional information

No response

[KnifMelti]

Claude recommended:

Workaround: Use AppLocker/WDAC instead of the CLI CSP policy

The root cause here is that EnableWindowsPackageManagerCommandLineInterfaces is a device-level policy, meaning it applies to all execution contexts including SYSTEM — which is exactly the context WAU's scheduled task runs in.

If the goal is to prevent interactive users from running winget manually via CLI (while keeping WAU functional), a more targeted approach is to use AppLocker or WDAC to block winget.exe at the user level instead.

AppLocker approach

Create a publisher or path rule that:

• Allows BUILTIN\Administrators and/or NT AUTHORITY\SYSTEM to execute winget.exe
• Denies standard users from executing winget.exe

This achieves the same security goal without touching WAU's execution context at all.

Why this works

AppLocker rules are evaluated per user token, so when WAU runs as SYSTEM via its scheduled task, it falls outside the deny rule targeting standard users. Interactive users attempting to run winget from a terminal are blocked as intended.

Trade-offs

• Requires AppLocker or WDAC to be configured and enforced (needs appropriate Windows edition — Business/Enterprise)
• Slightly more complex initial setup compared to the single CSP toggle
• More flexible and granular than the CSP, which is an all-or-nothing machine-wide block

[A55imilat0r]

I did not come here for an AI answer that stuff sends me round the bend, and denying users via applocker could break in that way could break updating apps in the user context.

[KnifMelti]

How this can be a [Bug] of WAU I don't know...

Anyway, you could try creating your own solution via the Mods for WAU system.
Maybe deleting the ruling REG Key/Value will do it and then restoring/gpupdate (or let GPO do it after the std. time if the user run shouldn't be affected too)
This you do in _WAU-mods.ps1/_WAU-mods-postsys.ps1