Change:
toolBarLocation: 'floating' | 'docked' | 'hidden'; showInStatusBar: 'never' | 'always' | 'onFirstSessionStart'; internalConsoleOptions: 'neverOpen' | 'openOnSessionStart' | 'openOnFirstSessionStart'; <ins> closeConsoleOnEnd: 'never' | 'always' | 'whenOpenedByDebug'; </ins> extensionHostDebugAdapter: boolean; enableAllHovers: boolean; showSubSessionsInToolBar: boolean;

Discussion:
IMHO the default behavior of the debug console should be as follows: 1) If the console was open before the session was started, it should also stay open after debugging session was ended 2) If the console was closed, the console should open during debugging session and hide again once the users stops the debugging session 3) For maximum flexibility, the user should have an option in the config file to force either to always hide or always leave the console open after the debugging session was stoped. The current behavior keeps the console open after debugging which is super annoying as it takes up valuable screen space and I find myself hitting that close button after every single debugging session...
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.511 --- <!-- score: 0.499 --- <!-- score: 0.481 --- <!-- score: 0.455 --<!-- potentialduplicatescomment --
I was literally searching for that exact same issue! I found , but it was closed and reverted as it may be useful to keep it open sometimes. I would also like the behavior as described here (maybe keeping how it is currently as the default, and make the configurable option have a "Retain previous view" as an option).
Yeah, I also found that but it was quite quickly reverted back to the current behaviour because of this issue: Glad someone else has the same need and regardless of the default behavior, I would also be happy with an option as described by
Interestingly, even thinks () that it should autoclose if it was opened programmatically : Thanks for pointing out !
Thanks for the feature request. I agree with the initial comment and I agree that we can improve. However we need to better define what to do for . Since the default should not be that it opens and closes after 1 second. So I think Debug: Start Without debugging should by default not close it. Once we agree on the desired behavior I would also be open to a PR to fix this. Thus adding help-wanted. fyi on potential feedback
~Is this a new feature? How is that linked to the feature request here?

Personally, I would like the described feature request here to be applied to the regular debugging experience, not only in a "debug-less" mode, as even when debugging, when I'm finished (so when the debugger is detached, for example), the console would close if it was opened by the debugger itself.~ EDIT : I didn't realize there was an option to run a task without the debugger, but like it was said below, they shouldn't be different (although what I strikedout kinda reflected this...) as they are both tasks. If the program runs in 1 second and stops, and an option would be set to close the debugger window on stop, then it should stop no? This is an interesting case, maybe there could be some sort of minimum runtime to be able to close the debug console automatically, say less than 5 seconds? (again, I'm confused by what "Debug: Start Without debugging" is in this context...), but I do believe that the current behavior of not closing up automatically should be kept, as many probably are accustomed to and use the output to further debug their app, even when the debug stopped, but a new option should be (as described here) to close it automatically if wanted. Just to add another point on the table, I feel like this should be a user setting AND a launch task overrideable value, as different task may require the debug console, and others don't. Therefore, a user could setup so his personal taste (setting) is "close" by default, but override it per task to allow greater flexibility.
The request here would mean to implement a new setting, flag or similar which I definitely would consider a "feature request". Imho starting to set timers and doing stuff based on that would be confusing for the user and overly complicated. regarding the Start with and without debugging. Currently, I am seeing the same behavior: The debug console gets programmatically opened if I press f5 or ctrl+f5 and then stays open if I close the session (shift + f5). In my opinion, we don't need to distinguish between the two and should use the same setting and behavior for both modes as they essentially do very similar things: running a task. I would say the simplest solution would be to have an option such as: "consoleOnSessionEnd": "keepOpen" "close". With keepOpen being the default as it is the current behavior.

Sounds good to me I think we can add a setting to enable closing it or matching the original state, but it should stay open by default to avoid confusing users who can't find their program output, especially when their program is fast.
To verify make sure the following setting works as expected for all values
For simplicity decided to go with just a boolean. I do not see a user needing the fine grained distinction between ifOpenedByDebug and always This way it also matches the current setting
Verified this works as expected but it feels kind of odd to me. The experience I would want (and probably enable if it was a setting) would be a "go back to previous state" setting. So if I had the terminal open before I started, go back there. If it was closed, close it. If I had the debug console open, do nothing. Personally I almost always have the bottom panel open and would probably never want it to close, but a 'back' action would be neat. This would also be a very nice interaction with the new debug terminal--you could type commands in the terminal, enter debug mode, and get swapped back to the terminal as soon as the process exits.
agree 100%. I feel like we will have to dump this setting in the future, thus it might have been smarter not to have it all. But now that it is done it is not the end of the world...
I certainly feel like this setting should be kept but the original PR intention should have been kept, in other words, the should not have been removed. I understand that trying to be coherent with already existing settings / for simplicity is very interesting since it gives the settings less complexity overall, but I don't think having this setting as an enum is such an issue. Maybe another setting in that case? I feel like another setting would be too much though. As Rob said in , the default should be to stay open. Why would you want to remove the setting? To remove this feature, or to change the default?