starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 00:15:10 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal hangs on exit with 'process exited with code 127' message #6423

New Issue
Closed
opened 2026-01-31 00:38:19 +00:00 by claunia · 20 comments
claunia commented 2026-01-31 00:38:19 +00:00
Owner
Copy Link

Originally created by @cristianciutea on GitHub (Feb 13, 2020).

Hi!
I've noticed that on newer releases(starting from 0.8.x) when you try to close the terminal(with exit command or ctrl+d) after executing a command that returned an error status code, the tab hangs with the message:
[process exited with code
This happens on wsl and cmd.

Environment

Microsoft Windows [Version 10.0.18363.657]
Windows Terminal version: 0.9.433.0

Steps to reproduce

Execute from cmd a command that produce an error then try to close with exit command: e.g:

C:\Users\cristi>asd
'asd' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\cristi>exit

[process exited with code 9009]

Same behavior in WSL when exit or ctrl+d:

 /mnt/c/Users/cristi$ false
 /mnt/c/Users/cristi$ exit
[process exited with code 1]

Expected behavior

Windows Terminal tab should be closed.

Actual behavior

Windows Terminal tab freeze.

Originally created by @cristianciutea on GitHub (Feb 13, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> Hi! I've noticed that on newer releases(starting from 0.8.x) when you try to close the terminal(with exit command or ctrl+d) after executing a command that returned an error status code, the tab hangs with the message: [process exited with code This happens on wsl and cmd. # Environment ```none Microsoft Windows [Version 10.0.18363.657] Windows Terminal version: 0.9.433.0 ``` # Steps to reproduce Execute from cmd a command that produce an error then try to close with exit command: e.g: ```none C:\Users\cristi>asd 'asd' is not recognized as an internal or external command, operable program or batch file. C:\Users\cristi>exit [process exited with code 9009] ``` Same behavior in WSL when exit or ctrl+d: ``` /mnt/c/Users/cristi$ false /mnt/c/Users/cristi$ exit [process exited with code 1] ``` <!-- A description of how to trigger this bug. --> # Expected behavior Windows Terminal tab should be closed. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior Windows Terminal tab freeze. <!-- What's actually happening? -->
claunia added the Resolution-Duplicate label 2026-01-31 00:38:19 +00:00
claunia commented 2026-01-31 00:38:20 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 13, 2020):

Hey there! This is, unfortunately, by design; it's highly conserved across different types of shells (bash, zsh, powershell and CMD all do the same thing) and the behavior of not closing the tab is in line with Ubuntu's terminal: https://github.com/microsoft/terminal/issues/4223#issuecomment-574834181

@DHowett-MSFT commented on GitHub (Feb 13, 2020): Hey there! This is, unfortunately, by design; it's highly conserved across different types of shells (bash, zsh, powershell and CMD all do the same thing) and the behavior of not closing the tab is in line with Ubuntu's terminal: https://github.com/microsoft/terminal/issues/4223#issuecomment-574834181
claunia commented 2026-01-31 00:38:20 +00:00
Author
Owner
Copy Link

@carragom commented on GitHub (Mar 20, 2020):

Hi,
I agree that not closing the tab/pane on error is correct. But one question remains, how do I close a split pane after it got to that dead state? See screenshot.

image

When a terminal only support tabs, as it was before splits landed, this is not too problematic because I can open a new tab and close the dead one (not ideal but acceptable). But now that splits are supported, closing a tab might mean loosing work since a tab might contain more than one terminal. There seem to be an action to close a pane here but this should have better default behavior.

My proposal for this would be

  1. Replace the message [process exited with code 1] with something like [process exited with code 1, press <key> to exit]. Where key could be enter, space or another sensible key. And of course implement the functionality of closing the pane/tab when the key is pressed.
  2. Have a setting where I can bypass this behavior and close the pane/tab when the shell exits no matter the exit status of the last command. There already exists a closeOnExit option but I have it on always and the pane/tab does not close.

On other related comments like this one the default behavior of never closing is suppose to exist to prevent a terminal from closing on startup because of a miss configuration on the shell. This behavior should never be lost even if proposal number 2 gets implemented.

I know I could place something like this inside my ~/.bash_logout to achieve what I want but that is just bad UX and specific to bash. This should be handled in the terminal and work with any shell.

if [ "$SHLVL" = 1 ]; then
    [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
exit 0

If there already exist a way to achieve any of my proposals please point me on the right direction.
Thanks.

@carragom commented on GitHub (Mar 20, 2020): Hi, I agree that not closing the tab/pane on error is correct. But one question remains, how do I close a split pane after it got to that dead state? See screenshot. ![image](https://user-images.githubusercontent.com/970403/77199875-2a511780-6aaf-11ea-9301-c5d650a469f5.png) When a terminal only support tabs, as it was before splits landed, this is not too problematic because I can open a new tab and close the dead one (not ideal but acceptable). But now that splits are supported, closing a tab might mean loosing work since a tab might contain more than one terminal. There seem to be an action to close a pane [here](https://github.com/microsoft/terminal/blob/master/doc/cascadia/SettingsSchema.md#implemented-commands-and-actions) but this should have better default behavior. My proposal for this would be 1. Replace the message `[process exited with code 1]` with something like `[process exited with code 1, press <key> to exit]`. Where `key` could be enter, space or another sensible key. And of course implement the functionality of closing the pane/tab when the key is pressed. 2. Have a setting where I can bypass this behavior and close the pane/tab when the shell exits no matter the exit status of the last command. There already exists a `closeOnExit` option but I have it on `always` and the pane/tab does not close. On other related comments like [this one](https://github.com/microsoft/terminal/issues/4223#issuecomment-574834181) the default behavior of never closing is suppose to exist to prevent a terminal from closing on startup because of a miss configuration on the shell. This behavior should never be lost even if proposal number 2 gets implemented. I know I could place something like this inside my `~/.bash_logout` to achieve what I want but that is just bad UX and specific to bash. This should be handled in the terminal and work with any shell. ```bash if [ "$SHLVL" = 1 ]; then [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q fi exit 0 ``` If there already exist a way to achieve any of my proposals please point me on the right direction. Thanks.
claunia commented 2026-01-31 00:38:21 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 20, 2020):

Hey so for the record, we already have a key bound to "close pane" by default, and have for some time now :) Ctrl+Shift+W, which is the default keybinding for closePane will try to close the active pane, and if there's only one pane in the tab, it'll just close the tab. So if you've been using that to close tabs, it'll just work for closing panes as well.

/cc @DHowett-MSFT, because "closeOnExit":"always" should work the way you want.

@zadjii-msft commented on GitHub (Mar 20, 2020): Hey so for the record, we already have a key bound to "close pane" by default, and have for some time now :) <kbd>Ctrl+Shift+W</kbd>, which is the default keybinding for `closePane` will try to close the active pane, and if there's only one pane in the tab, it'll just close the tab. So if you've been using that to close tabs, it'll _just work_ for closing panes as well. /cc @DHowett-MSFT, because `"closeOnExit":"always"` _should_ work the way you want.
claunia commented 2026-01-31 00:38:21 +00:00
Author
Owner
Copy Link

