Bash tool spawns child processes with no Win32 console on Windows — native console apps hang indefinitely

Bug report

Title: Bash tool spawns child processes with no Win32 console on Windows — native console apps hang indefinitely

Environment

• OS: Windows 11 Pro (10.0.26220)
• Shell: Git Bash (MSYS2/MINGW64), invoked via the Bash tool
• Claude Code client: claude.exe 2026-08 build

Summary

On Windows, commands run through the Bash tool are spawned with stdio
fully redirected via pipes and no Win32 console object attached at all
— not a hidden/zero-size console, but genuinely absent. Any native Win32
console application that probes console state during startup (rather than
purely reading/writing stdio) can hang indefinitely in that environment,
with no timeout and no clean fallback, because the console-state query
itself never resolves.

This reliably reproduced with tea (the Gitea CLI, a compiled Go binary)
on every invocation — tea --version, tea --help, tea login list, and
a git credential.helper shelling out to tea login helper all hung until
externally killed, even for subcommands that touch no network and prompt
for no auth. The PowerShell tool, run in the same session against the
same binary, returns instantly and correctly every time.

Reproduction

# Under the Bash tool:
timeout 8 tea --version < /dev/null
# hangs full 8s, then killed (exit 124) — no output, no error

# Under the PowerShell tool, same session, same machine:
tea login list
# returns instantly with correct output

Ruled out before concluding this is a Bash-tool environment issue, not a
tea/network/auth issue:

• Not network/auth-specific: tea --help and tea --version hang too, no

network call involved.

• Not blocked on a stdin read: still hangs with < /dev/null (which would

otherwise deliver immediate EOF).

• Not "any native Win32 binary hangs under Bash tool": git.exe (also a

compiled native Windows binary, MSYS/Cygwin-style POSIX I/O) works fine
for both local and network operations under the same Bash tool session.
Only binaries that probe Win32 console state (rather than relying on
POSIX pipe/tty semantics) are affected.

• Confirmed no console object exists at all: winpty (which builds a full

Windows pseudo-console specifically for running native console apps
under MSYS2) crashed on its own internal assertion —
ASSERT_CONDITION("wp != nullptr && cols > 0 && rows > 0") — because it
could not read valid console dimensions from the process tree the Bash
tool spawned it in.

• Confirmed the gap is inherited by the whole process tree, not shell-

specific: invoking powershell.exe -NoProfile -Command "tea login list"
from inside the Bash tool also hangs, identically to invoking tea
directly. The PowerShell tool only works because Claude Code spawns
it with a real console attached at a level outside the Bash tool's
process tree — a plain powershell.exe child of a Bash-tool process gets
the same broken (consoleless) environment as everything else under Bash.

Impact

• Any native Win32 console application invoked (directly, or transitively

via a git credential.helper, build tool, linter, etc.) that performs a
console-capability probe on startup can hang the Bash tool indefinitely
instead of erroring or timing out promptly.

• Each hang leaves orphaned child processes running in the background after

the Bash tool's own timeout kills the wrapper — the killed command's
children are not reaped, so they persist consuming resources and can
block subsequent invocations of the same binary (observed repeatedly with
tea.exe/git.exe/git-remote-https.exe orphans piling up across a
session).

Expected behavior

• Bash-tool-spawned processes on Windows should have a valid (even if

headless/zero-size) console object, matching what the PowerShell tool's
process tree gets — enough for GetConsoleMode/console-dimension queries
to return a clean, consistent answer instead of an inconsistent state
that some binaries block on.

• When a command times out and is killed, its full descendant process tree

should be terminated too (e.g. via a Windows Job Object), not just the
immediate wrapper process — this would at least prevent orphan pileup
even without fixing the console gap itself.

Workaround in use

Routing anything that touches git/credential helpers/native Win32
console binaries through the PowerShell tool instead of Bash on this
machine, via a global ~/.claude/CLAUDE.md instruction. Works reliably,
but shouldn't be necessary — this is a genuine gap in the Bash tool's
Windows process-spawning behavior, not a project/git/tea misconfiguration.