Vscode-remote-release: Dev container workspace stuck "Starting with Dev Container"

[Michaelhobo]

• VSCode Version:

• Local OS Version:
  Version: 1.48.0 (user setup)
  Commit: db40434f562994116e5b21c24015a2e40b2504e6
  Date: 2020-08-13T07:50:42.600Z
  Electron: 7.3.2
  Chrome: 78.0.3904.130
  Node.js: 12.8.1
  V8: 7.8.279.23-electron.0
  OS: Windows_NT x64 10.0.19041

• Remote OS Version: WLinux

• Remote Extension/Connection Type: Docker

My Remote Dev Container workspaces have been occasionally getting stuck at "Starting with Dev Container". It hangs indefinitely, and the terminal shows this output:

[18 ms] Start: Resolving remote
[19 ms] Start: Run: wsl -d WLinux -e wslpath -u \\wsl$\WLinux\home\michaelhobo\repos\rname
[115 ms] Start: Run: wsl 
[118 ms] Start: Run in container: printenv ; exit

I've tried:

• Restarting vscode
• rebooting
• deleting the associated docker container
• deleting the associated docker images
• Reinstalling vscode

No matter what I do, it still gets stuck. All my other workspaces work fine - it happens sporadically.

Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: No

[Michaelhobo]

All my other workspaces work fine - it happens sporadically.

I take this back - my other workspaces are also not working, and are stuck at the same spot.

[byron70]

I was getting a very similar thing just now and pulling my hair out. Did the same steps as @Michaelhobo, but the container would not even attempt to rebuild. Shell server terminated was all I got in the logs.

I finally backed off the Remote Container Extension to v0.128.0 from v0.134.0 and things started to work again.

Odd however, as I had VSCode and all extensions updated 3 days ago and things were fine, and the last Remote-Container extension update was 6 days ago.

[chrmarti]

@Michaelhobo Is WLinux your "default" WSL distro? (One issue I see is that wsl is run without the -d <distro> parameter.)

[Michaelhobo]

@chrmarti yes it's my default

[Michaelhobo]

@byron70 thanks for the tip, I had no idea you could revert to a previous version. I also reverted to 0.128.0 and it's working again

[chrmarti]

@Michaelhobo and @byron70: What is your default shell in WSL? And what do you get when you run the following commands from cmd or PowerShell:

printenv
exit

We run these commands programmatically to read the environment variables from WSL. One slight difference is that when you run them manually you will run them with an interactive login shell whereas when we run them programmatically it is a non-interactive login shell. That might or might not make a difference depending on your .bash_profile and .bashrc files (if you are using bash, other shells have other startup files).

[chucknelson]

Just want to chime in that I'm experiencing the exact same behavior with the Remote - Containers extension versions 0.131.0 to 0.134.0. Rolling back to 0.128.0 works for me, same as @byron70.

@chrmarti - My default shell is bash in wsl, and those commands you list, done in Powershell, result in WSL / bash starting, printing my env vars, and then exiting as expected. Nothing has changed in my WSL setup between extension versions.

---

