Yeah, you can. Set closeOnExit to always.

You can also just set closeOnExit to always in your settings.json.

For those that may not know, closeOnExit is a profile-specific setting. I had to go look up the settings schema docs to verify.

Using exit 0 avoids this behaviour of the Terminal. Yes, cmd is using the exit status of the last external command as the value for exit if you do not supply one.

Sometimes it exits and closes the tab, sometimes not. When it doesn’t close the tab (because of whatever non-zero code or another reason), I propose it should print some clear explanation what process is talked about and why the tab isn’t closed automatically so that I don’t have to google it another time when it happens in a few months…

@raxraj as mentioned earlier in this thread:

Using exit 0 avoids this behavior of the Terminal. Yes, cmd is using the exit status of the last external command as the value for exit if you do not supply one.

You can also just set closeOnExit to always in your settings.json.

Not to beat a dead horse but check the docs: https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-settings#how-the-profile-closes-when-exiting

closeOnExit to always specifically under the profiles.defaults section of settings.json fixed it for me.

Cheers,

Can we have the window close no matter what the code is? I’ve got an SSH client as one of my shells that connects to a machine and when I type “bye” on the remote machine, my window always says

[process exited with code 4294967295]

and won’t close. I honestly don’t care about the code. Just close the window. How can we do that?

(EDIT: Changed so that people don’t think I’m patronizing)

That’s fair. The message should say “the root process, wsl.exe, exited and reported an error code. everything underneath it has been either terminated or detached from the console”.

Sorry, that’s the best explanation we can give. 😄

Entering a nonexistent command then typing exit yields code 9009. I believe Terminal’s broadly incapable of picking up somebody else’s exit code – it’s holding a process handle for CMD, after all 😄

This also happens for me. I can reliably reproduce it with WSL (Ubuntu). How to see the issue:

1. Without typing any command, press CTRL + D -> tab closes
2. Open another WSL tab
3. Type an invalid command (‘frwgufgwe’ should do)
4. Press CTRL + D -> “[process exited with code 127]”

So, the main thing we were combatting is shells exiting immediately on open; it was one of the huge perceived reliability issues in versions pre-0.5 that was largely out of our control. We’ve got a plan on the books to make it more like ConEmu and only show you the message if the process eats it within five seconds of launching, but that one didn’t make the cut for 1.0.

Sorry for being so trigger-happy to call you out. 😄

Yeah, wasn’t trying to be patronizing. Just didn’t know about the always option. Weird that you can set a field to either true or false, or a string value.

Just my opinion, I think “always” would be the preferred default option for most people. I’ve been a Windows user and software developer for over 25 years and couldn’t think of a single instance in that time I wanted to know what exit code a shell or program closed with. I’m sure there’s reasons people would want it, but just seems unnecessary by default.

Thanks for the quick response, though. 😃

I’ve read that closeOnExit is a profile especific feature. Seems not anymore, I’ve edit the settings.json and defined the setting in general (not inside the profiles part) and worked. That should be default behavior.

You will probably find, next time you Save your settings using the UI, that it deletes that key from the general section. It is not expected there, and it will be ignored. 😃