@carragom commented on GitHub (Mar 20, 2020):

Thanks for the quick response, Ctrl+Shift+W does close the dead pane/tab but I still think press <key> to exit would be a better feature.

As for "closeOnExit": "always" I'm not sure why it does not work for me, I do have it in the global section and not on any specific profile.

@carragom commented on GitHub (Mar 20, 2020): Thanks for the quick response, Ctrl+Shift+W does close the dead pane/tab but I still think `press <key> to exit` would be a better feature. As for `"closeOnExit": "always"` I'm not sure why it does not work for me, I do have it in the global section and not on any specific profile.
claunia commented 2026-01-31 00:38:21 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 20, 2020):

@carragom Oh, that explains it - closeOnExit is a Profile setting. See this doc:
https://github.com/microsoft/terminal/blob/master/doc/cascadia/SettingsSchema.md#profiles

If you want it for all your profiles, you could try the following:

{
    "profiles": {
        "defaults": {
            "closeOnExit": "always"
        },
        "list": [
            // all your profiles go here
        ]
    }
}
@zadjii-msft commented on GitHub (Mar 20, 2020): @carragom Oh, that explains it - `closeOnExit` is a Profile setting. See this doc: https://github.com/microsoft/terminal/blob/master/doc/cascadia/SettingsSchema.md#profiles If you want it for all your profiles, you could try the following: ```jsonc { "profiles": { "defaults": { "closeOnExit": "always" }, "list": [ // all your profiles go here ] } } ```
claunia commented 2026-01-31 00:38:22 +00:00
Author
Owner
Copy Link

