PSNativeWindowsTildeExpansion breaks commands like wsl bash ~/run-task.sh, add option for disabling #28183

Activity

1. Arnav Bhate (arnavbhate)

   added

   Needs-TriageThe issue is new and needs to be triaged by a work group.The issue is new and needs to be triaged by a work group.

   on Oct 10, 2026
2. mklement0 commented on Oct 10, 2026

   

   Michael Klement (mklement0)

   on Oct 10, 2026

   Contributor

   More actions

   Duplicate of the following, which was closed as by-design:

   • Regression: wsl ~ works in 7.5 but fails in 7.6 due to tilde expansion and argument mangling #27098

   Quote paths to avoid the problem; wsl bash '~/run-task.sh' in your case.
3. arnavbhate commented on Oct 10, 2026

   

   Arnav Bhate (arnavbhate)

   on Oct 10, 2026

   Last edited by arnavbhate

   Author

   More actions

   Not entirely duplicate, clarified title
4. Arnav Bhate (arnavbhate)

   changed the title [-]PSNativeWindowsTildeExpansion breaks commands like `wsl bash ~/run-task.sh`[/-] [+]PSNativeWindowsTildeExpansion breaks commands like `wsl bash ~/run-task.sh`, add option for disabling[/+] on Oct 10, 2026
5. mklement0 commented on Oct 11, 2026

   

   Michael Klement (mklement0)

   on Oct 11, 2026

   Contributor

   More actions

   To clarify:

   • Your issue was submitted as a bug report, and as such it is a duplicate of Regression: wsl ~ works in 7.5 but fails in 7.6 due to tilde expansion and argument mangling #27098

   • It sounds like it should have been submitted as a feature request; because it wasn't, it lacks the Issue-Enhancement label (which I personally cannot add).

   • As for the nature of your feature request:

     • It sounds like you're looking to have the option to deactivate a formerly experimental feature, PSNativeWindowsTildeExpansion, which became a stable, unconditional one in v7.6, and you presumably want that option to be implemented in the form of a yet to be introduced new preference variable (if not, please clarify).

     • As noted, ad hoc you can simply use quoting to deactivate the feature.
6. arnavbhate commented on Oct 11, 2026

   

   Arnav Bhate (arnavbhate)

   on Oct 11, 2026

   Last edited by arnavbhate

   Author

   More actions

   Not a duplicate because wsl ~ shouldn't work, but it used to. But this should work, and it doesn't. The option is a method I am suggesting to resolve the bug, but not the only one.
7. mklement0 commented on Oct 11, 2026

   

   Michael Klement (mklement0)

   on Oct 11, 2026

   Last edited by mklement0

   Contributor

   More actions

   wsl ~ shouldn't work, but it used to. But this should work, and it doesn't.

   The form wsl ~ is incidental to the problem at hand; the root cause is the same as with your command form, wsl bash ~/run-task.sh, or any other form involving unquoted, argument-initial ~ (either ~ in isolation or if followed by / or, on Windows, alternatively \):

   • The intentional behavioral change to make PowerShell itself expand unquoted, argument-initial ~ to the path of the current user's home (profile) directory up-front, on Windows too, introduced in v7.6, whereas up to v7.5 ~ was passed through as-is to the target program.

   As such, there is no bug, only an intentional change, as implied by the resolution of #27098 - notwithstanding the fact that it is possible that it wasn't anticipated that the change amounted to a breaking one in the context of Unix-like CLIs on Windows, notably wsh.exe and bash.exe, which need to do their own interpretation of ~, differing from PowerShell's.

   ---

   • If your argument is that the new behavior is a bug nonetheless, I suggest you elaborate, especially with a view to demonstrating real-world impact.

     • Should the team agree with your assessment, the only way to fix the problem without removing the new feature altogether would be to introduce a "blacklist" of Unix-like CLIs to which the new feature should not apply.
     • Such an approach is obviously fraught (it's impossible to anticipate all relevant CLIs, both currently and going forward). That said - for better or worse - it has been done before, in the form of a whitelist in the context of the $PSNativeCommandArgumentPassing preference variable

   • Asking for a configuration option (e.g. via a preference variable) to revert to the old behavior is at odds with considering the new behavior a bug, however; as noted, it amounts to a feature request.

     • Here too it would help your case if you elaborated on the exact implementation of the desired configuration option.
     • That said, my personal sense is that this unlikely to be implemented, given the narrow use case, the potential to affect other code, and the fact that an ad hoc solution is very simple (quoting, as discussed).

   The more specific your request / arguments are, the more likely they are to be reviewed by the relevant working group.
   (Note that as of this writing the issue isn't even tagged as needing working-group review.)