Git Bash tabs hang forever on stty raw, pegging one CPU core at 100% each — regression after v0.2026.08.26.17.59.stable_01 #15659

Activity

1. aslan-py

   added

   bugSomething isn't working.Something isn't working.

   on Aug 29, 2026
2. warp-for-oss commented on Aug 29, 2026

   

   warp-for-ossBot

   on Aug 29, 2026

   Last edited by warp-for-oss

   Contributor

   More actions

   @aslan-py

   Here's what I found while triaging this issue:

   This appears to be a Windows-only Git Bash startup regression in Warp's MSYS2/ConPTY shell bootstrap path. The current evidence is strong enough to route as a reproducible bug; the bash plugin detection changelog entry is a useful regression-window clue, but the report points to an earlier hang at the initial raw-mode bootstrap command.

   I have a few follow-up questions before I can narrow this down:

   1. Can you attach redacted Warp logs captured immediately after opening one stuck Git Bash tab?
   2. For a single new Git Bash tab, does it eventually finish after roughly 30-40 seconds every time, or does it remain stuck indefinitely until closed?

   Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

   Maintainer details

   I concluded that windows Git Bash startup regressed in v0.2026.08.26.17.59.stable_01, hanging at Warp's injected stty raw bootstrap command while each tab's bash process pins one CPU core..

   Triage summary

   This looks like a Windows-specific Git Bash/MSYS2 startup regression in Warp's shell bootstrap path. The report is unusually detailed: it identifies the affected Warp build, Windows and Git for Windows/MSYS2 versions, the bash.exe --noprofile --norc child process, the first stuck bootstrap command, screenshots, and per-process CPU behavior.

   Reproduction confidence

   High. The issue is isolated to Warp's Git Bash session path, with native Git Bash, PowerShell, and WSL reported as unaffected. The exact environment and reproduction path are specific enough to route without waiting for generic environment details.

   Likely area

   Current code routes Git Bash through the MSYS2 shell starter and starts it with --noprofile --norc (crates/warp_terminal/src/local_tty/shell.rs). For MSYS2/Zsh shells, TerminalManager::enqueue_init_script sends the init script before PTY creation (app/src/terminal/local_tty/terminal_manager.rs). The Bash init script begins with command -p stty raw and then emits InitShell metadata (app/assets/bundled/bootstrap/bash_init_shell.sh). On Windows that path runs through the ConPTY-backed PTY implementation (crates/warp_terminal/src/local_tty/windows/mod.rs and crates/warp_terminal/src/local_tty/windows/conpty_api.rs).

   The best current hypothesis is a regression in the Windows ConPTY/MSYS2 raw-mode/startup handoff or queued init-script behavior. The nearby bash plugin detection change affects shell_plugins in the later Bootstrapped payload (app/assets/bundled/bootstrap/bash_body.sh), so it is worth checking in the regression window, but the report's observed hang occurs earlier at stty raw and does not by itself prove plugin detection is the cause.

   Duplicate check

   I enumerated all open issues and then narrowed exact searches for Starting Git Bash, stty raw, --noprofile --norc, Git Bash + CPU/hang, MSYS2 + Windows bash, and ConPTY/Windows PTY CPU reports. The closest candidates describe different surfaces such as Linux command hangs, Claude Code large-output CPU/crash behavior, SSH MSYS2 wrapper failures, or WSL rendering slowness. I did not find two or more open issues that meet the duplicate threshold for this specific Git Bash startup hang.

   Suggested next diagnostics

   Warp logs from immediately after opening a stuck Git Bash tab would help confirm whether the client sees a PTY/bootstrap event-loop error, and clarifying whether a single tab eventually recovers or remains permanently stuck would help distinguish slow startup from a hard hang.

   Question reasoning

   1. Can you attach redacted Warp logs captured immediately after opening one stuck Git Bash tab? — The report already identifies the failing startup point, but logs may show whether Warp records a ConPTY, PTY event-loop, or bootstrap hook error before the bash process starts spinning.
   2. For a single new Git Bash tab, does it eventually finish after roughly 30-40 seconds every time, or does it remain stuck indefinitely until closed? — The report describes both an indefinite hang and a 30-40+ second startup delay; distinguishing slow recovery from a permanent hang affects severity and likely failure mode.

   This is my automated analysis and may be incorrect. A maintainer will verify the details.

   Powered by Oz
3. warp-for-oss

   added

   area:performanceGeneral application performance, responsiveness, and resource usage.General application performance, responsiveness, and resource usage.

   area:performance:cpuCPU utilization, process efficiency, and compute-bound performance.CPU utilization, process efficiency, and compute-bound performance.

   area:shell-terminalTerminal input/output, shell integration, prompt behavior, and block rendering.Terminal input/output, shell integration, prompt behavior, and block rendering.

   needs-infoMore issue-specific reporter detail is needed before the problem can be confidently triaged.More issue-specific reporter detail is needed before the problem can be confidently triaged.

   os:windowsWindows-specific behavior, regressions, or requests.Windows-specific behavior, regressions, or requests.

   repro:highThe report includes enough evidence that the issue appears highly reproducible.The report includes enough evidence that the issue appears highly reproducible.

   triagedIssue has received an initial automated triage pass.Issue has received an initial automated triage pass.

   on Aug 29, 2026
