exit doesn&#39;t reliably close the tab #7252

@ghost commented on GitHub (Apr 1, 2020):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Apr 1, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

claunia commented

@DHowett-MSFT commented on GitHub (Apr 1, 2020):

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 😄

@DHowett-MSFT commented on GitHub (Apr 1, 2020): 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 :smile:

claunia commented

@randomascii commented on GitHub (Apr 1, 2020):

Ah. Exit codes indeed. Trying to run a nonexistent command and then type exit gives 9009. Typing "where asdfasdf" and then typing exit gives exit code 1. And so on.

"where asdfasdf" followed by "where notepad" followed by "exit" works (closes the tab)

@randomascii commented on GitHub (Apr 1, 2020): Ah. Exit codes indeed. Trying to run a nonexistent command and then type exit gives 9009. Typing "where asdfasdf" and then typing exit gives exit code 1. And so on. "where asdfasdf" followed by "where notepad" followed by "exit" works (closes the tab)

claunia commented

@ossdesign commented on GitHub (Apr 4, 2020):

I came here to search in regards to this one, as have been getting this for a little bit, just as "randonascii" puts it. I am not sure if this is normal or not, I am trying just now to read up on the "closeOnExit" stuff. A little over my head on the exit codes, but will figure out. I'll leave it in other's very capable hands!

@ossdesign commented on GitHub (Apr 4, 2020): I came here to search in regards to this one, as have been getting this for a little bit, just as "randonascii" puts it. I am not sure if this is normal or not, I am trying just now to read up on the "closeOnExit" stuff. A little over my head on the exit codes, but will figure out. I'll leave it in other's very capable hands!

claunia commented

@ossdesign commented on GitHub (Apr 4, 2020):

Okay, I figured it out, found the resources online. Looks like exit codes can be used to evaluate the state that a run program exited as, maybe good for scripting. I just didn't know. Obviously you do, just saying ;) But yeah, seems like exiting via 'exit' when %ErrorLevel% != 0, then you get stuck with that error message, and you cannot break out of to close the terminal with the command line. You can still close the tab via clicking the X.

To the original poster, looks whatever you last did before trying to exit triggered a 'code 2':
"The system cannot find the file specified."

@ossdesign commented on GitHub (Apr 4, 2020): Okay, I figured it out, found the resources online. Looks like exit codes can be used to evaluate the state that a run program exited as, maybe good for scripting. I just didn't know. Obviously you do, just saying ;) But yeah, seems like exiting via 'exit' when %ErrorLevel% != 0, then you get stuck with that error message, and you cannot break out of to close the terminal with the command line. You can still close the tab via clicking the X. To the original poster, looks whatever you last did before trying to exit triggered a 'code 2': "The system cannot find the file specified."

claunia commented

@randomascii commented on GitHub (Apr 4, 2020):

I plan to tell people that this command sequence guarantees a clean exit:

cmd.exe /c echo ExitOnError=1 >%temp%\errorhandler.val && exit

It's true, and also deliciously misleading.

Vaguely related: twice I've seen a command prompt exit and print:

[process exited with code 1]

This is without my typing exit. I guess it has crashed?

@randomascii commented on GitHub (Apr 4, 2020): I plan to tell people that this command sequence guarantees a clean exit: cmd.exe /c echo ExitOnError=1 >%temp%\errorhandler.val && exit It's true, and also deliciously misleading. Vaguely related: twice I've seen a command prompt exit and print: [process exited with code 1] This is *without* my typing exit. I guess it has crashed?

claunia commented

@jdebp commented on GitHub (Apr 6, 2020):

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.

@jdebp commented on GitHub (Apr 6, 2020): 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.

claunia commented

@WSLUser commented on GitHub (Apr 6, 2020):

This also happens sometimes with WSL.

@WSLUser commented on GitHub (Apr 6, 2020): This also happens sometimes with WSL.

claunia commented

2026-01-31 00:59:09 +00:00

@WSLUser commented on GitHub (Apr 8, 2020):

I copied it this time. Strange thing though, I couldn't run any exe from WSL either.

wsluser@somecomputer:~$ cmd.exe
wsluser@somecomputer:~$ echo $PATH
/home/wsluser/.local/bin:/home/wsluser/bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/OpenSSH-Win64:/mnt/c/Program Files/PowerShell/7/:/mnt/c/Program Files/Microsoft VS Code Insiders/bin:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/Program Files/PuTTY/:/mnt/c/Users/user/.vcxsrv/vcxsrv.exe:/mnt/c/Users/user/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/user/AppData/Local/Programs/Microsoft VS Code Insiders/bin
wsluser@somecomputer:~$ ssh.exe
wsluser@somecomputer:~$ explorer.exe .
wsluser@somecomputer:~$ exit
logout

