Since upgrading to Windows 11 Insider Version 10.0.26120 Build 26120, I’ve noticed that any program set to start automatically at login (via registry “Run” or the Startup folder) fails to launch if the target path is a symlink—for example, using Scoop’s current symlink or one created with mklink.
Details:
- These startup entries work fine if I launch them manually from Explorer (symlink resolves perfectly).
- System services using the same kind of symlinked path (e.g. the Everything service) do launch at boot.
- This started immediately after the last Windows Insider update.
- Disabling/enabling Windows Search (WSearch) does not resolve it.
- It only affects user-context startups (interactive login), not SYSTEM or services.
Steps to reproduce:
- Create a symlinked folder (e.g.,
mklink /D current 1.2.3). - Place a shortcut or set a registry Run entry to point at
currentMyApp.exe. - Reboot and log in.
- The app does not launch at login, but works if you run it manually from Explorer.
System:
- Windows 11 Insider Version 10.0.26120 Build 26120
- Scoop v0.5.2 (package manager for Windows)
- PowerShell 7.5.2
- WSearch disabled (but toggling it does not fix)
- Local user account (not Admin)
Is anyone else seeing this? Is this a new Windows security or policy change affecting symlink resolution in user startup context? Is there a known workaround or a way to restore the previous behavior?