4. aslan-py commented on Aug 29, 2026

   

   aslan-py

   on Aug 29, 2026

   Author

   More actions

   Attached the redacted logs (warp-logs.zip)
   Regarding the second question: for a single new Git Bash tab, it does eventually finish — it takes roughly 30–40 seconds every time, rather than hanging indefinitely. It's consistently slow to start, not a permanent hang.

   warp-logs.zip
5. warp-for-oss commented on Aug 29, 2026

   

   warp-for-ossBot

   on Aug 29, 2026

   Last edited by warp-for-oss

   Contributor

   More actions

   @aslan-py

   Here's what I found while triaging this issue:

   Thanks for the logs — they corroborate repeated slow Git Bash bootstrap failures in Warp. Based on the follow-up, this looks like a consistent ~30-40s Git Bash startup delay for a single new tab that can cascade into much worse CPU usage/unresponsiveness when several Git Bash tabs are opened, rather than a permanent single-tab hang.

   Maintainer details

   I concluded that windows Git Bash tabs in Warp v0.2026.08.26.17.59.stable_01 consistently spend ~30-40s in bootstrap on stty raw while each spawned bash process pins one CPU core, with logs corroborating repeated slow bootstrap failures..

   Triage summary

   This is a high-confidence Windows Git Bash startup performance regression in Warp. The reporter is on Warp v0.2026.08.26.17.59.stable_01 for Windows, Windows 11 Pro 10.0.26200, and Git for Windows 2.55.0.windows.5; new Git Bash tabs started by Warp get stuck on the first injected bootstrap command (command -p stty raw) while the spawned bash.exe --noprofile --norc process pins one logical CPU core. The follow-up clarifies that a single tab usually completes after roughly 30-40 seconds, but opening several tabs compounds the CPU usage and can make existing Git Bash tabs unresponsive.

   Evidence

   • The issue includes deterministic repro steps, screenshots, per-process CPU sampling, and comparisons showing PowerShell, WSL, and native git-bash.exe are not affected.
   • The attached logs contain repeated Starting direct shell process: \"C:\\Program Files\\Git\\usr\\bin\\bash.exe\" entries and repeated Bootstrapping failed for shell \"unknown\" on ssh false warnings around the reported attempts, which matches the slow-bootstrap banner path.
   • Although the template dropdown says this is not a regression, the body provides a clearer regression window: it began after updating to v0.2026.08.26.17.59.stable_01 on 2026-08-27.

   Likely affected code

   • crates/warp_terminal/src/local_tty/shell.rs special-cases MSYS2/Git Bash via ShellStarter::MSYS2 and starts bash with --noprofile --norc.
   • app/src/terminal/local_tty/terminal_manager.rs injects the shell init script for MSYS2 before PTY creation.
   • app/assets/bundled/bootstrap/bash_init_shell.sh starts with command -p stty raw and uses Windows-ConPTY-specific OSC hook emission for MSYS2.
   • crates/warp_terminal/src/local_tty/windows/mod.rs and crates/warp_terminal/src/local_tty/windows/conpty_api.rs create the Windows pseudoconsole, load the bundled conpty.dll, and attach the shell process to it.

   The reporter's proposed links to bash plugin detection and the bundled conpty.dll should be treated as hypotheses. The shell plugin payload change runs later in the bash bootstrap, while the observed stall is at the first injected stty raw command; the ConPTY/MSYS2 bootstrap boundary is the stronger current lead.

   Duplicate check

   I enumerated all 3,827 open issues, excluding pull requests and #15659, and checked recently closed issues since 2026-08-22. Exact and narrowed matches for Git Bash, MSYS2, stty raw, ConPTY/OpenConsole, startup delay, and CPU spin did not produce two or more likely duplicates; the closest open issues are SSH/MSYS2 or unrelated ConPTY/terminal behavior, not this Git Bash startup regression.

   Suggested next steps

   • Reproduce on Windows with Warp v0.2026.08.26.17.59.stable_01 and Git for Windows 2.55.0.windows.5, then compare against the prior Windows build if available.
   • Instrument timestamps around MSYS2 init-script injection, stty raw, InitShell/Bootstrapped hook receipt, ConPTY reads/writes, and the slow-bootstrap timer.
   • Check whether swapping the bundled ConPTY/OpenConsole sidecar back to the prior release changes the behavior before attributing the regression to bash payload changes.

   This is my automated analysis and may be incorrect. A maintainer will verify the details.

   Powered by Oz
6. warp-for-oss

   removed

   needs-infoMore issue-specific reporter detail is needed before the problem can be confidently triaged.More issue-specific reporter detail is needed before the problem can be confidently triaged.

   on Aug 29, 2026
