Einführung

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

Two things are always true for every Level winget action:

Runs as SYSTEM: Level executes winget 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 adds --scope machine to all winget operations. Only packages with a machine scope defined in their manifest 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:

__PRESERVE_CODE_7__

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 adds --scope machine to upgrade scans, so only machine-scoped installations appear in the upgrade list.

You can verify by running the equivalent command yourself:

__PRESERVE_CODE_9__

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

Package install times out in Level but works via admin PowerShell

This is rare. It happens when the package's installer doesn't handle silent/quiet mode properly and waits for user interaction that can never arrive, since Level runs as SYSTEM with no UI. There's no workaround for this — the issue is with the installer itself. Check the package's open issues in the winget-pkgs repository.

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 — 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.

Häufig gestellte Fragen

Does Level use the standard Microsoft winget or its own version? Level installs and manages its own implementation of winget. The Install Winget action (or any other winget action, which auto-installs it) sets up Level's managed version. This ensures consistent behavior across your devices regardless of what winget version (if any) was already present.
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 Level's winget is installed. The ID you find is what goes in the Level action.
Can I run winget commands directly from Level's terminal? Yes. Level's background terminal runs as SYSTEM, so the machine scope and SYSTEM context constraints apply there too. Test commands in the terminal first before building them into an automation.
A package was recently added to winget-pkgs but Level doesn't show it as available. Level's winget implementation may lag behind the community repository slightly. If a very recent package isn't appearing, check whether the --scope machine scope is defined in the manifest yet.