Microsoft's Visual Studio Code (VSCode) is a free source code editor that supports various programming languages and offers a wealth of extensions. The Remote-SSH extension enhances the VSCode's capabilities by allowing developers to work on the remote execution of code. This is intended to allow the developer to edit/run/debug in the (eventual) target environment or access hardware not present in the local host (e.g., GPUs).
There are several issues with this when the target environment is an HPC cluster:
The clusters currently in production at UD have multiple login nodes balanced via round-robin DNS resolution of a single hostname. With regard to the first point above, the local VSCode application will "remember" the session it previously created and attempt to reconnect to it. But since repeated DNS resolution of the hostname may not produce the same IP address, that session may not always be found — and a new one will be created while the old one persists on a different login node. We often see users accumulate many of these orphaned VSCode remote sessions on our login nodes.
An attempt at proxying VSCode remote sessions through the cluster job scheduler seemed like a worthy project. If the VSCode app's shell commands were forwarded to an interactive job running on a compute node, then the remote execution infrastructure would:
vscode-shell-proxyhas been developed to achieve the above goals. It requires each user to configure VSCode Remote-SSH extension in the application to use vscode-shell-proxy as the command to connect. When configured properly, our tests show using vscode-shell-proxy eliminates the issues stated above for Caviness and DARWIN.
The official public vscode-shell-proxy code repository is available on Github. This visibility means that the proxy can be used by other institutions and organizations, and anyone can raise Issues or submit code changes.
In early 2025, Microsoft began building the binary components of VSCode remote software against Linux OS'es that were much newer than that which runs DARWIN and Caviness. When starting a remote VSCode shell, an error message would be produced regarding the version of glibc1) present versus what Microsoft's binary components require.
A solution was found in online forums, tested, and subsequently integrated into `vscode-shell-proxy` as part of a refactoring of the Python code that was happening at the time. In mid-April of 2025, a `vscode-shell-proxy-new` was installed for testing of the changes (as well as the glibc compatibility fix). In early February of 2026, the changes were released as version 2.0.0 of the utility.