Change:
private _initializeTerminal(checkRestoredTerminals: boolean) { if (this.isBodyVisible() && this._terminalService.isProcessSupportRegistered && this._terminalService.connectionState === TerminalConnectionState.Connected) { <ins> const wasInitialized = this._isInitialized; this._isInitialized = true; let hideOnStartup: 'never' | 'whenEmpty' | 'always' = 'never'; if (!wasInitialized) { hideOnStartup = this._configurationService.getValue(TerminalSettingId.HideOnStartup); if (hideOnStartup === 'always') { this._terminalGroupService.hidePanel(); } } </ins> let shouldCreate = this._terminalGroupService.groups.length === 0; // When triggered just after reconnection, also check there are no groups that could be // getting restored currently if (checkRestoredTerminals) { shouldCreate &&= this._terminalService.restoredGroupCount === 0; } <del> if (shouldCreate) { this._terminalService.createTerminal({ location: TerminalLocation.Panel }); </del> <ins> if (!shouldCreate) { return; </ins> } <ins> if (!wasInitialized) { switch (hideOnStartup) { case 'never': this._terminalService.createTerminal({ location: TerminalLocation.Panel }); break; case 'whenEmpty': if (this._terminalService.restoredGroupCount === 0) { this._terminalGroupService.hidePanel(); } break; } return; } this._terminalService.createTerminal({ location: TerminalLocation.Panel }); </ins> } }

Discussion:
Whenever I open a project, chances are that a terminal will automatically open because the previous time I opened that project, its window had 1 or more terminals. This doesn't work for me: "feature" is unpredictable. I may open a project 1 week or month later, who remembers if that window had a terminal? 's useless. If I want a terminal I'm a shortcut away from it. If I don't need it however, I have to focus to it and close it. use my extension for managing terminals, I absolutely never need an empty terminal automatically open at startup. What about a option for disabling this?
The reason the terminal is automatically created is because the panel gets restored, which triggers the terminal being created. ever considered the ability to never restore a panel? This request has come before from the Powershell team.
no. We always restore all our ux as it was in a previous session. I do not see why the panel is a sepcial case when compared to the sidebar, activity bar, editor state and so on.
I don't think so. You don't restore: the activity bar (global, non session-specific), status bar (global, non session specific), active activity bar section (it's always "explorer"), the "replace" input field always starts hidden () and probably other things as well. The editor state and sidebar are useful, so it may be the activity bar for some people, but what use does it have a "debug" panel automatically open at startup? Or an empty terminal that automatically opens because when 2 months ago I closed that window it had a terminal visible?
the special case is to avoid creating terminal sessions when the terminal panel is restored as some extensions want to prevent the initial terminal being created. Allowing an empty terminal is another way to workaround the same issue, it's a pretty big change in thinking though.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
could you reopen this please? What kind of "more info" is needed?
I've tried to fix this in an extension, it didn't work. This is what I've tried: Running inside the function. There's no way of knowing if there's actually a terminal open ().

Maybe there's another extension that opens a terminal at startup, we shouldn't just kill it. There's a noticeable delay between the restored terminal opening and then closing. Maybe I could uninstall all my other extensions, or maybe I could rename my extension to "000", or something, ensuring that it's function will be called as soon as possible, but this is not really a solution. Killing all terminals upon shutdown, so that none will be restored the next time that window gets opened It would actually produce the desired effect only after the second opening of that window, unless that's a completely new window. I couldn't find a way to hook into the "shutdown" event, there's the function, but I believe that gets triggered after the actual window is closed, so there's no terminal to kill anymore. Even if there was a way of doing this there's no way of knowing how many terminals are open, if any (). Injecting custom JS with ensuring that the gets executed as soon as possible I couldn't find a way to do it, is VSC actually exporting something to the global namespace that I can use to execute commands? This is a bit annoying to me, and I couldn't find a way of fixing it without patching VSC itself. Is there any update on this? Maybe an option for this could be as part of
If anybody else finds those restored terminals annoying, this is what I'm currently doing for killing them: , needed for injecting some code into VSC. to remove the thing from the titlebar. the following to your settings: the following code to your file:
This is bad, the whole point of the unsupported message is to make it obvious that the source has been modified so the team doesn't have to chase down issues that are caused by people manipulating VS Code's source code - several team members wasted a bunch of time in the past on such problems. In 1.26 you have a ext API (and ) which you can query at any time and kill all of them after launch.
I understand that, but it's also very annoying to me to read that message every single time, if I can remove it I'll do it.

Maybe a suffix could be to the version displayed in the About window instead, maybe this way it will also be more useful because when people get asked which version they are running they'll say instead of just forgetting to mention that they are running a patched version. is not triggered for the restored terminal, or I guess maybe my extension isn't active yet when that happens. I can't fix it with an extension because: I don't think there's a way of knowing if the open terminal has been uselessly restored or maybe opened manually or by another extension, in the latter cases it shouldn't be killed. It takes a while before my extension gets activated and can actually kill the terminal. That piece of code I posted kills the terminal almost instantaneously and only if it's a restored terminal. Of course I would rather just set an option in my settings for disabling panel/terminal restoration, but said option doesn't seem like is going to get implemented.
created to address the annoying part of it
Let's do a setting to prevent this which your users could enable (your extension could have a notification that helps users). The setting (is there a better name for this?) would prevent terminals being created via during launch. I believe this is the code in question:
Thanks for wanting to fix this. I have a couple of questions: Since the thing being restored is actually the panel itself, shouldn't the setting disable that instead? Shouldn't this setting be enabled by default? It's difficult for me to imagine someone wanting to have the panel open at startup, unpredictably (who remembers if last time it was open or not). Regarding the name I see there are already settings like: and so maybe one of these would be good: - is more explicit but at the expense of verbosity
doesn't want that to be a thing for the panel. Plus it makes more sense for this to be a terminal setting as we only want the terminal not to restore, output, problems, etc. should still be restored at normal. The workbench has always restored the state it was previously in, if you had a terminal open it will be open with a new shell to jump into, it's easy to hide/kill. I think being explicit is better here, is too ambiguous and is very similar for example to the setting that was just removed to restore the processes.

The "Debug Console" open at startup is totally useless too, even more so than the terminal. should not restore the panel if the active section is "Terminal", right? Or do you want the panel restored without creating a terminal in it?
the behavior I'm thinking is that a set visible on startup would not create a process and instead hide the panel immediately, allowing extensions to show it again when they activate.
I'm concerned this could cause the panel to get rendered very briefly, effectively flashing it on the screen, which is what I'm seeing with my
is there a way for a panel to abort the panel creation before the DOM is touched? Say allow me to cancel by returning something from ?
no, this is not currently supported. But we could add something to the . Let me know if you think of something elegant
I don't think we're going to add this, however you should be able to kill the terminals much more reliably now by calling on entries in
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 . 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 and guidelines. Thanks for your understanding and happy coding!
A tangential feature to this is persistent sessions, these can be disabled with the following setting:
I would also prefer to not have a restored terminal. When working with python projects, it doesn't restore the virtualenv correctly, so I have to close that terminal and open a new one anyway. I suppose that could be fixed but I'd simply rather not have to deal with it. In general, terminal session restoration seems like a pretty strange feature to me because I most often use terminal sessions ephemerally (with very few exceptions, where I will leave a detached session running) I understand your argument about preserving the UX/layout that was set by the user, but I feel like the bottom panel doesn't really apply well to that. It's not really a static feature of the window that the user always keeps in the same configuration; me personally, I constantly open and close and maximize it depending on my needs at that given time. (e.g.

changing needs of visibility, particularly line count, of the terminal and editor)
the python extension will soon be able to opt-out of the feature which sounds like it might make sense for certain Python terminals. your team might want to adopt this proposal: (it hasn't yet been to the API sync so it could change in early Jan).
Adding my workaround here in case it helps anyone. I have a task that launches two custom terminals when I open the workspace, and while working I use specific keybindings to select terminal 1 or 2. The terminal that automatically launches occupies index 1, throwing off those keybindings. In my case I know that I always want to close terminal 1 before launching my custom ones, so as a workaround I a task that does just that, and set it to run before opening my terminals.
how do i use this "tasks" config, put it in ?
see
got it, thx
It's been a while since our last work and the issue's been bumped already.. So when is the team's next availability to get this one On Deck? VSC wreaks havoc when I want to use Netflix or play a videogame
what do you mean by this? I wouldn't have expected this to cause performance problems.
It's something to do with PowerShell being open that messes with other games and anything running off GPU 0 (3D)
AFAIK the terminal does use GPU rendering also
that's surprising, are you using a low spec GPU? You can disable GPU rendering by setting , your terminals will be noticeably slower but I'd prioritize gaming performance in this case
Is there any workaround for this yet? It's irritating to have the terminal always pop open on restart if I happen to close my editor when I had a Julia REPL still running. I'd be OK with a solution that closes all terminals when I quit VSCode.
I thought about it and went with hideOnStartup in The word "restore" might confuse the user with persistent sessions but the main reason for this was that the panel still gets "restored" by the view system, it just hides almost immediately after and doesn't create a terminal. Early feedback on the setting would be awesome. Here's the definition: