fix(coding-agent): run %%bash cells in Git Bash on Windows, not WSL bash

[FiveTechSoft]

Problem

On Windows, a bare %%bash cell in the IPython kernel resolves bash through CreateProcess, which finds C:\Windows\System32\bash.exe (WSL) before anything on PATH — even when Git Bash is installed and earlier in PATH.

Inside WSL there is no Git Credential Manager, so git push (or any command that prompts) blocks on a username/password prompt that the kernel can never answer — the kernel runs with allow_stdin: false and no TTY. The cell hangs until the user aborts, and the kernel can die with it. Observed in a real session as a 3-minute hang on git push, with commits authored as root@<host>.localdomain (the WSL default identity).

Fix

• Bare %%bash cells are rewritten to %%script <Git Bash> by default on Windows via a new getWindowsIpythonBashScriptPath() helper (utils/shell.ts). An explicit shellPath setting still wins. Git Bash is located in the standard install dirs or derived from git.exe on PATH.
• The resolved path is converted to its 8.3 short path with forward slashes (C:/PROGRA~1/Git/bin/bash.exe). This is required because IPython parses %%script lines on Windows with shlex in non-posix mode, which keeps quotes literally and mangles backslash escapes — verified against the installed IPython: only a space-free, forward-slash path survives parsing (quoteScriptMagicArgument now also keeps ~ unquoted for this).
• The kernel env now defaults to GIT_TERMINAL_PROMPT=0 (kernel/index.ts): when no credential helper can answer, git fails fast with a clear error instead of hanging the cell forever. An explicit host or per-kernel value still takes precedence.

Verification

• 3 new tests in ipython-provisioner.test.ts (Windows default applied, explicit shellPath wins, no Git Bash → cell untouched). They fail against the old code and pass with the fix.
• End-to-end simulation of the script magic with the real kernel venv (arg_split + create_subprocess_exec + cell via stdin): runs Git Bash (/mingw64/bin/git, credential.helper=manager) and a git ls-remote to a nonexistent repo authenticates via GCM and fails fast in ~2s — no hang.
• npm run check (biome + tsgo + installer + browser-smoke) passes. The 6 remaining test failures on Windows (fake-python sh stubs, chmod-based EACCES) are pre-existing on main and unrelated.

Note

Fix %%bash cells to use Git Bash on Windows instead of WSL bash

• On Windows, bare %%bash cells (with no explicit shell arguments) are rewritten to %%script invocations using a resolved Git Bash path via the new getWindowsIpythonBashScriptPath() helper in utils/shell.ts.
• Git Bash discovery scans standard Program Files locations and also checks for bash.exe relative to any git.exe found on PATH, replacing previously hardcoded paths.
• Windows paths with spaces are converted to 8.3 short paths (via PowerShell/COM) to avoid breaking IPython's %%script argument parser; ~ is also left unquoted to prevent corruption of Windows short paths.
• Kernel child processes now default to GIT_TERMINAL_PROMPT=0 across both forked and directly spawned code paths.
• Behavioral Change: on Windows, %%bash cells will run in Git Bash instead of WSL bash when Git Bash is available; cells are left unchanged if no suitable path is found.

^{Macroscope summarized 3bbe038.}

[khanra17]

Validated the integration on Windows 11 x64 with Git for Windows:

• Bare %%bash cells resolve to C:/PROGRA~1/Git/bin/bash.exe, so they do not fall through to WSL's System32\\bash.exe.
• An explicit shellPath still wins.
• GIT_TERMINAL_PROMPT=0 makes headless Git credential failures return instead of hanging the kernel.

When combined with #744, the IPython path should remain the public Git Bash launcher, while daemon Job Object execution should retain #744's direct usr\\bin\\bash.exe path. The short-path conversion and git.exe-relative discovery are integration details; I am not opening a separate PR for them.

[kevinjosethomas]

Hi, thanks for taking the time to contribute to Prime Agent! Since open sourcing the project, we’ve received far more pull requests than we can responsibly review and validate. Prime Agent runs directly on users’ machines, so we need to be deliberate about which changes we accept and how they are reviewed. Rather than leave a large backlog that we cannot meaningfully work through, we’re closing the current PR queue and moving to a discussion-first contribution process.

We have established new contribution guidelines to help us continue iterating on Prime Agent and better manage contributions from the community. Going forward, we won’t review unsolicited pull requests. Instead, please start with a GitHub Discussion. We’ll identify recurring bugs and feature requests, create Issues for work we want to pursue, and invite pull requests from maintainers or vouched contributors when implementation is ready. Please read the full process documented in our contribution guidelines.

While we’re closing this backlog, we’re still reviewing it at a high level to identify recurring bugs, useful ideas, and important problems that we should address ourselves. Thanks again for the time you put into this!