vscode: Resolve shell environment failed on 1.62.1
The shell environment no longer resolves correctly in remote terminals in 1.62.1.
A possible workaround is to manually source the shell env in remote terminals
source ~/.bashrc
Another workaround is to downgrade to 1.62.0
- configure
"update.mode": "none"
and install1.62.0
: - win x64: win32-x64-user | win32-x64 | win32-x64-archive
- win ia32: win32-user | win32 | win32-archive
- win arm64: win32-arm64-user | win32-arm64 | win32-arm64-archive
- macOS: macOS x64 | macOS arm64 | macOS Universal
- Linux 64: linux-x64 | linux-deb-x64 | linux-rpm-x64 | linux-snap-x64
- VS Code Version: 1.62.1
- OS Version: Windows 10 21H1 / WSL2 / Ubuntu 20.10
After updating from 1.62.0 to 1.62.1, the full shell environment under WSL2 isn’t loaded.
- Aliases from .bashrc work normally
- Additional configuration files like .profile are not loaded
The remote server log shows the following errors:
[2021-11-09 22:18:30.906] [remoteagent] [error] ptyHost was unable to resolve shell environment {}
[2021-11-09 22:18:31.090] [remoteagent] [error] ExtensionHostConnection#buildUserEnvironment resolving shell environment failed {}
Rolling back to 1.62.0 solves the problem
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 20
- Comments: 27 (9 by maintainers)
This will be available in
1.62.2
which is set to release Thursday PST this week, if there are any last minute candidates then the release will be pushed to next Tuesday PSTI am having the same issue with SSH Remote workspace after updating VS Code to 1.62.1
I am having what appears to be the same issue with a SSH Remote workspace on the latest release. My .bashrc is sourced, but my .bash_profile no longer is. It seems the terminal no longer inherits the environment.
Before updating VS Code today, I have never had this problem. (Is there any easy way to temporarily downgrade VS Code (on Windows), btw?)
@Stanzilla It should. Check out the WSL log for the entry
Using shell environment from invoking shell
. Setting"remote.WSL.debug": true
will give more information about the env variables that are read and set. Please file a new issue if it doesn’t work.Verification steps:
~/.bash_profile
and some simple statement likeexport TEST="hello"
New WSL window
from command paletteecho $TEST
hello
Chiming in: took me a while to figure out why my Go setup that has been working for years suddenly wasn’t working, and it’s this bug; pathing sourced from
.profile
was no longer working. Rolling back to 1.62.0 fixed my issues.Also impacting tasks in WSL: https://github.com/microsoft/vscode/issues/136799
WSL2 Ubuntu seems to be having some severe regressions with the release of v1.62.1 - I just filed https://github.com/microsoft/vscode/issues/136809 and I see that https://github.com/microsoft/vscode/issues/136799 is also WSL2 ubuntu-related - each seems to be issues related to SSH/connections via either the terminal or otherwise.
Hopeful someone at Microsoft can take a look soon! 😃