Short summary
On Windows, the agent-merge skill runs its helper script with bare bash (e.g. bash check-merge-conditions.sh <owner> <repo> <pr>). On a standard Windows dev box that has WSL installed, bash resolves to C:\Windows\System32\bash.exe (the WSL launcher), so the script executes inside the WSL distro, where the Copilot-bundled gh and the user's jq are not on PATH. The script fails immediately with No such file or directory / exit 127, so agent-merge cannot evaluate merge conditions.
Affected version or release
- GitHub Copilot app: 0.2.27
- Copilot CLI: 1.0.60
- OS: Windows 11 Enterprise (10.0.26200)
- WSL: installed (default distro Ubuntu-22.04)
- Git for Windows: 2.53.0.windows.3 (Git Bash present at
C:\Program Files\Git\bin\bash.exe but NOT on PATH, which is the Git for Windows default)
What happened?
When agent-merge follows the skill instructions and runs bash check-merge-conditions.sh ...:
/bin/bash: C:Users...app-skills\agent-merge\check-merge-conditions.sh: No such file or directory
# exit 127
The script never runs because:
bash resolves to the WSL launcher (System32\bash.exe), not Git Bash.
- Inside WSL, the Copilot-bundled
gh (%LOCALAPPDATA%\copilot-desktop-gh-*\gh) and the user's jq (mise shim) are not available, so even when the path is corrected the script's gh/jq calls fail.
Confirmed root cause on this machine: the only bash.exe entries on PATH are the two WSL launchers (System32, WindowsApps); C:\Program Files\Git\bin is intentionally not on PATH (Git for Windows default). So bare bash -> WSL is the out-of-the-box outcome.
Why this is not environment-specific
This reproduces for the common configuration class "Git for Windows (default install) + WSL installed", not a one-off misconfiguration:
- Git for Windows deliberately keeps
bash off PATH to avoid shadowing system tools.
- WSL places
bash.exe in System32.
- Therefore bare
bash -> WSL is the default behavior for a large population of Windows dev machines, and the skill always invokes bare bash.
It happens on every agent-merge run/session on such a machine.
Workaround
Invoking the script through Git Bash explicitly works, because Git Bash inherits the Windows PATH and can see the bundled gh and the jq shim:
& "C:\Program Files\Git\bin\bash.exe" -lc "/c/Users/.../agent-merge/check-merge-conditions.sh <owner> <repo> <pr>"
(With Git Bash the WSL/PATH problem is gone; a separate Failed to fetch requested reviewers / exit 2 can still occur from the script's reviewer fetch, but that is a different layer.)
Suggested fixes
- When running skill
.sh scripts on Windows, prefer Git Bash (C:\Program Files\Git\bin\bash.exe) over a bare bash that resolves to WSL.
- Or ensure the interpreter used for skill scripts can see the Copilot-bundled
gh and jq.
- Or provide a PowerShell-native execution path / fallback for these skills on Windows.
Related
Short summary
On Windows, the agent-merge skill runs its helper script with bare
bash(e.g.bash check-merge-conditions.sh <owner> <repo> <pr>). On a standard Windows dev box that has WSL installed,bashresolves toC:\Windows\System32\bash.exe(the WSL launcher), so the script executes inside the WSL distro, where the Copilot-bundledghand the user'sjqare not on PATH. The script fails immediately withNo such file or directory/ exit 127, so agent-merge cannot evaluate merge conditions.Affected version or release
C:\Program Files\Git\bin\bash.exebut NOT on PATH, which is the Git for Windows default)What happened?
When agent-merge follows the skill instructions and runs
bash check-merge-conditions.sh ...:The script never runs because:
bashresolves to the WSL launcher (System32\bash.exe), not Git Bash.gh(%LOCALAPPDATA%\copilot-desktop-gh-*\gh) and the user'sjq(mise shim) are not available, so even when the path is corrected the script'sgh/jqcalls fail.Confirmed root cause on this machine: the only
bash.exeentries on PATH are the two WSL launchers (System32,WindowsApps);C:\Program Files\Git\binis intentionally not on PATH (Git for Windows default). So barebash-> WSL is the out-of-the-box outcome.Why this is not environment-specific
This reproduces for the common configuration class "Git for Windows (default install) + WSL installed", not a one-off misconfiguration:
bashoff PATH to avoid shadowing system tools.bash.exeinSystem32.bash-> WSL is the default behavior for a large population of Windows dev machines, and the skill always invokes barebash.It happens on every agent-merge run/session on such a machine.
Workaround
Invoking the script through Git Bash explicitly works, because Git Bash inherits the Windows PATH and can see the bundled
ghand thejqshim:(With Git Bash the WSL/PATH problem is gone; a separate
Failed to fetch requested reviewers/ exit 2 can still occur from the script's reviewer fetch, but that is a different layer.)Suggested fixes
.shscripts on Windows, prefer Git Bash (C:\Program Files\Git\bin\bash.exe) over a barebashthat resolves to WSL.ghandjq.Related