Repository navigation
Support cross-host R sessions with sess #1763
Description
Activity
- marked Did not receive a response from VSCode-R API within 5 seconds #1019 as a duplicate of this issue
on Sep 23, 2026 - marked Allow the R
.vsc.attach()function to connect by TCP to VSCode - supporting remote R sessions #1359 as a duplicate of this issueon Sep 23, 2026 - marked Session watcher should not rely on pid #1391 as a duplicate of this issue
on Sep 23, 2026 - marked Inability to Attach active R terminal on Compute Nodes in HPC Environment #1541 as a duplicate of this issue
on Sep 23, 2026 - added a commit that references this issue
on Sep 26, 2026 #1764 establishes useful prerequisites: stable session IDs, explicit endpoint/discovery metadata, and the public session API. It still uses local Unix sockets / Windows named pipes and does not establish supported cross-host attachment.
Cross-host identity/discovery and forwarding or another transport still need implementation and validation, including the case where the extension host runs on a login node and R runs on a compute node. Persistent Interactive sessions on the same remote host do not cover that separation.
Keeping this open for the cross-host functionality.
There have been repeated requests to attach vscode-R to an R session running on a different host from the VS Code extension host, particularly in HPC environments where VS Code runs on a login node while R runs on a scheduler-allocated compute node.
Related issues include #469, #1019, #1047, #1276, #1359, #1391, #1506, and #1541.
Historically this was difficult because the session watcher depended on shared files, file watchers, and local process IDs.
With the new sess architecture, communication is now bidirectional JSON-RPC over a stream socket.
This should make cross-host sessions feasible in the future, for example through SSH socket forwarding or an additional TCP transport, without changing the higher-level session protocol.
I don't think vscode-R needs to manage SSH, Slurm, or other schedulers itself.
The useful boundary would be simply allowing sess to connect when the R process and the extension host are on different machines.