fix: run shell tools via PowerShell on Windows (closes #11)#12
Merged
Conversation
The shell and bash tools hardcoded /bin/sh and /bin/bash, which don't exist on Windows, so every command failed with `ENOENT: no such file or directory, uv_spawn '/bin/sh'` (issue #11). On Windows now: - Spawn commands through PowerShell (-NoProfile -NonInteractive -Command), overridable via PFLOW_WINDOWS_SHELL. - Skip the macOS/BSD portability rewrite and GNU-flag guards (they target Unix tools and would corrupt or wrongly block PowerShell commands). - Tear down the child tree with `taskkill /T /F` and leave the process attached, since POSIX process groups/signals don't apply. - Surface PowerShell-appropriate tool descriptions/schema. POSIX behavior is unchanged. All 596 tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Make the platform check call-time (isWindows()) and export shellInvocation so the Windows code paths are testable from a POSIX CI host. Adds tests that the shell/bash tools target PowerShell (not /bin/sh) on win32, honor PFLOW_WINDOWS_SHELL, skip the Unix grep -P rewrite, and surface PowerShell guidance — guarding against a regression of issue #11. 602 tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PentesterFlow
added a commit
that referenced
this pull request
Jun 12, 2026
* fix: run shell tools via PowerShell on Windows instead of /bin/sh The shell and bash tools hardcoded /bin/sh and /bin/bash, which don't exist on Windows, so every command failed with `ENOENT: no such file or directory, uv_spawn '/bin/sh'` (issue #11). On Windows now: - Spawn commands through PowerShell (-NoProfile -NonInteractive -Command), overridable via PFLOW_WINDOWS_SHELL. - Skip the macOS/BSD portability rewrite and GNU-flag guards (they target Unix tools and would corrupt or wrongly block PowerShell commands). - Tear down the child tree with `taskkill /T /F` and leave the process attached, since POSIX process groups/signals don't apply. - Surface PowerShell-appropriate tool descriptions/schema. POSIX behavior is unchanged. All 596 tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: cover Windows PowerShell shell invocation Make the platform check call-time (isWindows()) and export shellInvocation so the Windows code paths are testable from a POSIX CI host. Adds tests that the shell/bash tools target PowerShell (not /bin/sh) on win32, honor PFLOW_WINDOWS_SHELL, skip the Unix grep -P rewrite, and surface PowerShell guidance — guarding against a regression of issue #11. 602 tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: SecFathy <kabtest91@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On Windows, every command failed with:
ShellToolandBashToolhardcoded/bin/sh//bin/bashand spawned them directly (src/tools/shell.ts). Those paths don't exist on Windows, so the spawnENOENT'd regardless of whether the user ran from CMD or PowerShell. Fixes #11.Fix
When
process.platform === 'win32':powershell.exe -NoProfile -NonInteractive -Command <cmd>, overridable withPFLOW_WINDOWS_SHELL(e.g.pwsh.exe).grep -P → perlrewrite and the GNU-only-flag guards target macOS/BSD/Linux tooling; under PowerShell they would corrupt commands or throw misleading "use macOS/BSD" errors.taskkill /pid <pid> /T /F.POSIX behavior is unchanged (Windows code paths are all guarded by
IS_WINDOWS).Not covered
The reporter also noted local models "seem to have issues with WSL." That's a separate networking matter (agent in WSL reaching a model server on the Windows host) unrelated to the
/bin/shspawn bug, so it's out of scope here.Verification
npm run typecheck✅npm run lint✅npx vitest run— 596/596 pass ✅🤖 Generated with Claude Code