Automatic desktop shortcut remover cannot delete shortcuts from C:\Users\Public\Desktop (Access denied)

[fabergen]

Hello,

I am experiencing a reproducible issue with UniGetUI's automatic desktop shortcut remover.

Environment

• UniGetUI: 2026.2.7
• Windows: Windows 11 Pro 25H2 x64
• Package manager: WinGet

Problem

The automatic desktop shortcut remover is enabled.

The affected shortcut is correctly detected by UniGetUI and is configured to be deleted after an installation or upgrade recreates it.

Example:

C:\Users\Public\Desktop\LibreOffice 26.8.lnk

However, after an update the shortcut remains on the Public Desktop.

UniGetUI detects the shortcut and attempts to delete it, but the deletion fails with "Access denied".

Relevant UniGetUI log

Deleting shortcut C:\Users\Public\Desktop\LibreOffice 26.8.lnk
Failed to delete shortcut {shortcutPath=C:\Users\Public\Desktop\LibreOffice 26.8.lnk}: Access to the path 'C:\Users\Public\Desktop\LibreOffice 26.8.lnk' is denied.

Deleting shortcut C:\Users\Public\Desktop\LibreOffice 26.8.lnk
Failed to delete shortcut {shortcutPath=C:\Users\Public\Desktop\LibreOffice 26.8.lnk}: Access to the path 'C:\Users\Public\Desktop\LibreOffice 26.8.lnk' is denied.

Deleting shortcut C:\Users\Public\Desktop\LibreOffice 26.8.lnk
Failed to delete shortcut {shortcutPath=C:\Users\Public\Desktop\LibreOffice 26.8.lnk}: Access to the path 'C:\Users\Public\Desktop\LibreOffice 26.8.lnk' is denied.

I have also observed the same practical behavior with applications such as Thunderbird when their installer recreates a shortcut on the Public Desktop.

Steps to reproduce
Enable UniGetUI's automatic desktop shortcut remover.
Configure a shortcut under C:\Users\Public\Desktop to be deleted when it is recreated.
Update the affected application through UniGetUI.
Approve the UAC elevation required for the package update.
The installer recreates the desktop shortcut.
UniGetUI correctly detects the shortcut and attempts to delete it.
The deletion fails with "Access denied", and the shortcut remains on the desktop.
Expected behavior

If UniGetUI detects a shortcut during an installation/update and the shortcut is configured for automatic deletion, it should also be able to remove shortcuts located in:

C:\Users\Public\Desktop

If administrative privileges are required for that location, I would expect the shortcut deletion to use UniGetUI's existing elevation mechanism/helper.

Actual behavior

The package update itself can run elevated after UAC approval, but the subsequent shortcut removal appears to run without sufficient privileges.

As a result, shortcuts on the Public Desktop remain even though UniGetUI correctly detects them and is configured to delete them.

Related existing report

There is an older issue containing what appears to be the same Public Desktop deletion error:

[https://github.com/Devolutions/UniGetUI/issues/3670](https://github.com/Devolutions/UniGetUI/issues/3670?utm_source=chatgpt.com)

That issue contains log entries such as a failed deletion of:

C:\Users\Public\Desktop\KeePass.lnk

with an "Access denied" error.

However, issue #3670 was closed as a duplicate of #3615, which concerns repeated UAC/elevation prompts. I could not find a dedicated current report specifically addressing the failure of the automatic shortcut remover to delete shortcuts from C:\Users\Public\Desktop.

Could you please confirm whether this is a known limitation or a bug in the current shortcut-removal/elevation implementation?

Thank you.

[Gabriel Dufresne (GabrielDuf)]

hi fabergen,
Thanks for the detailed report. Your diagnosis is correct, and the logs confirm the issue.

The shortcut cleanup runs in UniGetUI’s main process rather than the elevated process used by the installer. As a result, UniGetUI can detect the shortcut on the Public Desktop but cannot delete it with standard permissions. Approving the UAC prompt for the package update does not elevate the cleanup operation that runs afterward.

I’ve opened a ticket on my side to track this issue and will post an update here once the fix is released.