Introduction

Level's winget actions run as the SYSTEM user and enforce machine scope on all operations. Most installation and upgrade failures trace back to one of these two constraints. Understanding them up front resolves the majority of reported issues.

How Level Runs Winget

Level's package install, upgrade, and uninstall actions use Microsoft's Windows Package Manager API. They do not depend on an interactive PowerShell session or the signed-in user's winget configuration. The separate Install Winget action installs the standalone winget.exe command-line tool.

Two things are always true for every Level winget package action:

Runs as SYSTEM: Level executes package operations under the SYSTEM account, not as a logged-in user or a standard admin session. Any package behavior that depends on user context won't work the same way.
Enforces machine scope: Level requires machine scope for package operations. Only packages with an applicable machine-scope installer can be installed or upgraded through Level.

These two constraints explain nearly every "it works in PowerShell but not in Level" report.

Common Issues

Package installs via PowerShell but not via Level

If you can install a package as the currently logged-in user but the Level action fails, the difference is user context. Level runs as SYSTEM, which has a different environment and registry than a logged-in user. Most of the time this surfaces as a permission issue or a missing user profile path.

There's no workaround for packages that fundamentally require a user session. For those, consider a script-based approach with PsExec or a scheduled task running under a specific user context.

Package installs as admin but not via Level

Level enforces machine scope. A package may install fine as an admin without --scope machine but fail when machine scope is required.

Test it directly to confirm:

winget install --scope machine -e --id PACKAGE_ID

If this fails in an admin PowerShell session, the package doesn't provide a machine scope installer. Level can't install it via the winget action. The only options are to find an alternative package ID that supports machine scope, or install it via a Run Script action with a different installer.

Upgrade action shows fewer packages than expected

Level uses machine scope for upgrade scans, so only machine-scoped installations appear in the upgrade list.

You can verify by running the equivalent command yourself:

winget upgrade --scope machine --all

If the results match what Level shows, Level is accurate. Packages installed under a user scope won't appear.

Package install or upgrade times out

If the action output says operation timed out, Windows Package Manager did not finish the package operation within about 30 minutes. This commonly happens when an installer stalls or waits for user interaction that cannot be provided while Level runs headlessly as SYSTEM.

Review the action output for a stalled process name or a message that the application is in use. Close the application and retry when that is practical. If the same package repeatedly times out, add its package ID to Excluded package(s) in an Upgrade all action and deploy it with the vendor's supported silent installer or a Run Script action instead.

Common error messages

Error	What it means	What to do
`0x8A150010` — None of the installers are applicable for the current system	The package does not provide an eligible installer for this device and machine scope.	Test the package with the machine-scope command above. Use a different package ID or vendor installer if it fails there too. Exclude it from Upgrade all if it keeps being selected.
`0x8A150011` — The installer file's hash does not match the manifest	The catalog manifest and downloaded installer no longer match, often because the vendor replaced the file before the catalog was updated.	Retry later. If the error continues, exclude the package until its upstream manifest is corrected.
`0x8A15005F` — Install location must be provided	The package requires an install location that the unattended action cannot supply.	Use another package or deploy the vendor installer with a script that provides the required location. Exclude it from Upgrade all.
`0x8A150030` — Running uninstall command failed, or `0x8A150114` — The installer does not support upgrading an existing package	The package's current installation cannot be upgraded through the available unattended path.	Use the vendor's supported upgrade procedure or a custom automation. Exclude the package from Upgrade all to prevent repeated failures.
`0x8A150006` — Running ShellExecute failed, or `0x8A150049` — Running MSI install failed	The vendor installer returned a failure. These are general errors, so the exact cause depends on the package.	Review the action output and vendor installer logs. Close the application or finish a pending reboot when the output indicates that is required. Use a vendor-supported silent installer if the failure repeats.
`0x8A150102` — Another installation is already in progress	Windows Installer is busy with another package or Windows Update operation.	Let the other installation finish, then retry. Avoid scheduling Winget and Windows Update install windows at the same time.

Excluding a Package from Auto-Updates

The Upgrade Winget Package action has a built-in Excluded package(s) field. Enter one or more package IDs there and those packages are skipped during the upgrade run, with no pinning or command-line workarounds needed.

Checking if a Package Supports Machine Scope

The definitive check is the package manifest in the winget-pkgs repository. Look for InstallerScope: machine in the manifest. If it's absent or set to user, Level's winget action won't be able to install it.

The practical shortcut: run the winget install --scope machine command above in an admin PowerShell session. If it succeeds there, it'll work in Level.

FAQ

Does Level use the standard Microsoft winget or its own version? Level's package actions use Microsoft's Windows Package Manager API. The separate Install Winget action installs the standalone winget.exe command-line tool. Running a package action does not guarantee that winget.exe is available on the device's PATH.
I can't find a package ID. Where do I look? Search the winget-pkgs repository or run winget search <name> in a PowerShell session on a device where the standalone CLI is installed. The ID you find is what goes in the Level action.
Can I run winget commands directly from Level's terminal? Yes, when winget.exe is installed and available on the device. Level's background terminal runs as SYSTEM, so the machine-scope and SYSTEM-context constraints apply there too. The package actions use the Windows Package Manager API rather than your terminal process, so use direct commands as a diagnostic rather than assuming every result will be identical.
A package was recently added to winget-pkgs but Level doesn't show it as available. Level's catalog data may lag behind the community repository slightly. If a very recent package isn't appearing, check whether machine scope is defined in the manifest yet.

Winget Troubleshooting