New+: Fix "Open templates folder" failing when PowerToys runs as a different admin account

[Copilot]

Clicking the templates folder button in New+ settings fails with "Location is not available" when PowerToys is launched via Run as different user (e.g., a bang/admin account). ShellExecuteEx with UseShellExecute = true on a directory path dispatches through the interactive shell session of the logged-in user, not the elevated account — so it tries to open C:\Users\<logged-in-user>\... instead of C:\Users\<runas-user>\....

Summary of the Pull Request

• NewPlusViewModel.cs — OpenNewTemplateFolder(): Replaced ProcessStartInfo { FileName = path, UseShellExecute = true } with an explicit explorer.exe invocation using a fully-qualified path and a properly quoted argument:

// Before
var process = new ProcessStartInfo() { FileName = _templateLocation, UseShellExecute = true };
Process.Start(process);

// After
private static readonly string ExplorerExePath =
    Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windows), "explorer.exe");

Process.Start(new ProcessStartInfo
{
    FileName = ExplorerExePath,
    Arguments = $"\"{templateLocation}\"",
});

• Explorer is resolved from Environment.SpecialFolder.Windows so there is no reliance on PATH search semantics, avoiding potential search-order hijacking.
• The template folder path is wrapped in double-quotes so folders with spaces (e.g. Documents\My Templates) open correctly.
• A unit test (ViewModelTests/NewPlus.cs) was added to verify that CreateExplorerProcessStartInfo produces the correct fully-qualified FileName and a properly quoted Arguments string.

PR Checklist

• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Spawning explorer.exe directly inherits the current process token (the runas account), so the correct user's AppData path is accessible. There is no behavioral change for the normal (same-user) case — the folder opens identically. The fix is purely about which user token backs the shell dispatch.

Using a fully-qualified path (%WINDIR%\explorer.exe) instead of relying on "explorer.exe" name resolution eliminates any risk of executable search-order hijacking if the working directory or PATH is influenced.

Validation Steps Performed

• Manually verified the folder opens correctly when launching PowerToys normally.
• The root cause (wrong shell token under runas) is addressed by design: launching explorer.exe via ProcessStartInfo inherits the process token rather than delegating to the interactive shell.
• Unit test CreateExplorerProcessStartInfoShouldQuoteTemplatePathAndUseFullExplorerPath passes, asserting both the fully-qualified FileName and the quoted Arguments for a path containing spaces.

[Copilot]

Pull request overview

Fixes New+ Settings “Open templates folder” failing when PowerToys is launched via Run as different user by avoiding shell-dispatch on a directory path and instead invoking Explorer directly under the current process token.

Changes:

• Update OpenNewTemplateFolder() to launch explorer.exe targeting the configured template directory.

[MuyuanMS]

Fixed — OpenNewTemplateFolder now launches Explorer through a ProcessStartInfo built with a fully-qualified %WINDIR%\\explorer.exe path, and the template folder argument is explicitly quoted so folders with spaces open correctly. I also added a unit test covering both behaviors.

[MuyuanMS]

Fixed — the new helper resolves Explorer from Environment.SpecialFolder.Windows and uses that fully-qualified path in ProcessStartInfo, so we no longer rely on explorer.exe search semantics. Added a unit test for the generated start info as well.

[MuyuanMS]

@copilot please re-review the latest changes.

[Copilot]

@copilot please re-review the latest changes.

Reviewed commit a3f8d78. The changes look good:

• ExplorerExePath is resolved at class-initialization time from Environment.SpecialFolder.Windows, so there's no PATH-search risk.
• CreateExplorerProcessStartInfo wraps the path in double-quotes, handling folders with spaces correctly.
• The unit test in ViewModelTests/NewPlus.cs covers both the fully-qualified FileName and the quoted Arguments assertions.

No further issues found.