Repository navigation
Open
Labels
feature-requestRequest for new features or functionalityRequest for new features or functionalityplan-reviewPM-highlighted item determined to be P1 or P2PM-highlighted item determined to be P1 or P2remoteIssues in the code server supportIssues in the code server supportsshIssue in vscode-remote SSHIssue in vscode-remote SSH
Milestone
Description
A lot of users of our Julia extension love the remote SSH features, they are super useful in a scientific research computing context!
One thing that has come up a lot lately, though, is that folks want an ability to have a persistent session on a server that they can disconnect from and then reconnect to way later.
The scenario is essentially something like this:
- User connects to some remote server via the Remote SSH extension
- They do some work
- They get interrupted and close their local VS Code instance
- They do something else for a couple of days
- The now want to reconnect to the server, and ideally nothing was shut down on the server. For example, if they opened a REPL in step 2 and started a Julia instance in that REPL, it would still be running, and was never shut down. Similarly with pretty much all other runtime state they had.
I think this might be related to #440, but what I'm really asking for is not just an option to change the timeout, but some way to make the timeout infinit, so that the server session never shuts down.
This might also require some kind of UI, maybe a command like "Disconnect but keep server alive" or something like that, not sure.
Reacted by Gerhard Aigner, agerlach, otobrzo, Marius Millea, Andrew Steck, David Little, John Travers, Brian Chen, AriMKatz, Gauthier Soleilhac and 553 more
Reacted by gpastal24, Alan Guedes, aoliong, G-S-Paris, Krishna Vishal, cossio, Victor L., Hunter Wilhelm, Zhuoqun Chen, Haithem Khelif and 5 more
Reacted by João Vitor Borges, Janosh Riebesell, Quyu Kong, cavallonechen, G-S-Paris, Michiel Dral, David Rees, Ryosuke Horiuchi, Luis Gustavo Lorgus Decker, Oskar Laverny and 21 more
Reacted by Siva, Azamat Berdyshev, Wen Wei Tseng, Josef, Kyle Daruwalla, Anton Isopoussu, leonardschneider, Janosh Riebesell, João Vitor Borges, tom-programming and 59 more
Reacted by João Vitor Borges, Quyu Kong, Andrea Tagliasacchi, G-S-Paris, Ryosuke Horiuchi, Luis Gustavo Lorgus Decker, Oskar Laverny, Adrian Garcia Badaracco, Yeasin Mollik, Miguel Caçador Peixoto and 23 more
Reacted by João Vitor Borges, G-S-Paris, Ryosuke Horiuchi, Luis Gustavo Lorgus Decker, Oskar Laverny, Adrian Garcia Badaracco, Yeasin Mollik, Miguel Caçador Peixoto, Amit Karamchandani Batra, Alexey Zaytsev and 22 more
Metadata
Metadata
Assignees
Labels
feature-requestRequest for new features or functionalityRequest for new features or functionalityplan-reviewPM-highlighted item determined to be P1 or P2PM-highlighted item determined to be P1 or P2remoteIssues in the code server supportIssues in the code server supportsshIssue in vscode-remote SSHIssue in vscode-remote SSH
Activity
xgdgsc commentedon Jun 4, 2020
#1790 also related.
EricChen1248 commentedon Jul 15, 2020
Not a perfectly solution, but what about opening the terminal into Screen. Users could reconnected back to their screen session each time, also gives more fine grain control over resource releases (properly terminating a process vs an always persistent session)
PavelSosin-320 commentedon Jul 15, 2020
This is a well-known pattern in the Cloud Applications. The problem is always that lifecycles of Server and client are not synchronized and either server or client or connection can go down at any point all clients will hang. Then, clients have to re-authenticate. If the client is idle at the point of time was idle its user will have no knowledge of how to proceed. To avoid such a died-end situation client needs awareness of the "session status" i.e. Server needs session management and ability to report either current session status to the client, at least, by the explicit client's request or every re-connect request coming from the client has had session attribute. There is also a security risk that the session can be hijacked by anybody who has a valid login of the server when the client was idle.
vscode-triage-bot commentedon Nov 6, 2020
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
vscode-triage-bot commentedon Nov 6, 2020
🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
janosh commentedon Feb 16, 2021
Glad I found this! Just wanted to mention that I believe this is far larger in scope than the Julia extension. I bet most people forced to work from home these days would really appreciate this feature!
bobaoapae commentedon Feb 17, 2021
This is what i need for stop using RDP to remote developmet. Sometimes i need keep service runing for several days and i don't want keep my own pc on just for it. Keep process running without vscode remain connected and re-establish connection/state after re-open vscode will be amazing!
tom-programming commentedon Feb 25, 2021
This would be a real game changer for myself, and I believe, a whole lot of people. Now I use tmux to achieve the same but it is uncomfortable in many ways
84 remaining items
tsuna commentedon Feb 28, 2026
I run remote-ssh over quicssh to work around this issue and also have my SSH sessions survive IP address changes that can happen along the way.
fehmi commentedon Mar 22, 2026
Me also tired of manual reloading.
CherryDT commentedon Apr 2, 2026
It is very annoying that this happens on WSL (not SSH - but issue #10767 was redirected here) after waking computer now all the time. It used to work fine.
fehmi commentedon Apr 3, 2026
The issue is not even in the backlog yet.
CherryDT commentedon Apr 3, 2026
For WSL it's a regression though... :(
charles-cai commentedon Apr 29, 2026
lost in the chat history, so 6 years down the line, where are we?
probably devtunnels is the way to go? https://aka.ms/devtunnels above which was posted in 2023, sigh
youngdjn commentedon Apr 29, 2026
For data scientists using Python or R specifically, the excellent VS Code fork Positron supports long-running SSH sessions.
joelsandocu commentedon May 19, 2026
This would be a very useful feature, +1,000,000 votes!
tsuna commentedon Jun 27, 2026
I could implement this easily if the extension was open source. Does anyone know why it's kept closed source?
cristianocca commentedon Sep 18, 2026
+100
unleex commentedon Oct 11, 2026
any temporary solution or a crutch, at least?
jodjo86 commentedon Oct 14, 2026
Has anyone tried Persisterm as a workaround for this issue? It seems to provide exactly the persistent SSH terminal experience we're looking for. I'd be interested to hear about its reliability and any potential drawbacks.
mmis1000 commentedon Oct 16, 2026
POC Images
Using vscodium and open-remote-ssh as base.
I vibed it with claude and chatgpt for POC for experiment.
Added
It turns out
vscode.Serverand vscode client interface changePOC url
https://github.com/mmis1000/ssh-remote-experiment
https://mmis1000.me/ssh-remote-experiment/
the page contains
datadir next toVSCodium.exeso it become portable and not pollute you system/user dirLimit of POC