Prompt: Fix pi's broken bash tool on Windows (use this on the affected machine)

Copy the text between the markers below and paste it into pi on the machine where the bash tool is broken. It walks through diagnosis and the fix.

START OF PROMPT

My pi bash tool is broken on Windows. When I ask you to run any command, you never get real output — instead every command returns only a Microsoft Windows cmd banner (Microsoft Windows [Version ...] and a C:\Users\...> prompt) and nothing actually executes. File writes via the shell also silently fail. The read/write/edit tools still work fine. Please diagnose and fix this.

Background facts you should use:

  • Pi (the @earendil-works/pi-coding-agent) runs on Windows and is supposed to use Git Bash for its bash tool. Its own documentation (docs/windows.md inside the pi package) says the shell is resolved in this order:
    1. A custom shellPath in ~/.pi/agent/settings.json
    2. Git Bash at C:\Program Files\Git\bin\bash.exe
    3. bash.exe found on PATH (Cygwin/MSYS2/WSL) The exact symptom above (cmd banner, nothing executes) is what happens when pi ends up spawning plain cmd.exe instead of a real bash.
  • The most common root cause is that ~/.pi/agent/settings.json contains "shellPath": "C:\\Windows\\System32\\cmd.exe" (set by an earlier session or by the user experimenting). Pi honors that custom path first, so it uses cmd forever.

Steps:

  1. Read the config: read the file ~/.pi/agent/settings.json (expand ~ yourself; on this Windows machine it is C:\Users\<username>\.pi\agent\settings.json). Do NOT rely on the shell to read it — use your read tool, since the shell is broken.
  2. If the file does not exist, create it with your write tool containing at minimum a JSON object with a shellPath key (see step 3 for the value).
  3. If shellPath is set to anything other than a real bash, change it to the absolute path of Git Bash, using proper JSON escaping of backslashes, e.g.: "shellPath": "C:\\Program Files\\Git\\bin\\bash.exe". Verify that bash actually exists there before relying on it: use your read tool on C:\Program Files\Git\bin\bash.exe — if it is a binary (you'll get binary content or a "not a text file"-style error), it exists; if you get ENOENT, it does not. If Git Bash is not at the default location, find it by asking the user where Git Bash is installed, or check the usual spots:
    • C:\Program Files\Git\bin\bash.exe
    • C:\Users\<username>\AppData\Local\Programs\Git\bin\bash.exe
    • anywhere Git for Windows was installed (its bin folder contains bash.exe) If no Git Bash can be found at all, an alternative fix is to switch pi's shell tool to PowerShell instead, by setting "defaultTools": ["read", "powershell", "edit", "write"] in the same settings.json. Prefer Git Bash if available.
  4. Preserve every other key already in settings.json — edit only shellPath (and/or defaultTools if falling back to PowerShell). Do not drop keys like defaultProvider, defaultModel, extensions, etc.
  5. IMPORTANT: pi reads shellPath only at startup, so tell the user to FULLY QUIT pi (exit the process — not just end the session) and relaunch it before testing.
  6. After the user restarts pi, verify the fix by running simple bash commands such as echo "$BASH_VERSION" and pwd. Real bash output (e.g. 5.x.x(...)-release) means it worked. If you still see the cmd banner, re-read settings.json to confirm the edit survived, and check whether a stale settings cache exists.

Please start by reading the settings file and reporting what shellPath is set to.

END OF PROMPT