Restore terminal sessions between restarts

[Tyriar]

Forking off from #20013, this issue is about restoring the terminal process shell, args, env and layout (dropdown/splits).

[fabiospampinato]

I'm posting my thoughts about this, since I've tackled this issue with my Terminals extension.

this issue is about restoring the terminal process shell, args, env and layout

Restoring shell, args and env: I might be wrong on this but I think one can't even set these variables on a per-terminal basis when creating terminals manually, so we would be either restoring terminals with default shell, args and env (nothing to restore basically), or terminals created by extensions, which are going to get recreated by those extensions anyway (there's no way of getting a list of opened terminals, so those extensions can't re-use restored terminals even if they wanted to).

Restoring layout: this is certainly useful, but I personally don't like if throwaway/temporary terminals get restored. And there's no way of knowing which terminal is important and which isn't without providing some kind of configuration.

it would be good to have some basic restoring if it won't get in the way, we certainly wouldn't want to add the complexity that this extension allows.

IMHO the real value comes from restoring commands as well as the layout, and possibly outputs too. Given the relatively low value of a restored layout without commands/output and the problem with duplicated terminals that get recreated by extensions I think it's not worth implementing this into the core.

I need to do some thinking about it, how it interacts with tasks and debug

I personally don't use tasks at all, and I'm not sure how terminals have anything to do with debug, what do you mean exactly?

While we're at it, these are a few API suggestions that would allow me to provide a more powerful/complete extension:

• Output restoration: It would be cool if we could restore the output of the terminals, for doing so I think a couple of APIs for reading and replacing a terminal's content are necessary.
• Splits restoration: As mentioned here an API for splitting terminals would be necessary in order to add this functionality.
• Listing all the terminals: Providing an array of all the opened terminals could be useful.

[Tyriar]

I personally don't use tasks at all, and I'm not sure how terminals have anything to do with debug, what do you mean exactly?

You can have debuggers run their processes inside the terminal, I think the main benefit here is you get to see the stdout of the process.

Output restoration

While possible to do, I'm not convinced this would be useful if the process needs to be recreated?

Splits restoration

I think we need this #45407

Listing all the terminals

#13267

[fabiospampinato]

I'm not convinced this would be useful if the process needs to be recreated?

I think it depends on the output, for my use cases this wouldn't be particularly valuable either, but maybe it would be useful for all those times one finds himself scrolling back the terminal.

[M-Zuber]

Other than my 👍 , the only thing I would want to ask for is to extend this from just restarts into having configurations associated with workspaces/folders

Which of course, @fabiospampinato's extension does wonderfully, but if we end up with an "official" api for this, it could enable core and/or other extensions to hook into the functionality.

[Tyriar]

The result of the investigation this iteration is:

• There are developments for serializing and restoring state in various UI components, we may use the same model as that for the terminal
• We may want to defer this behavior to extensions as the most compelling restore behavior comes when you can automate the creation of terminals that run commands like https://marketplace.visualstudio.com/items?itemName=fabiospampinato.vscode-terminals
• We should wait until after grid layout Support a grid layout for editors #14909 for the splitting API Add an API for specifying terminal location #45407

[bpasero]

@Tyriar my biggest use case is to reconnect to a running "npm run watch", is that covered here or should I file a new issue? This is to get rid of tmux finally...

[Tyriar]

@bpasero that's this one #20013, the current thinking there is might be a lot of work to re-architect where the terminal process lives for not much payoff (QoL for team and people who change extensions a lot).

[bpasero]

@Tyriar the payoff is that the VS Code team could selfhost on the integrated terminal without tmux (which brakes basically everything), so I would give it a shot :)

[Tyriar]

I'm planning on removing the experimentalRestore setting in August.

[Tyriar]

I removed the experimentalRestore setting as I don't think it's the direction we're going to go in and I'm concerned about bugs/stability issues it could be causing.

[brunoborges]

Confirming that if I have a Java process running in the terminal, after a window reload (e.g. installed an extension) the Java process remains running but now in the background, and a new blank terminal loads in the window.

• Using Mac OS and latest VS Code as of the date of this comment.

// @hexiaokai @Matthew-Dong

[Tyriar]

@brunoborges please create an issue with repro steps and OS/vscode version details.

[brunoborges]

@Tyriar Isn't the issue the same?

[Tyriar]

@brunoborges aren't you pointing out this:

Java process remains running but now in the background

The process should be killed?

This issue is a feature request about retaining terminal processes across window reload, currently the expected behavior is to kill all terminal processes.

[brunoborges]

The process should not be killed. And the terminal should be retained.

[Tyriar]

@brunoborges for that behavior is this feature request. Until this issue is handled, all the processes are meant to be killed when you close VS Code, you indicated that this is not the case currently.

[brunoborges]

@Tyriar That is correct. But I'd rather see this feature implemented than that bug fixed. Priorities :)

[wallzero]

First step should be to reopen VSCode and have restored terminals, their names, and paths. If the processes have to be killed and restarted then that can the second step. I can live with restarting my processes if I have to but reopening my terminals and going to the correct paths is time consuming.

[mrfloppi]

@Tyriar So what's the status on this 🙂 Still split terminals don't get restored on restart.

[Tyriar]

We have no plans on restoring sessions like this as the experiment I built earlier ended up revealing it would be a lot of code/config to get this right. Instead we're opting for extensions like Terminals Manager to take up this role which will be able to cater to complex setups better. Currently the API is limited in this area around splitting, vote on #45407 to help bump that up.

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[EthanSK]

I made an extension to do just this https://marketplace.visualstudio.com/items?itemName=EthanSK.restore-terminals

[artm]

All the extensions proposed as solutions expect me to decide in advance which terminals I want opened with a workspace. What I want is that terminals I have started are restarted the next time I open the workspace. Basically I would like the terminals to be a part of the workspace state just like opened files.

[Tyriar]

@artm they should be now? See https://code.visualstudio.com/docs/terminal/advanced#_persistent-sessions

[artm]

Hmm, doesn't seem to do much for me: I use WSL terminals, after restart one of them might have contents of the last session restored, but I never get multiple terminals back

[Tyriar]

@artm it's working for me in both local and wsl windows. Do you input in them when you're testing? Because they only get restored if they had some interaction. Please create another issue with this info as you might be referring to a new bug.