upgrading vscode with multiple instances opened to the same linux remote will cause corrupt installation

Is there an existing issue for this bug?

• I have searched the existing open issues and found none that apply.
• If I find any issue of interest that is related or closed, I will included a link to it in this issue.

Required Troubleshooting Steps

• I have read and performed the troubleshooting steps
• I have tried both values of the remote.SSH.useLocalServer setting
• My issue was not covered in the Tips and Tricks linked from the Troubleshooting Wiki.
• I will include a complete copy of my Remote - SSH logs by running Remote-SSH: Show Log in the command palette or from View > Output in the menu bar

[Optional] Diagnose with Copilot

I did not ask the @remote-ssh participant for help

In step 2 of the troubleshooting wiki, what was the result of running the generated SSH command verbatim outside of VS Code?

I did not try step 2 of the troubleshooting steps

Remote-SSH Log

logs of the instance that got lock:
trigger install - got lock.txt

logs of an instance that was waiting for lock:
trigger install - waiting for lock 1.txt

logs of another instance waiting for lock:
trigger install - waiting for lock 2.txt

Expected Behavior

Note: I work with Hnasar and believe this is the root cause of the issues that were reported in https://github.com/microsoft/vscode-remote-release/issues/10133

The setup: have multiple vscode instances using the Remote SSH extension, all pointing to the same linux remote, but open to different directories. When upgrading vscode, all the instances will attempt to download and untar the installation tarball at the same time, causing corruption. the issue is not that locking isn't working per se. one instance correctly grabs the lock and the others wait for it. rather, the issue is that all the waiting instances see the GET_DOWNLOAD_SERVER_START_TRIGGER (i believe), which causes them to download the installation tarball and untar it, even though they are not the instance that has the lock.

So, the expected behavior is that only the instance that acquired the lock would download and install, and then the waiting instances would ignore the GET_DOWNLOAD_SERVER_START_TRIGGER and proceed after the lock is released and see that there is no installation necessary anymore.

Actual Behavior

See the three logs that i've included in the Remote-SSH Log section. These were generated with the following to clarify what was happening:

joel@atxjoelmacbook2 ~ % diff /Users/joel/.vscode/extensions/ms-vscode-remote.remote-ssh-0.122.0/out/install-script/scripts/linux-exec-server-installer.sh.orig /Users/joel/.vscode/extensions/ms-vscode-remote.remote-ssh-0.122.0/out/install-script/scripts/linux-exec-server-installer.sh
362a363,364
> sleep 15 # NOCOMMIT
> 

see how the two instances that did not grab the lock are waiting, and print out:

Starting to look for password prompt from another window

but once the instance that has the lock proceeds to the part of the script that triggers the installation via echo "${GET_DOWNLOAD_SERVER_START_TRIGGER}", the other instances also see the trigger and start a parallel installation that ends up stepping all over each other. this often manifests with a directory missing, so that there are errors like Error: Cannot find module 'uuid' (for any of the many modules in the installation).

Steps To Reproduce

1. have multiple vscode instances using the Remote SSH extension, all pointing to the same remote, but open to different directories
2. either initiate a vscode upgrade, or simulate a need for a download by, e.g. rm -rf ~/.vscode-server/cli/servers/Stable-591199df409fbf59b4b52d5ad4ee0470152a9b31 on the remote side
3. quit and restart vscode such that all windows re-open at the same time
4. looking at the remote logs for each window, see they are all downloading and un-taring the tarball at the same time, often causing a corrupt installation

Anything else?

Extension version: 0.122.0
VS Code version: Code 1.109.2 (Universal) (591199df409fbf59b4b52d5ad4ee0470152a9b31, 2026-02-10T20:18:23.520Z)
OS version: Darwin arm64 25.2.0
Modes:
Remote OS version: Linux x64 6.6.104.hrtdev
Remote OS version: Linux x64 6.6.104.hrtdev
Remote OS version: Linux x64 6.6.104.hrtdev
Remote OS version: Linux x64 6.6.104.hrtdev

here i also have attached the log files that resulted in a corrupt install directory from an upgrade (without the sleep 15 modification i used in the other log files i posted).

upgrade-got lock.txt

upgrade-waiting for lock 1.txt

upgrade-waiting for lock 2.txt

Start with out/install-script/scripts/linux-exec-server-installer.sh and compare its lock-waiting flow with the attached Remote-SSH logs. Reproduce the upgrade with multiple VS Code instances targeting one Linux remote, then verify that only the lock holder downloads and untars the installation while waiting instances continue after the lock is released without parallel installation.