7. warp-agent-staging

   assigned

   zachbai

   on Aug 29, 2026
8. warp-agent-staging

   added

   warp:auto-triage-review

   on Aug 29, 2026
9. mozex commented on Aug 30, 2026

   

   mozex

   on Aug 30, 2026

   Last edited by mozex

   More actions

   A same-version A/B that might save someone time: the trigger here is Git for Windows 2.55.0.windows.5, not Warp's build.

   Two boxes on the same Warp, v0.2026.08.26.17.59.stable_01, both running Kaspersky:

   	Box A	Box B
   Git for Windows	2.55.0.windows.5	2.55.0.windows.3
   Logical cores	24	16
   Starting direct shell process to Shell is bootstrapped	14s, 24s, 35s, 69s, 78s	1s to 2s

   Downgrading Box A to 2.55.0.windows.4 fixed it. Same Warp build, untouched, tabs now bootstrap in 2s.

   Why

   .5 (2026-08-20) is the release that moved the MSYS2 runtime to Cygwin 3.6.10. .1 through .4 ship 3.6.9. That bump pulled in git-for-windows/msys2-runtime#131, "Cygwin: pty: detect pcon-backed pty for non-Cygwin-spawned children":

   The fix scans the shared tty table during stdio_init() for a tty whose pseudo console owner PID is in our console's process list (via GetConsoleProcessList).

   Warp spawns bash.exe --noprofile --norc from a native Win32 parent into a ConPTY, which is precisely that case. It runs in stdio_init(), so it fires during process startup, before any of the bootstrap script. That's why the block sits on the first line sent (command -p stty raw) while the process pins a core.

   Everything in the bootstrap itself is fast on the affected box: stty raw in a ConPTY outside Warp 40ms, hostname and whoami ~25ms, bash -n over the 73 KB bash_body.sh 32ms, sourcing /etc/profile plus ~/.bash_profile 0.29s, bash -lic exit 0.27s. Meanwhile a live bash --noprofile --norc child of warp.exe had burned 25s of CPU without reaching a prompt.

   Workaround

   Git for Windows 2.55.0.windows.4: Cygwin 3.6.9, so no PR #131, and unlike .3 it still carries the CVE-2026-62960 fix. Then git config --global update-git-for-windows.autoUpdate false, or the updater pulls .5 back.

   Posting this for the record since it's reproducible from the version numbers alone.

   👍React with 👍1Reacted by Rares Petrescu
10. aslan-py commented on Aug 31, 2026

    

    aslan-py

    on Aug 31, 2026

    Author

    More actions

    Confirming the fix suggested by @mozex above — the culprit was Git for Windows 2.55.0.windows.5 (Cygwin 3.6.10 + patch git-for-windows/msys2-runtime#131).

    Downgraded to 2.55.0.windows.4 (https://github.com/git-for-windows/git/releases/tag/v2.55.0.windows.4) and disabled auto-update:
    git config --global update-git-for-windows.autoUpdate false

    After that, Git Bash tabs in Warp now start in 1-2 seconds instead of 30-40. This looks like an upstream Git for Windows issue rather than a Warp bug — might be worth re-labeling/tracking this as upstream and waiting for a fix in a newer .windows.N build.
11. YevheniiKotyrlo commented on Oct 20, 2026

    

    YevheniiKotyrlo

    on Oct 20, 2026

    More actions

    Git for Windows 2.56.0 ships the fix for the runtime regression behind this, so upgrading is an alternative to going back to 2.55.0(4). The slowdown is the Cygwin 3.6.10 console input path (msys2/msys2-runtime#358: pasting into bash pegs a core), whose fix Git for Windows backported in git-for-windows/msys2-runtime#144. winget upgrade Git.Git doesn't reach it yet, since winget's newest Git.Git is still 2.55.0.5; the installer from the v2.56.0.windows.2 release does.

    CPU per character typed into an interactive bash, one bash binary with only msys-2.0.dll swapped, 30 other MSYS processes running:

    Git for Windows (runtime)	CPU per character
    2.55.0(4) (Cygwin 3.6.9)	0.28 ms
    2.55.0(5) (Cygwin 3.6.10)	199 ms
    2.56.0(2) (Cygwin 3.6.10 with the fix)	0.87 ms

    These are console runs, not a Warp tab; I haven't timed a tab on 2.56.0 yet.
12. YevheniiKotyrlo commented on Oct 20, 2026

    

    YevheniiKotyrlo

    on Oct 20, 2026

    More actions

    Timed in Warp now, on Git for Windows 2.56.0(2): a Git Bash tab runs its first command 4.1 s after I open it, and four opened together all do within 10.5 s, with 88 other MSYS processes running. The same probe took 102.6 s for one tab and 122 s for four on 2.55.0(5), with 21 and 29 others. Warp also updated from v0.2026.10.07 to v0.2026.10.14 between those runs, so the console comparison above is the one that isolates the runtime.