feat(coding-agent): fetch portable git bash on windows

[mitsuhiko]

This is an experiment to automatically download git bash like we do for rg and find on windows. However it will unpack around 350MB of things into ~/.pi so it's not clear we actually want this.

I am leaving this on a draft PR for a little while until I get an idea of if this is something we want to entertain.

[markokocic]

Please don't, at least not by default and not without asking.

I can already see cases of pi not detecting Git bash (or other bash) installed in a non standard location and downloading another copy.

Also, many Windows installations in corporate environments are locked down, so installing won't work anyways.

A better approach would be to just check for the required tools, and then ask the user if they want them to be installed automatically, or if they want to provide a path to an already installed tool.

[mitsuhiko]

I can already see cases of pi not detecting Git bash (or other bash) installed in a non standard location and downloading another copy.

Given how pi works today, in that case pi does not work. They are hooked up to the same path.

Also, many Windows installations in corporate environments are locked down, so installing won't work anyways.

That then also affects ripgrep and fd which we also already download today.

[Demonese]

Interesting! I think it can also be implemented via plugins, and recommended official plugins can be listed in the README.

[badlogic]

@mitsuhiko rg and fd downloads fail gracefully and a small dependencies. msys is 350mb.

i propose this: our install script can offer the user to setup msys2/git bash if it finds its absent. the tricky part is that Windows users may not install via curl | sh :)

[marcfargas]

Anyone considered Busybox? https://frippery.org/busybox/
I am, will report back :P

[mitsuhiko]

@marcfargas i have indeed. Unfortunately it's shell is quite more restricted to what agents love to invoke so I'm not entirely clear if that is a good tradeoff.

[marcfargas]

Unfortunately it's shell is quite more restricted to what agents love to invoke so I'm not entirely clear if that is a good tradeoff.

Proposal:

• implement the "download sh on windows when unavailable" as an experimental feature, opt-in.
• add /download-builtin-sh that simply does that and configures shellPath accordingly
• take advantage of the experimental flag: download busybox instead of bash

Then on next release you can ask windows users to test !!!

I will report my findings on busybox nonetheless, git bash and complex pipes is miserable anyway

[mitsuhiko]

You are banned @Randy-sin

[D7x7z49]

@Demonese @mitsuhiko

This PR got me thinking about the git bash problem from a different angle.

pi already has a clean pattern: every tool has an *Operations interface, with "for example SSH" in the comments. Seven interfaces, but they separate into two concerns:

• bash, grep, find, ls — all invoke a shell
• read, write, edit — all touch a filesystem

A thin Environment layer that holds these two together under one identity:

Environment(username, hostname, port, path)
  ├── shell (bash, pwsh, python repl, ...)
  └── file  (local fs, http resources, git tree, ...)

The core tools stay exactly as they are — four tools, same structured output, same agent experience. They just call env.shell.exec() and env.file.read() instead of reaching directly for spawn() or fs. No new tools, no tool explosion.

For this PR specifically: shell.bash becomes a backend config. Portable git bash on Windows is one shell implementation. Local /bin/bash is another. SSH remote bash is a third. Same interface, pick the right one.

For pi maintainers this means: getShellConfig() and 350MB download logic live in one shell backend, not scattered across platform detection code. For third-party developers: implement shell + file, all existing tools work on your target automatically.

It's a small layer. Just giving a name to what pi's tools already assume — that there's a shell and a filesystem underneath.