[process exited with code 1]

@WSLUser commented on GitHub (Apr 8, 2020): I copied it this time. Strange thing though, I couldn't run any exe from WSL either. ``` wsluser@somecomputer:~$ cmd.exe wsluser@somecomputer:~$ echo $PATH /home/wsluser/.local/bin:/home/wsluser/bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/OpenSSH-Win64:/mnt/c/Program Files/PowerShell/7/:/mnt/c/Program Files/Microsoft VS Code Insiders/bin:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/Program Files/PuTTY/:/mnt/c/Users/user/.vcxsrv/vcxsrv.exe:/mnt/c/Users/user/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/user/AppData/Local/Programs/Microsoft VS Code Insiders/bin wsluser@somecomputer:~$ ssh.exe wsluser@somecomputer:~$ explorer.exe . wsluser@somecomputer:~$ exit logout [process exited with code 1] ```

claunia commented

@WSLUser commented on GitHub (Apr 8, 2020):

Since no errors popped up, I'm assuming the commands were piped to Windows but Terminal didn't handle them correctly.

@WSLUser commented on GitHub (Apr 8, 2020): Since no errors popped up, I'm assuming the commands were piped to Windows but Terminal didn't handle them correctly.

claunia commented

2026-01-31 00:59:09 +00:00

@DHowett-MSFT commented on GitHub (Apr 8, 2020):

Since no errors popped up, I'm assuming the commands were piped to Windows but Terminal didn't handle them correctly.

Windows Terminal doesn't "handle" commands. It gets text out of a stream and puts it on the screen, and gets user input from the keyboard and puts it into a different stream.

It looks like you're hitting an interop failure in WSL, which almost certainly warrants a bug filed on their repository.

The exit code from bash is, as always, the last exit code of the last command you tried to run with it. This is by design, and this behavior is highly conserved across many shells on a heap of different operating systems.

@DHowett-MSFT commented on GitHub (Apr 8, 2020): > Since no errors popped up, I'm assuming the commands were piped to Windows but Terminal didn't handle them correctly. Windows Terminal doesn't "handle" commands. It gets text out of a stream and puts it on the screen, and gets user input from the keyboard and puts it into a different stream. It looks like you're hitting an interop failure in WSL, which almost certainly warrants a bug filed on [their repository](https://github.com/microsoft/wsl). The exit code from bash is, as always, the last exit code of the last command you tried to run with it. This is by design, and this behavior is highly conserved across many shells on a heap of different operating systems.

claunia commented

2026-01-31 00:59:09 +00:00

@WSLUser commented on GitHub (Apr 8, 2020):

Usually I don't get exit codes to exit the tab. This time I did and got this interop error. It's working better than before at least (wsl.conf wasn't being read and interop was completely dead before unless I manually mounted my Windows drives in the CLI). Using an imported distro is more painful than one would think.

@WSLUser commented on GitHub (Apr 8, 2020): Usually I don't get exit codes to exit the tab. This time I did and got this interop error. It's working better than before at least (wsl.conf wasn't being read and interop was completely dead before unless I manually mounted my Windows drives in the CLI). Using an imported distro is more painful than one would think.

claunia commented

2026-01-31 00:59:10 +00:00

@sentry07 commented on GitHub (Apr 23, 2020):

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)

@sentry07 commented on GitHub (Apr 23, 2020): 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)

claunia commented

2026-01-31 00:59:10 +00:00

@DHowett-MSFT commented on GitHub (Apr 23, 2020):

Yeah, you can. Set closeOnExit to always.

@DHowett-MSFT commented on GitHub (Apr 23, 2020): _Yeah, you can. Set `closeOnExit` to `always`._

claunia commented

2026-01-31 00:59:10 +00:00

@DHowett-MSFT commented on GitHub (Apr 23, 2020):

You do not need to be patronizing to make your point. (EDIT: It is possible I read "Just close the window. Can we do that?" in a way the author did not intend.)

@DHowett-MSFT commented on GitHub (Apr 23, 2020): You do not need to be patronizing to make your point. (EDIT: It is possible I read "Just close the window. Can we do that?" in a way the author did not intend.)

claunia commented

@sentry07 commented on GitHub (Apr 23, 2020):

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. :)

@sentry07 commented on GitHub (Apr 23, 2020): 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. :)

