More robust check for mintty when creating winpty bash aliases

[cspotcode]

winpty aliases cause some issues (see linked issue) and aren't necessary outside of mintty, so I tweaked the conditional to detect mintty and excludes Windows Terminal, VSCode terminal, and other modern windows terminals that export TERM=xterm-256color.

git-for-windows/git#5960

Other detection techniques I considered

I considered checking tty -s but it returns exit code 0 everywhere, in both mintty and Windows Terminal. Plus, it would require access to tty on the path (usually true but maybe sometimes not?) and would mean an extra process spawn in the profile which slows down startup.

I checked all env vars in both terminals, and TERM_PROGRAM is the only one that seems viable. MSYSTEM is set in both mintty and Windows Terminal.

Code review questions

Did I write the bash syntax correctly? I'm not using any bash-specific syntax that might break in unique configurations, and I'm not going to trigger errors if the shell has set -u?

[dscho]

/updpkgsums

The workflow run was started.

[dscho]

In my tests, node.exe worked, even without winpty. Maybe this has changed with the default to using Pseudo Consoles? It would be so great if we could get rid altogether of that winpty dependency.

On the other hand, in my tests, python.exe still did not work without winpty (I am using v3.13 from the Microsoft Store), I cannot Ctrl+Z nor Ctrl+D out of the blank prompt when I call the interactive interpreter without winpty. Any ideas?

[cspotcode]

Are we talking about two different questions?

• Question A) Is winpty necessary in Windows Terminal, VSCode integrated terminal, and other modern terminals?
  • As far as I know, "never necessary" which is the impetus for this PR
• Question B) Is winpty necessary in mintty? If so, which programs require winpty in mintty?
  • Is this second question what you are asking in your comment? More robust check for mintty when creating winpty bash aliases #664 (comment)

[dscho]

Is winpty necessary in Windows Terminal, VSCode integrated terminal, and other modern terminals?

• As far as I know, "never necessary" which is the impetus for this PR

Correct. winpty is not necessary when there is a real Win32 Console.

• Is winpty necessary in mintty?

Originally, all regular Console programs required winpty when running in MinTTY. The reason is that MinTTY does not actually have a Win32 Console associated with its (emulated Unix) pseudo terminal, but relies purely on the POSIX emulation layer (provided by the MSYS2 runtime, which is a friendly fork of the Cygwin runtime). winpty provides the bridge between, by creating a Win32 Console for the Console programs to use, and mapping them to the (emulated Unix) pseudo terminal of the MinTTY window.

Some time ago, Windows started to offer Pseudo Consoles, with the intention to provide enough functionality to make that emulated Unix pseudo terminal support obsolete. Cygwin started supporting these Pseudo Consoles, at first opt-in, then later as opt-out feature. I personally experienced so many issues with Cygwin's Pseudo Console support that I held out a lot longer than Cygwin, making the Pseudo Consoles the default in Git for Windows only much much later than Cygwin. Today, it is the default, though.

Which was the reason why I tried running node.exe directly in a Git Bash (using MinTTY), and it worked!

I also tried tclsh.exe which also worked. I would have tried interactive OpenSSL, as mentioned in Git for Windows' known issues about Console programs requiring winpty, but this mode [was removed in OpenSSL v3.0](https://docs.openssl.org/3.0/man1/openssl/#:~:text=was removed in OpenSSL 3.0).

If so, which programs require winpty in mintty?

So far, the only program I tried that did require was Microsoft Store's Python. I do not quite understand why that is, though. Given my understanding of Pseudo Consoles, it should work.

[jeremyd2019]

https://cygwin.com/pipermail/cygwin/2025-October/258882.html ?

[dscho]

https://cygwin.com/pipermail/cygwin/2025-October/258882.html ?

@jeremyd2019 thank you so much for the pointer! I also realized that this reproducer basically demonstrates the very same issue.

[dscho]

For the record: I have submitted patches to the Cygwin-patches mailing list to fix this thing with app execution aliases and standard handles (and it was pointed out that another patch would also fix the issue, even if the commit message might fool readers into believing that it's about something completely different, and even if v2 of that patch still shares that unfortunate trait).

I also opened a draft PR over at git-for-windows/msys2-runtime#122 whose build artifact can be used to verify that it fixes the issue.

All this is to say: I hope that before long, we can do away with the winpty hack altogether!

[cspotcode]

Another case where these aliases break things: using mise

mise symlinks itself to the names of the various tools it manages, then detects when it's spawned as their name and delegates to the correct version of that tool. (same pattern as used by busybox)

winpty appears to break that behavior, so that mise always thinks it's being launched as mise.exe even when via symlink

# Problematic alias is enabled
$ alias node
node='winpty node.exe'

# node is a symlink to `mise` 
$ ls -al `which node.exe`
... /c/Users/cspot/AppData/Local/mise/shims/node.exe -> /c/Users/cspot/AppData/Local/Microsoft/WinGet/Packages/jdx.mise_Microsoft.Winget.Source_8wekyb3d8bbwe/mise/bin/mise.exe*

# Bug: winpty breaks mise's ability to detect it is launched via node symlink
$ node --version
              _                                        __
   ____ ___  (_)_______        ___  ____        ____  / /___ _________
  / __ `__ \/ / ___/ _ \______/ _ \/ __ \______/ __ \/ / __ `/ ___/ _ \
 / / / / / / (__  )  __/_____/  __/ / / /_____/ /_/ / / /_/ / /__/  __/
/_/ /_/ /_/_/____/\___/      \___/_/ /_/     / .___/_/\__,_/\___/\___/
                                            /_/                 by @jdx
2026.2.13 windows-x64 (2026-02-15)

# Must bypass alias to fix
$ node.exe --version
v25.2.1

[dscho]

@cspotcode thank you for the ping! We actually integrated a new MSYS2 runtime version (v3.6.6) into Git for Windows, and this bump includes the fix I was talking about in its commit range.

All this is to say: I think we can just drop the entire winpty alias hack. Would you kindly do the honors, and force-push?

[cspotcode]

@dscho done!

[dscho]

/updpkgsums

The workflow run was started.

[dscho]

done!

@cspotcode thank you! Out of curiosity: did you test it with a Store app?

[dscho]

/updpkgsums

[dscho]

If the change in this here PR works, we probably also want to edit the known issues item of the release notes that talks about the console program problems...

[cspotcode]

@cspotcode thank you! Out of curiosity: did you test it with a Store app?

No, I didn't test it; I unfortunately don't have any bandwidth to test this change.

[dscho]

@cspotcode thank you! Out of curiosity: did you test it with a Store app?

No, I didn't test it; I unfortunately don't have any bandwidth to test this change.

No worries, I just tested it, and the MSYS2 runtime works fine with the Store version of Python, without having to have the winpty hack.

[dscho]

/deploy git-extra

The i686/x86_64 and the arm64 workflow runs were started.

[dscho]

/add relnote feature The shell aliases in Git Bash that ensured that interpreters such as Python and Node.JS are executed via winpty are no longer necessary, and have therefore been dropped.

The workflow run was started