`sudo -N` should preserve the current directory

Sudo for Windows version

1.0.0

Windows build number

10.0.26063.1

Other Software

No response

Steps to reproduce

According to my tests, the general expectation regarding sudo is that it preserves the current directory.

If you run sudo rm * or sudo del *.* the user would expect to affect files in the current directory.
If you do sudo notepad ./filename, the user expects that the path resolves relative to the current directory.

But currently:

• when -N is used
• or sudo is configured in forceNewWindow mode

... then the current folder is set to C:\WINDOWS\System32 instead

• Except if sudo is run from an already elevated console. (then it preserves the current directory)

For example

C:\test> del /P *.*
C:\Test\test-file.txt, Delete (Y/N)? Y
Access Denied

C:\test> sudo del /P *.*
C:\Test\test-file.txt, Delete (Y/N)? N

C:\test> sudo sudo config --enable forceNewWindow
Sudo mode set to Force New Window mode

C:\test> sudo del /P *.*
# a new window appears with:

C:\Windows\System32\07409496-a423-4a3e-b620-2cfb01a9318d_HyperV-ComputeNetwork.dll, Delete (Y/N)?

See:

I know you mentioned this was by-design. IMO that design choice should be reconsidered. This is not just unpredictable and inconvenient... In these edge cases it can also be dangerous.

Expected Behavior

Sudo should preserve the current directory, regardless of being invoked from an elevated process, a non-elevated one, with or without -N, and with any configuration mode.

Actual Behavior

Sudo preserves the current directory depending on the -N argument, the config mode, or the elevation status of the caller.

Start by tracing how the Windows implementation handles the -N argument, forceNewWindow mode, and the caller's elevation status. Reproduce the commands from the issue in each combination and identify where the working directory becomes C:\Windows\System32. Done means sudo preserves the invoking directory in all listed cases, with coverage for the reported behavior.