claunia commented

@DHowett-MSFT commented on GitHub (Apr 23, 2020):

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. 😄

@DHowett-MSFT commented on GitHub (Apr 23, 2020): 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. 😄

claunia commented

@DHowett-MSFT commented on GitHub (Apr 23, 2020):

(If you’re coming from a version of Terminal settings where closeOnExit is a Boolean value, it might be a great time to refresh your settings by moving them aside and letting us regenerate the file. The new defaults are a lot more sane than the old ones, but they might also change some things you’re relying on. YMMV.)

@DHowett-MSFT commented on GitHub (Apr 23, 2020): (If you’re coming from a version of Terminal settings where closeOnExit is a Boolean value, it might be a great time to refresh your settings by moving them aside and letting us regenerate the file. The new defaults are a lot more sane than the old ones, but they might also change some things you’re relying on. YMMV.)

claunia commented

@randomascii commented on GitHub (Apr 23, 2020):

Perhaps related: a couple of times a cmd window in the Windows Terminal (Preview) has spontaneously printed "[process exited with code 1]" without me typing exit. This seems to happen when I'm not even interacting with it. It feels like it has just randomly quit.

I have WER configured to get crash dumps and I haven't seen any so I don't know what's going on. It doesn't seem worth filing a bug because I have no real information, but I thought I'd mention it here.

@randomascii commented on GitHub (Apr 23, 2020): Perhaps related: a couple of times a cmd window in the Windows Terminal (Preview) has spontaneously printed "[process exited with code 1]" without me typing exit. This seems to happen when I'm not even interacting with it. It feels like it has just randomly quit. I have WER configured to get crash dumps and I haven't seen any so I don't know what's going on. It doesn't seem worth filing a bug because I have no real information, but I thought I'd mention it here.

claunia commented

2026-01-31 00:59:12 +00:00

@DHowett-MSFT commented on GitHub (Apr 23, 2020):

Huh.. that could be a crash in the PTY host. Would you mind keeping your eyes peeled for OpenConsole dumps? This could be one of our known issues if it’s related to resizing (which I can’t immediately evoke by name on my phone.)

@DHowett-MSFT commented on GitHub (Apr 23, 2020): Huh.. that could be a crash in the PTY host. Would you mind keeping your eyes peeled for OpenConsole dumps? This could be one of our known issues if it’s related to resizing (which I can’t immediately evoke by name on my phone.)

claunia commented

@Firehawke commented on GitHub (Apr 24, 2020):

I don't know if I should open a new issue for this, but I'm starting to have issues with 'exit' causing WT as a whole to freeze. Before today's update it had started to randomly freeze on a 'exit' then after a few seconds the whole WT session would disappear. Now it's just freezing and staying that way.

As I see it, it's still a "exit doesn't reliably close the tab" kind of thing, so if I need to open a different issue, let me know.

@Firehawke commented on GitHub (Apr 24, 2020): I don't know if I should open a new issue for this, but I'm starting to have issues with 'exit' causing WT as a whole to freeze. Before today's update it had started to randomly freeze on a 'exit' then after a few seconds the whole WT session would disappear. Now it's just freezing and staying that way. As I see it, it's still a "exit doesn't reliably close the tab" kind of thing, so if I need to open a different issue, let me know.

claunia commented

2026-01-31 00:59:12 +00:00

@DHowett-MSFT commented on GitHub (Apr 24, 2020):

@Firehawke We should definitely track that one as a separate issue! Would you mind capturing a dump file from Task Manager (WindowsTerminal.exe process) when it's hung like this? You can e-mail me with the address on my GitHub profile.

@DHowett-MSFT commented on GitHub (Apr 24, 2020): @Firehawke We should definitely track that one as a separate issue! Would you mind capturing a dump file from Task Manager (WindowsTerminal.exe process) when it's hung like this? You can e-mail me with the address on my GitHub profile.

claunia commented

2026-01-31 00:59:12 +00:00

@Firehawke commented on GitHub (Apr 24, 2020):

Okay, I'll open a new issue as soon as I'm able to trigger it again.

@Firehawke commented on GitHub (Apr 24, 2020): Okay, I'll open a new issue as soon as I'm able to trigger it again.

claunia commented

@vlad-teodor commented on GitHub (May 6, 2020):

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

Without typing any command, press CTRL + D -> tab closes
Open another WSL tab
Type an invalid command ('frwgufgwe' should do)
Press CTRL + D -> "[process exited with code 127]"

