Windows: run_shell and patch_file don't work (bash resolves to the WSL launcher, no patch binary)

[Flobo2689x]

Follow-up to #179/#185. With the packaged app starting on Windows, the next gap is the tools that shell out. I ran the backend suite on Windows 11: 18 failures, 453 passed. Most of them come from two tools.

What happens today

• run_shell (openbot/tools/builtin/shell.py) runs bash -lc <command>. On Windows, bash on PATH is usually C:\Windows\System32\bash.exe, the WSL launcher.
  • Without a WSL distro every call fails: <3>WSL … execvpe(/bin/bash) failed: No such file or directory, reported as exit code: 1.
  • With a distro, the command silently runs inside WSL, with Linux tools, Linux paths and a different filesystem view than the rest of the app. That seems worse than failing.
  • The timeout/cancel path uses start_new_session=True + os.killpg, which don't exist on Windows.
  • Tests: test_run_shell* (3), test_runner (2), test_token_efficiency (3).
• patch_file with a diff input (openbot/tools/builtin/files.py) runs the external patch program, which Windows doesn't have. The result is FileNotFoundError: [WinError 2], 6 failures in test_patch_file.py.

Proposal (happy to implement it, but the shell choice is your call, since run_shell is the trust boundary CONTRIBUTING.md asks to discuss):

1. On Windows, resolve bash from Git for Windows: next to git.exe on PATH (…\Git\bin\bash.exe), then %ProgramFiles%\Git\bin\bash.exe. Explicitly skip %SystemRoot%\System32\bash.exe so commands never end up in WSL by accident. The tool description stays "bash", so prompts and head/grep habits keep working.
2. If no Git Bash is found, run_shell returns a clear error ("run_shell on Windows needs Git for Windows (bash); install it from https://git-scm.com") instead of the WSL relay error.
3. Timeout/cancel on Windows: start with CREATE_NEW_PROCESS_GROUP and end the tree with taskkill /pid <pid> /T /F. os.killpg stays on POSIX.
4. patch_file: use the patch.exe that ships with Git for Windows (…\Git\usr\bin\patch.exe), found the same way, with the same clear error if missing.

Alternatives I considered: running run_shell through PowerShell would change the tool's semantics and every prompt that assumes bash; deliberately using WSL would make the workspace paths differ between tools. Git Bash seems the least surprising, but I'd rather hear your preference before touching run_shell.

The other failures are separate:

• The SPA fallback serving /api/... on Windows is fixed in fix: keep unknown API paths a 404 on Windows instead of serving the app shell #186.
• Three tests are portability issues in the tests themselves: path separators in test_validate_workspace_directory, ~/work in test_home_relative_core_web…, and 0o600 in test_key_is_generated_once_and_kept_private, since Windows has no POSIX modes. I left those alone for now.

[regnull]

Thanks for the thorough writeup and for testing on real Windows 11 again. Git Bash is the right call. The tool's contract is "bash", every prompt assumes bash idioms, and Git for Windows ships both bash and patch, so one lookup covers both gaps. Skipping System32\bash.exe explicitly is important; the silent WSL relay is the worst failure mode. PowerShell would change the tool's semantics for every prompt, and WSL would give bots a different filesystem view than the file tools. Agreed on both.

The trust boundary doesn't move here: Git Bash runs with the same host privileges run_shell already has on macOS and Linux. Go ahead.

A few requests for the PR:

• Lookup order: next to git.exe on PATH, then %ProgramFiles%\Git\bin\bash.exe, %ProgramFiles(x86)%\Git\bin\bash.exe, and %LocalAppData%\Programs\Git\bin\bash.exe (the installer's user-scope install). Prefer bin\bash.exe over usr\bin\bash.exe so the login-shell PATH setup matches what Git Bash users see in their terminal.
• patch.exe from usr\bin next to whichever Git install was found, with the same clear error when missing.
• The "install Git for Windows" message should be the tool's return value (like the other error: ... results), so the bot can relay it to the user rather than it only landing in logs.
• CREATE_NEW_PROCESS_GROUP + taskkill /T /F on Windows is consistent with what main.cjs already does for the launcher. Keep os.killpg unchanged on POSIX; the macOS/Linux path should be byte-for-byte the same after this change.
• Please include the three test portability fixes (test_validate_workspace_directory separators, ~/work in test_home_relative_core_web…, and skipping the 0o600 assertion on Windows) so the suite goes green there. Same PR or a follow-up, your choice.

The next release will ship the Windows installer with a note that run_shell and patch_file aren't functional there yet, pointing at this issue.

[Flobo2689x]

Thanks! On it. I'll follow your lookup order and include the three test portability fixes in the same PR.