I can install the package using PowerShell as a currently logged-in user, but not using the Winget action.
Level runs Winget using the SYSTEM user, so it is a different operation than running as the current logged-in user.
I can install the package using PowerShell as admin, but not using the Winget action.
Level enforces the machine scope when installing a package. Only packages that define the machine scope in the manifest can be installed using the Winget action. You can test it running this command in an admin PowerShell session:
winget install --scope machine -e --id PACKAGE_ID
If the install fails, it means the package does not provide the machine scope.
The Winget action shows fewer packages that need an update.
Level enforces the machine scope on all commands. You should have the same results by running this command in an admin PowerShell session:
winget upgrade --scope machine --all
How do I know if a package is supported by the Winget action?
Unfortunately, for now, the only way is to check the manifest defined in the winget-pkgs repository. In the future we might consider having a mini Winget mirror with only machine-scoped packages that we could display in the UI.
A package install times out using the Winget action but works using an admin PowerShell session and the machine scope.
This is rare and can occur if the installer doesn't handle the silent/quiet flag properly. It is not related to Level or Winget, and there's no viable workaround since the installer expects user interaction to proceed, which is not possible because Level runs as the SYSTEM user without a user interface.