VS Code version: Code 1.48.0 (db40434f562994116e5b21c24015a2e40b2504e6, 2020-08-13T07:50:42.600Z)
OS version: Windows_NT x64 10.0.19041

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (8 x 3398)|
|GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|31.94GB (19.38GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

Extensions (13)

Extension|Author (truncated)|Version
---|---|---
vscode-eslint|dba|2.1.8
EditorConfig|Edi|0.15.1
Scala|itr|0.1.7
vscode-docker|ms-|1.4.1
python|ms-|2020.8.101144
remote-containers|ms-|0.134.0
remote-ssh|ms-|0.51.0
remote-ssh-edit|ms-|0.51.0
remote-wsl|ms-|0.44.4
vscode-remote-extensionpack|ms-|0.20.0
vscode-typescript-tslint-plugin|ms-|1.2.3
ruby|reb|0.27.0
vscode-ruby|win|0.27.0

[chrmarti]

@Michaelhobo @byron70 @chucknelson Could you try Remote-Containers 0.135.0 (you will need VS Code Insiders to get that version: https://code.visualstudio.com/insiders/) and let me know if you still see this issue?

[chucknelson]

@chrmarti - Thanks - behavior is working again for the most part - the container starts and shutdowns on close as expected.

Whatever changed from prior extension versions, though, has the WSL environment being used to launch things behaving...differently. In my WSL bash startup, I throw out the npm version (i.e., npm --version) just for reference. For some reason this is now failing when the container is trying to start up in VS Code:

[25 ms] Start: Resolving remote
[28 ms] Start: Run: wsl -d Ubuntu -e wslpath -u \\wsl$\Ubuntu\home\chucknelson\development\fliplist
[158 ms] Start: Run: wsl -d Ubuntu
[882 ms] NPM version...
[882 ms] your 131072x1 screen size is bogus. expect trouble
your 131072x1 screen size is bogus. expect trouble
internal/modules/cjs/loader.js:584
    throw err;
    ^

Error: Cannot find module 'C:\mnt\c\Program Files\nodejs\node_modules\npm\bin\npm-cli.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15)
    at Function.Module._load (internal/modules/cjs/loader.js:508:25)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

[887 ms] Command failed: wsl -d Ubuntu

Removing the call to npm --version is what gets things working as expected. I also throw out other versions of things in my bash startup that don't seem to cause any issues, such as java -version, node --version and nvm --version.

Prior extension versions had no issues with my bash startup commands, so not sure what has changed.

[chrmarti]

It looks like your PATH includes NPM from Windows. Is that expected? Could you add echo $PATH just before npm --version in the startup script (.bash_profile?)? What is its output when starting a dev container and what is its output when running wsl manually?

For background: We used to run printenv to read the WSL environment variables without running the shell startup scripts. To also include environment variables from the shell startup scripts (fixing https://github.com/microsoft/vscode-remote-release/issues/3456) I switch over to run wsl and send it printenv over stdin. That runs the default shell as a login shell which typically invokes some startup script (e.g., bash runs .bash_profile).

[chucknelson]

@chrmarti - Ah, you're right, but I think that's expected per default WSL behavior?

https://docs.microsoft.com/en-us/windows/wsl/interop

Windows path is included in the WSL $PATH.

Here is the output comparison running wsl normally versus when the dev container is starting, echoing $PATH before running npm --version:

wsl via Powershell or CMD

PS C:\Users\chucknelson> wsl -d Ubuntu
Path:
/home/chucknelson/.rvm/gems/ruby-2.6.0/bin:/home/chucknelson/.rvm/gems/ruby-2.6.0@global/bin:/home/chucknelson/.rvm/rubies/ruby-2.6.0/bin:/home/chucknelson/.nvm/versions/node/v10.15.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Java/openjdk-8u192-b12/bin:/mnt/c/Program Files/Microsoft MPI/Bin/:/mnt/g/Oculus/Support/oculus-runtime:/mnt/c/Python27:/mnt/c/ProgramData/Oracle/Java/javapath:/mnt/c/Program Files (x86)/Intel/iCLS Client/:/mnt/c/Program Files/Intel/iCLS Client/:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/Program Files (x86)/Intel/OpenCL SDK/3.0/bin/x86:/mnt/c/Program Files (x86)/Intel/OpenCL SDK/3.0/bin/x64:/mnt/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program Files/Intel/Intel(R) Management Engine Components/IPT:/mnt/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/IPT:/mnt/c/Program Files (x86)/Microsoft SQL Server/110/Tools/Binn/:/mnt/c/Program Files/Microsoft SQL Server/110/Tools/Binn/:/mnt/c/Program Files/Microsoft SQL Server/110/DTS/Binn/:/mnt/c/Program Files (x86)/Microsoft SQL Server/110/Tools/Binn/ManagementStudio/:/mnt/c/Program Files (x86)/Microsoft SQL Server/110/DTS/Binn/:/mnt/c/Program Files (x86)/Smart Projects/IsoBuster:/mnt/c/Program Files (x86)/NVIDIA Corporation/Phys:/mnt/c/Program Files/Microsoft SQL Server/130/Tools/Binn/:/mnt/c/Program Files/Microsoft SQL Server/120/Tools/Binn/:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/Anaconda3:/mnt/c/Program Files/Anaconda3/Scripts:/mnt/c/Program Files/Anaconda3/Library/bin:/mnt/c/apache-tools/apache-maven-3.5.0/bin:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Users/chucknelson/AppData/Roaming/nvm:/mnt/c/Program Files/nodejs:/mnt/c/dev-tools/terraform_0.11.14_windows_amd64:/mnt/c/Program Files/PowerShell/6/:/mnt/c/Program Files/Intel/WiFi/bin/:/mnt/c/Program Files/Common Files/Intel/WirelessCommon/:/mnt/c/Program Files (x86)/Yarn/bin/:/mnt/c/HashiCorp/Vagrant/bin:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/ProgramData/DockerDesktop/version-bin:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files (x86)/Microsoft VS Code/bin:/mnt/c/Users/chucknelson/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files/Heroku/bin:/mnt/c/Users/chucknelson/AppData/Local/Programs/Microsoft VS Code/bin:/mnt/c/Users/chucknelson/AppData/Roaming/npm:/mnt/c/Users/chucknelson/AppData/Local/Yarn/bin:/snap/bin:/home/chucknelson/.rvm/bin:/usr/local/go/bin:/home/chucknelson/.rvm/bin
Running 'npm --version'...
6.4.1
chucknelson@chucknelson-pc:/mnt/c/Users/chucknelson$

wsl output from VS code starting container

[20 ms] Start: Resolving remote
[22 ms] Start: Run: wsl -d Ubuntu -e wslpath -u \\wsl$\Ubuntu\home\chucknelson\development\fliplist
[148 ms] Start: Run: wsl -d Ubuntu
[841 ms] Path:
/home/chucknelson/.rvm/gems/ruby-2.6.0/bin:/home/chucknelson/.rvm/gems/ruby-2.6.0@global/bin:/home/chucknelson/.rvm/rubies/ruby-2.6.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Java/openjdk-8u192-b12/bin:/mnt/c/Program Files/Microsoft MPI/Bin/:/mnt/g/Oculus/Support/oculus-runtime:/mnt/c/Python27:/mnt/c/ProgramData/Oracle/Java/javapath:/mnt/c/Program Files (x86)/Intel/iCLS Client/:/mnt/c/Program Files/Intel/iCLS Client/:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/Program Files (x86)/Intel/OpenCL SDK/3.0/bin/x86:/mnt/c/Program Files (x86)/Intel/OpenCL SDK/3.0/bin/x64:/mnt/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program Files/Intel/Intel(R) Management Engine Components/IPT:/mnt/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/mnt/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/IPT:/mnt/c/Program Files (x86)/Microsoft SQL Server/110/Tools/Binn/:/mnt/c/Program Files/Microsoft SQL Server/110/Tools/Binn/:/mnt/c/Program Files/Microsoft SQL Server/110/DTS/Binn/:/mnt/c/Program Files (x86)/Microsoft SQL Server/110/Tools/Binn/ManagementStudio/:/mnt/c/Program Files (x86)/Microsoft SQL Server/110/DTS/Binn/:/mnt/c/Program Files (x86)/Smart Projects/IsoBuster:/mnt/c/Program Files (x86)/NVIDIA Corporation/Phys:/mnt/c/Program Files/Microsoft SQL Server/130/Tools/Binn/:/mnt/c/Program Files/Microsoft SQL Server/120/Tools/Binn/:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/Anaconda3:/mnt/c/Program Files/Anaconda3/Scripts:/mnt/c/Program Files/Anaconda3/Library/bin:/mnt/c/apache-tools/apache-maven-3.5.0/bin:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Users/chucknelson/AppData/Roaming/nvm:/mnt/c/Program Files/nodejs:/mnt/c/dev-tools/terraform_0.11.14_windows_amd64:/mnt/c/Program Files/PowerShell/6/:/mnt/c/Program Files/Intel/WiFi/bin/:/mnt/c/Program Files/Common Files/Intel/WirelessCommon/:/mnt/c/Program Files (x86)/Yarn/bin/:/mnt/c/HashiCorp/Vagrant/bin:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/ProgramData/DockerDesktop/version-bin:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files (x86)/Microsoft VS Code/bin:/mnt/c/Users/chucknelson/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files/Heroku/bin:/mnt/c/Users/chucknelson/AppData/Local/Programs/Microsoft VS Code/bin:/mnt/c/Users/chucknelson/AppData/Roaming/npm:/mnt/c/Users/chucknelson/AppData/Roaming/nvm:/mnt/c/Program Files/nodejs:/mnt/c/Program Files/Intel/WiFi/bin/:/mnt/c/Program Files/Common Files/Intel/WirelessCommon/:/mnt/c/Users/chucknelson/AppData/Local/Yarn/bin:/snap/bin:/usr/local/go/bin:/home/chucknelson/.rvm/bin
Running 'npm --version'...
[841 ms] your 131072x1 screen size is bogus. expect trouble
your 131072x1 screen size is bogus. expect trouble
internal/modules/cjs/loader.js:584
    throw err;
    ^

Error: Cannot find module 'C:\mnt\c\Program Files\nodejs\node_modules\npm\bin\npm-cli.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15)
    at Function.Module._load (internal/modules/cjs/loader.js:508:25)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

[847 ms] Command failed: wsl -d Ubuntu

Weirdest thing I see is the path is in a different order when comparing them?

[chrmarti]

@chucknelson Could you share your .bash_profile and .bashrc? I have an idea of what might be going on.

[chucknelson]

@chrmarti - Sure:

# .bash_profile

[[ -s "$HOME/.profile" ]] && source "$HOME/.profile" # Load the default .profile

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

echo "Path:"
echo $PATH
echo "Running 'npm --version'..."
npm --version

# .bashrc

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
    # We have color support; assume it's compliant with Ecma-48
    # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
    # a case would tend to support setf rather than setaf.)
    color_prompt=yes
    else
    color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

# override default terminal colors where needed
LS_COLORS=$LS_COLORS:'di=01;36:'
export LS_COLORS

PS1="\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;36m\]\w\[\033[00m\]\$ "
export PS1

# Add RVM to PATH for scripting. Make sure this is the last PATH variable change.
export PATH="$PATH:$HOME/.rvm/bin"

[chrmarti]

I assume $HOME/.profile is sourcing .bashrc?

The following at the top of .bashrc is skipping NVM (and all of .bashrc) for non-interactive shells:

case $- in
    *i*) ;;
      *) return;;
esac

We currently run printenv a non-interactive login shell, so your .bashrc is skipped by that. You get your Windows NVM on the PATH due to the WSL interop with env variables you pointed out.

I suggest you move npm --version to the end of your .bashrc when you know NPM in WSL is on the PATH.

[chucknelson]

@chrmarti - Awesome, thanks for looking into that - works as expected. Makes sense with the background you gave in how you're now including shell startup scripts when starting the container in WSL locations. I guess this is pretty "internal" to how containers are started so no public docs to really update either.

I'll go ahead and move my version sanity checks - I'm sure I put them in .bash_profile after reading some random blog or something, haha 😄

Thanks again for all the help - version 0.135.0 of the Remote - Containers extension looks good to me!

---

Wait, I remember now - rvm doesn't work until after .bash_profile runs, so I think I needed that for the ruby version to work, so I just put ALL the version stuff there...anyway, just FYI 😄

[chrmarti]

@chucknelson Sounds good. I'm also looking into making this more robust in case the startup scripts fail and just fall back to the earlier behavior before fixing #3456 in that case.

[byron70]

What is your default shell in WSL? And what do you get when you run the following commands from cmd or PowerShell:

printenv
exit

@chrmarti This lead me to the path of discovery, when running wsl did nothing. My default distro was docker-desktop-data. I don't think I ever set this actually.

Setting the wsl deafult distro to any other distro Alpine, Ubuntu, I am now able to (with Remote-Containers v0.134.0) >Remote-Containers: Rebuild Container and Remote-Containers: Reopen in Container. Which, I wasn't even getting the docker image built previously.

[chrmarti]

To verify:

• Have Docker Desktop for Windows installed with the WSL2 backend enabled for the target distro.
• Set the default distro temporarily (in local PowerShell/cmd): wsl -s docker-desktop-data.
• Remote-WSL: New Windows using Distro... with your previous default distro.
• Append the following to the end your ~/.bash_profile in the WSL distro (assuming bash is the default shell):

case $- in
    *i*) ;;
      *) echo HERE3525; exit 1;;