@carragom commented on GitHub (Mar 20, 2020):

Thanks a lot, when placing the closeOnExit on the specific profile it behaves as expected.

@carragom commented on GitHub (Mar 20, 2020): Thanks a lot, when placing the `closeOnExit` on the specific profile it behaves as expected.
claunia commented 2026-01-31 00:38:22 +00:00
Author
Owner
Copy Link

@weitzhandler commented on GitHub (May 11, 2020):

By me, the closeOnExit setting was under defaults, though it was set to true. Changing it to "always" seems to do the job.

@weitzhandler commented on GitHub (May 11, 2020): By me, the `closeOnExit` setting was under `defaults`, though it was set to `true`. Changing it to `"always"` seems to do the job.
claunia commented 2026-01-31 00:38:22 +00:00
Author
Owner
Copy Link

@jake-dev-99 commented on GitHub (May 18, 2020):

I'll add that this is happening under powershell when it's not expected, for example running a python script and hitting "Ctrl+C" to kill the script. When this happens it requires me to open a new terminal tab and re-navigate to my working directory.

@jake-dev-99 commented on GitHub (May 18, 2020): I'll add that this is happening under powershell when it's not expected, for example running a python script and hitting "Ctrl+C" to kill the script. When this happens it requires me to open a new terminal tab and re-navigate to my working directory.
claunia commented 2026-01-31 00:38:22 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 18, 2020):

@jaallen did you install powershell with scoop or dotnet global, or as a standard MSI?

@DHowett commented on GitHub (May 18, 2020): @jaallen did you install powershell with scoop or dotnet global, or as a standard MSI?
claunia commented 2026-01-31 00:38:23 +00:00
Author
Owner
Copy Link

@jake-dev-99 commented on GitHub (May 18, 2020):

@DHowett Was installed via standard MSI

@jake-dev-99 commented on GitHub (May 18, 2020): @DHowett Was installed via standard MSI
claunia commented 2026-01-31 00:38:23 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 18, 2020):

Huh. That's unexpected. Usually we see "^C terminates everything, even things I didn't want it to" with the two powershell wrappers from scoop or dotnet global.

@DHowett commented on GitHub (May 18, 2020): Huh. That's unexpected. Usually we see "^C terminates everything, even things I didn't want it to" with the two powershell wrappers from scoop or dotnet global.
claunia commented 2026-01-31 00:38:23 +00:00
Author
Owner
Copy Link

@jake-dev-99 commented on GitHub (May 18, 2020):

In that case, it's been a couple years since this machine was rebuilt, so it's possible I did some powershell gymnastics at some point that could have created this. Let me do some deep-diving and I'll report back.

@jake-dev-99 commented on GitHub (May 18, 2020): In that case, it's been a couple years since this machine was rebuilt, so it's possible I did some powershell gymnastics at some point that could have created this. Let me do some deep-diving and I'll report back.
claunia commented 2026-01-31 00:38:23 +00:00
Author
Owner
Copy Link

@jake-dev-99 commented on GitHub (May 18, 2020):

@DHowett Unfortunately I don't have much else to add. As far as I can tell, I'm just using the built-in powershell without any additional addons or modifications. When I ctrl+c from a hung python script, it prints code 3221225786 and closes the session on that tab. Let me know if I can provide anything specifically that might be of any help.

