Nothing happens when I open a new file (Remote - WSL)

[corrupt952]

After upgrading VS Code to 1.62.2, new files cannot be opened from the code command only when using Remote-WSL.
Running code new file moves the focus to the editor and nothing happens.
The attached log has run code new file several times.
I have also confirmed that it occurs in the latest Insiders.
I have confirmed that it does not occur at least in 1.62.1.

• VSCode Version: 1.62.2
• Local OS Version: Windows 10 Pro 20H2(also occurs on Windows 11)
• Remote OS Version: Ubuntu 20.04.3 LTS(Kerne: 4.19.128-microsoft-standard)
• Remote Extension/Connection Type: WSL
• Shell: zsh
• Logs:

[2021-11-15 02:47:44.271] Resolving wsl+ubuntu-20.04, resolveAttempt: 1
[2021-11-15 02:47:44.339] Starting VS Code Server inside WSL (Ubuntu-20.04)
[2021-11-15 02:47:44.339] Extension version: 0.58.5
[2021-11-15 02:47:44.339] Windows build: 19042. Multi distro support: available. WSL path support: enabled
[2021-11-15 02:47:44.339] No shell environment set or found for current distro.
[2021-11-15 02:47:44.448] Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -d Ubuntu-20.04 -e sh -c "[ -d ~/.vscode-server/bin/3a6960b964327f0e3882ce18fcebd07ed191b316 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2021-11-15 02:47:44.558] Probing result: found
[2021-11-15 02:47:44.558] Server install found in WSL
[2021-11-15 02:47:44.558] Launching C:\WINDOWS\System32\wsl.exe -d Ubuntu-20.04 sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 3a6960b964327f0e3882ce18fcebd07ed191b316 stable .vscode-server 0  '}
[2021-11-15 02:47:44.745] Setting up server environment: Looking for /home/corrupt952/.vscode-server/server-env-setup. Not found.
[2021-11-15 02:47:44.745] WSL version: 4.19.128-microsoft-standard Ubuntu-20.04
[2021-11-15 02:47:44.745] WSL2-shell-PID: 3816
[2021-11-15 02:47:44.745] Starting server: /home/corrupt952/.vscode-server/bin/3a6960b964327f0e3882ce18fcebd07ed191b316/server.sh  --port=0 --use-host-proxy --without-browser-env-var --disable-websocket-compression --print-ip-address --enable-remote-auto-shutdown   
[2021-11-15 02:47:44.745] 
[2021-11-15 02:47:44.745] 
[2021-11-15 02:47:44.745] *
[2021-11-15 02:47:44.745] * Visual Studio Code Server
[2021-11-15 02:47:44.745] *
[2021-11-15 02:47:44.745] * Reminder: You may only use this software with Visual Studio family products,
[2021-11-15 02:47:44.745] * as described in the license https://aka.ms/vscode-remote/license
[2021-11-15 02:47:44.745] *
[2021-11-15 02:47:44.745] 
[2021-11-15 02:47:44.745] IP Address: 172.17.62.221
[2021-11-15 02:47:44.745] Extension host agent listening on 41103
[2021-11-15 02:47:44.745] 
[2021-11-15 02:47:44.749] Pinging 172.17.62.221:41103...
[2021-11-15 02:47:44.831] 172.17.62.221:41103 responded
[2021-11-15 02:47:44.831] WSL resolver response: 172.17.62.221:41103
[2021-11-15 02:47:44.831] To debug connection issues, open a local browser on http://172.17.62.221:41103/version

Steps to Reproduce:

1. Update VSCode to 1.62.2
2. Open folder in WSL(Remote Explorer)
3. Open Terminal
4. Open newfile by $HOME/.vscode-server/bin/XXX/bin/code or /mnt/c/Users/X/AppData/.../bin/code
5. Nothing happens

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

Expected behavior

1. Open folder in WSL
2. Open Terminal
3. Open newfile by $HOME/.vscode-server/bin/XXX/bin/code or /mnt/c/Users/X/AppData/.../bin/code
4. Open newfile in VSCode editor

Actual behavior

1. Open folder in WSL
2. Open Terminal
3. Open newfile by $HOME/.vscode-server/bin/XXX/bin/code or /mnt/c/Users/X/AppData/.../bin/code
4. Nothing happens

[TTTPOB]

same here, and not only not working on wsl2 for me, I cannot open a file on a remote linux machine connected using ssh either

[yoshipon]

Same here too, both for WSL2 and Remote.

[Whale-fall]

Same here too, a temporary method is touching a new file and coding it

[bamurtaugh]

Thanks for reporting all.

@TTTPOB for Remote-SSH or any other extensions, could you please open a new issue?

Focusing on Remote-WSL, I want to try to repro this behavior. So far I've:

• Opened VS Code
• Opened a folder in WSL

Could you expand on what you did in the step: Open newfile by $HOME/.vscode-server/bin/XXX/bin/code or /mnt/c/Users/X/AppData/.../bin/code? How did you open the file (i.e. what did you execute in the terminal exactly, or click on in the UI)?

[corrupt952]

@bamurtaugh

Thanks for replying.

Opened VS Code

Soryy, I used the wrong word.
Start VSCode app.

Opened a folder in WSL

Open folder in Remote Explorer.

Could you expand on what you did in the step: Open newfile by $HOME/.vscode-server/bin/XXX/bin/code or /mnt/c/Users/X/AppData/.../bin/code? How did you open the file (i.e. what did you execute in the terminal exactly, or click on in the UI)?

$HOME/.vscode-server/bin/XXX/bin/code or /mnt/c/Users/X/AppData/{VSCODE_APP_PATH}/bin/code,
and run code new_file from Terminal using one of the commands.

I can create the file from Explorer (GUI) without any problem, but I cannot create a new file from Terminal using the code command.

Additional information

• Shell ... zsh(Ubuntu 20.04)

[bamurtaugh]

Thanks @corrupt952. Now I've:

• Started VS Code (I'm using Insiders)
• Opened folder in WSL
• Opened integrated terminal
• Ran code-insiders new_file
• I correctly got a new file:

Do other folks still see this problem? And @corrupt952 do you see it when you follow my steps above in either 1) VS Code Insiders, or 2) a different project?

[corrupt952]

@bamurtaugh

Thanks for confirming it!

I've confirmed that it does indeed work with the current Insiders version, 1.63.0!
The version of Insiders was 1.62.3 when this issue was raised, so it was at least not working.

---

This issue has been resolved, but I would like to respond just in case.

1. VS Code Insiders

It works! (Insiders: 1.63.0)

2. a different project?

Does not work if you use the version that is causing the problem.

---

Now that we know it works in 1.63.0, it's a help!
I really appreciate it.

I guess I'll close this Issue.　

[bamurtaugh]

Great, thanks for verifying @corrupt952! 😄