Repository navigation
Regression: wsl ~ works in 7.5 but fails in 7.6 due to tilde expansion and argument mangling #27098
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
Summary
wsl ~ works in PowerShell 7.5 but fails in PowerShell 7.6 due to unexpected tilde expansion and argument mangling
Steps to reproduc
Run the following command in PowerShell:
wsl ~
the command fails with:
/bin/bash: line 1:
D:Users<username>: command not found
Additional information
The issue does not occur in cmd.exe
The issue did not occur in PowerShell 7.5
This suggests a regression or change in native argument passing behavior in 7.6
Workarounds
The following commands work as expected:
wsl --cd ~
wsl "~"
Expected behavior
~ should be passed to WSL and resolved to the Linux home directory (e.g. /home/<user>).
This is the behavior observed in PowerShell 7.5.Actual behavior
In PowerShell 7.6, the command fails with:
/bin/bash: line 1:
D:Users<username>: command not found
It appears that:
1. ~ is expanded by PowerShell into a Windows path (e.g. D:\Users\<username>)
2. The backslashes (\) are stripped or mangled when passed to the native command
3. The resulting string (D:Users<username>) is interpreted by bash as a commandError details
Environment data
Name Value
---- -----
PSVersion 7.6.0
PSEdition Core
GitCommitId 7.6.0
OS Microsoft Windows 10.0.26200
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.4
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Visuals
No response
Activity
mklement0 commentedon Mar 26, 2026
Per https://learn.microsoft.com/en-us/powershell/scripting/learn/experimental-features, the v7.5.x experimental
PSNativeWindowsTildeExpansionfeature was promoted to a stable feature in v7.6.That is, by design, an unquoted
~(either stand-alone or if followed by\or/) now expands to the value of$HOMEon Windows too (using Windows-native directory-path separators, i.e.\), which explains the behavior you're seeing.Thus, use
wsl '~'to pass~verbatim towsl.exeAs an inconsequential aside: it is unclear why the specific command
wsl ~even worked to begin with, given that~is interpreted as a shell command and executing a directory path as such doesn't normally work; for instance,wsl /tmpfails (and even if it worked, it wouldn't enter an interactive session).By contrast, using the
--cdoption works robustly, even with tilde expansion; that is,wsl --cd ~also works in v7.6, but sets the Windows home directory as the working directory (whereaswsl --cd '~'does what you want).rhubarb-geek-nz commentedon Mar 27, 2026
If you start from a basic
cmd.exesession and runIt launches an interactive session. Effectively the tilde has no effect.
However if you use
Which passes all following arguments to the shell, then you get
So wsl itself does not expand the tilde, it is only when it gets passed into bash that it then expands it.
mklement0 commentedon Mar 27, 2026
rhubarb-geek-nz: As noted, it is curious that
wsl '~'works at all, because operands (non-option) arguments are interpreted as the components of a shell command by default - even without explicit--; trywsl '~/foo', for instance, and you'll see that the~gets expanded.In other words: it seems that with everything (that doesn't look like an option) other than a stand-alone
~as the sole argument,wsl ...behaves the same aswsl -- ...; normally,wsl '~'should fail with/bin/bash: line 1: /home/jdoe: Is a directory, but inexplicably doesn't.That said, this is an incidental aspect - a quirk of
wsl.exe; the root cause of the problem at hand is the by-design decision to bring tilde expansion in the context of calling external programs to Windows too (a feature that isn't WSL-specific)mklement0 commentedon Mar 27, 2026
Dongbo Wang (@daxian-dbw), I don't think the interactive WG is the right one for review, given that the feature in question isn't specific to interactive use (it is distinct from how
~tab-completes).In fact, I think
Resolution-By Designis the right label, given that the change in behavior is the result of a previously experimental feature becoming a stable one.daxian-dbw commentedon Mar 27, 2026
I tagged WG-Engine instead. I want the WG to review this issue to measure the impact. It's regression after all.
mklement0 commentedon Mar 28, 2026
Understood, Dongbo Wang (@daxian-dbw). (Strictly speaking, it isn't a regression, though - tilde expansion was never an official feature; it was briefly part of a larger experimental feature that got scrapped).
What makes the
wsl.execase tricky (applies equally to the deprecatedbash.exe) is that~refers to a different home directory than on the Windows side.rkeithhill commentedon Apr 12, 2026
Yet another workaround:
wsl --% ~SeeminglyScience commentedon Apr 20, 2026
The Engine WG discussed this, as described by Michael Klement (@mklement0) above, this is by design.
microsoft-github-policy-service commentedon Apr 22, 2026
This issue has been marked as by-design and has not had any activity for 1 day. It has been closed for housekeeping purposes.