@jake-dev-99 commented on GitHub (May 18, 2020): @DHowett Unfortunately I don't have much else to add. As far as I can tell, I'm just using the built-in powershell without any additional addons or modifications. When I ctrl+c from a hung python script, it prints code 3221225786 and closes the session on that tab. Let me know if I can provide anything specifically that might be of any help.
claunia commented 2026-01-31 00:38:24 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 18, 2020):

@jaallen hmm.

If this is PowerShell 7, can you run...

$p=(Get-Process -id $PID); ($p, $p.Parent) | ft Id,Path

(I hope you're on 7 :P)

@DHowett commented on GitHub (May 18, 2020): @jaallen _hmm_. If this is PowerShell 7, can you run... ``` $p=(Get-Process -id $PID); ($p, $p.Parent) | ft Id,Path ``` (I hope you're on 7 :P)
claunia commented 2026-01-31 00:38:24 +00:00
Author
Owner
Copy Link

@jake-dev-99 commented on GitHub (May 19, 2020):

@DHowett Unfortunately....I'm not lol

Running the above command, I get the following:

14856 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

The $PSVersionTable shows me at 5.1.18362.752

@jake-dev-99 commented on GitHub (May 19, 2020): @DHowett Unfortunately....I'm not lol Running the above command, I get the following: > 14856 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe The $PSVersionTable shows me at 5.1.18362.752
claunia commented 2026-01-31 00:38:24 +00:00
Author
Owner
Copy Link

@AyoungDukie commented on GitHub (Jul 31, 2020):

Can confirm that this occurs for me when prematurely terminating a basic cmdlet with CTRL+C as well. I have installed from the Microsoft App Store in my case.

@AyoungDukie commented on GitHub (Jul 31, 2020): Can confirm that this occurs for me when prematurely terminating a basic cmdlet with CTRL+C as well. I have installed from the Microsoft App Store in my case.
claunia commented 2026-01-31 00:38:24 +00:00
Author
Owner
Copy Link

@bilogic commented on GitHub (Sep 21, 2020):

I like it that Terminal does not close if there was an error, this can be extremely helpful when you least expect it and I have always used a batch file shortcut x.bat which contains just @exit to exit and close cmd.exe.

I'm currently testing if @exit 0 solves this issue.

@bilogic commented on GitHub (Sep 21, 2020): I like it that Terminal does not close if there was an error, this can be extremely helpful when you least expect it and I have always used a batch file shortcut `x.bat` which contains just `@exit` to exit and close `cmd.exe`. I'm currently testing if `@exit 0` solves this issue.
claunia commented 2026-01-31 00:38:25 +00:00
Author
Owner
Copy Link

@chinwobble commented on GitHub (Feb 9, 2021):

Hi I'm getting this issue too in wsl ubuntu.

When I run a script and it fails it exits with

[process exited with code 1]

The entire shell terminates and I'd prefer to be able to press a hotkey to restart the shell in the same location.

@chinwobble commented on GitHub (Feb 9, 2021): Hi I'm getting this issue too in wsl ubuntu. When I run a script and it fails it exits with ```sh [process exited with code 1] ``` The entire shell terminates and I'd prefer to be able to press a hotkey to restart the shell in the same location.
claunia commented 2026-01-31 00:38:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 9, 2021):

@chinwobble You're looking for something more like #4772

@zadjii-msft commented on GitHub (Feb 9, 2021): @chinwobble You're looking for something more like #4772
claunia commented 2026-01-31 00:38:25 +00:00
Author
Owner
Copy Link

@eversonleal commented on GitHub (Jul 2, 2021):

I added an alias called "exit" on my .bash_profile: alias exit="exit 0". It solved the problem for me.

@eversonleal commented on GitHub (Jul 2, 2021): I added an alias called "exit" on my .bash_profile: alias exit="exit 0". It solved the problem for me.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6423
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?