@vlad-teodor commented on GitHub (May 6, 2020): 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]"

claunia commented

@raxraj commented on GitHub (May 7, 2020):

This is after the latest update the FIRST (without Preview) release.
And the exit command still doesn't appear to be fixed.

@raxraj commented on GitHub (May 7, 2020): ![image](https://user-images.githubusercontent.com/41513907/81290430-afa38200-9085-11ea-8366-099bf2eb953b.png) This is after the latest update the FIRST (without Preview) release. And the exit command still doesn't appear to be fixed.

claunia commented

@zadjii-msft commented on GitHub (May 7, 2020):

@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.

@zadjii-msft commented on GitHub (May 7, 2020): @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`.

claunia commented

@HolisticDeveloper commented on GitHub (May 8, 2020):

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.

@HolisticDeveloper commented on GitHub (May 8, 2020): > 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](https://github.com/microsoft/terminal/blob/master/doc/cascadia/SettingsSchema.md) to verify.

claunia commented

@raxraj commented on GitHub (May 8, 2020):

@HolisticDeveloper @zadjii-msft Thanks, I understood. Solved the problem :)

@raxraj commented on GitHub (May 8, 2020): @HolisticDeveloper @zadjii-msft Thanks, I understood. Solved the problem :)

claunia commented

@vadimkantorov commented on GitHub (Aug 14, 2020):

Just got the same thing when closing a WSLv1 tab

What's bad is that it's completely unclear in the UI if WSLv1 is still running or not and what process exited with this exit code. I thought that some wrapper process is still running and typed Ctrl+C multiple times which does not work. Enter also doesn't work to close this. If it's Terminal that handles printing this message, the message should better include an explanation what happened and what's running / what's closed.

@vadimkantorov commented on GitHub (Aug 14, 2020): Just got the same thing when closing a WSLv1 tab ![image](https://user-images.githubusercontent.com/1041752/90196952-835a7880-ddcd-11ea-81c1-10541765b29a.png) What's bad is that it's completely unclear in the UI if WSLv1 is still running or not and what process exited with this exit code. I thought that some wrapper process is still running and typed Ctrl+C multiple times which does not work. Enter also doesn't work to close this. If it's Terminal that handles printing this message, the message should better include an explanation what happened and what's running / what's closed.

claunia commented

@DHowett commented on GitHub (Aug 14, 2020):

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. 😄

@DHowett commented on GitHub (Aug 14, 2020): 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. :smile:

claunia commented

@vadimkantorov commented on GitHub (Aug 14, 2020):

Well, this explanation is way better than the message that I got just minutes ago. At least it'd be clear that WSL is dead and that I should close the tab.

I thought some WSLv1 process (like Ubuntu's command_not_found that loads up python and does search for modules in a gazillion of site locations) got hung so badly that doesn't respond to Ctrl+C and blocked the WSL instance.

@vadimkantorov commented on GitHub (Aug 14, 2020): Well, this explanation is way better than the message that I got just minutes ago. At least it'd be clear that WSL is dead and that I should close the tab. I thought some WSLv1 process (like Ubuntu's command_not_found that loads up python and does search for modules in a gazillion of site locations) got hung so badly that doesn't respond to Ctrl+C and blocked the WSL instance.

claunia commented

@LuckyGinger commented on GitHub (Dec 7, 2020):

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,

@LuckyGinger commented on GitHub (Dec 7, 2020): 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,

claunia commented

@vadimkantorov commented on GitHub (May 11, 2021):

Again stumbled on this. After typing Ctrl+D in WSLv1 shell it hung and did not close the tab:

@vadimkantorov commented on GitHub (May 11, 2021): Again stumbled on this. After typing `Ctrl+D` in WSLv1 shell it hung and did not close the tab: ![image](https://user-images.githubusercontent.com/1041752/117823546-de8e9e00-b26d-11eb-8086-d3b8cc62f5e7.png)

claunia commented

@zadjii-msft commented on GitHub (May 11, 2021):

Yep, that's exactly the same as all the other hits in this thread. You can totally avoid it with "closeOnExit": "always". I'm not sure there's any other discussion to be had on the subject?

@zadjii-msft commented on GitHub (May 11, 2021): Yep, that's exactly the same as all the other hits in this thread. You can totally avoid it with `"closeOnExit": "always"`. I'm not sure there's any other discussion to be had on the subject?

claunia commented

@vadimkantorov commented on GitHub (May 11, 2021):

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...

@vadimkantorov commented on GitHub (May 11, 2021): 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...

claunia commented