esac

• Open an empty folder in WSL and Remote-Containers: Reopen in Container.
  
  
  
  • Pick any definition the first time, e.g., Debian.
  
  
• Verify the folder opens in the container (Explorer shows .devcontainer folder and remote indicator says Dev Container ...).
• Verify Remote-Containers: Show Log shows the HERE3525 message followed by 'Exit code 1' (the screen size error can be ignored, use Ctrl + F to search).
  
  
  
  • A WSL error might cause tar to complain about timestamps and flood the HERE3525 out of the terminal buffer. Reload the window in this case (the tar only runs once per VS Code build in each container).
  
  
• Remote-Containers: Reopen in WSL
• Replace the above snippet in your ~/.bash_profile with export HERE3525=true.
• Add the following to your (previously generated) devcontainer.json:

    "remoteEnv": {
        "VERIFY3525": "${localEnv:HERE3525}"
    }

• Remote-Containers: Reopen in Container
• Verify the folder opens in the container and in the integrated terminal echo $VERIFY3525 outputs true.
• Remote-Containers: Reopen in WSL
• Revert the change in your ~/.bash_profile.
• Set the default distro back, e.g. (in local PowerShell/cmd): wsl -s Ubuntu (list with wsl -l -v).

[chrmarti]

The complete fix is published in Remote-Containers 0.136.0, that currently requires VS Code Insiders to run. Looking into publishing in a recovery release for current VS Code 1.48.

[chrmarti]

Published 0.134.1 with the fix for VS Code 1.48.