claude-code - 💡(How to fix) Fix [plugin: ralph-loop] stop-hook.sh #!/bin/bash shebang fails on Windows + Git Bash

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

  1. Observe /bin/bash: cannot execute binary file in the hook error feed Stop hook executes silently when the assistant turn ends. No /bin/bash error spam in the hook error feed.

Error Messages/Logs

PreToolUse:Write hook error PostToolUse:Write hook error PreToolUse:Read hook error PostToolUse:Read hook error PreToolUse:Edit hook error PostToolUse:Edit hook error 4. Observe stderr in the hook error feed:

Root Cause

stop-hook.sh hard-codes #!/bin/bash. This assumes bash is at /bin/bash, which is true on most Linux distros and macOS, but not on:

  • Windows + Git Bash (MinGW) → /usr/bin/bash
  • Some minimal NixOS / Alpine setups
  • Custom Homebrew bash installs

Fix Action

Fix

Change shebang from #!/bin/bash to #!/usr/bin/env bash.

/usr/bin/env is part of POSIX and is the portable form recommended by autoconf, the Filesystem Hierarchy Standard, and cross-platform shell-script style guides. It resolves bash via PATH, so:

  • Linux / macOS with bash at /bin/bash → still works (env finds it via PATH)
  • Git Bash on Windows (/usr/bin/bash) → now works
  • Nix / Alpine / Homebrew custom bash paths → now works

Zero behavior change on systems where the original shebang already worked.

Code Example

/bin/bash: cannot execute binary file

---

--- a/plugins/ralph-loop/hooks/stop-hook.sh
+++ b/plugins/ralph-loop/hooks/stop-hook.sh
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/usr/bin/env bash

 # Ralph Loop Stop Hook
 # Prevents session exit when a ralph-loop is active

---

Python was not found but can be installed from the Microsoft Store: ms-windows-store://...

---

PreToolUse:Write hook error
PostToolUse:Write hook error
PreToolUse:Read hook error
PostToolUse:Read hook error
PreToolUse:Edit hook error
PostToolUse:Edit hook error

Failed with non-blocking status code: /bin/bash: /bin/bash: cannot execute binary file
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Bug

plugins/ralph-loop/hooks/stop-hook.sh in claude-plugins-official uses #!/bin/bash. On Windows, Claude Code runs .sh hooks via Git Bash (C:\Program Files\Git\usr\bin\bash.exe), where bash lives at /usr/bin/bash — there is no /bin/bash symlink. The Stop hook therefore fails on every assistant turn with:

/bin/bash: cannot execute binary file

The failure is non-blocking, but it spams stderr on every Stop event, polluting the user's terminal.

Reproduce

  1. Windows 10/11 + Claude Code installed
  2. Enable ralph-loop plugin (/plugin enable ralph-loop@claude-plugins-official)
  3. Send any prompt → assistant turn ends → Stop hook fires
  4. Observe /bin/bash: cannot execute binary file in the hook error feed

Root cause

stop-hook.sh hard-codes #!/bin/bash. This assumes bash is at /bin/bash, which is true on most Linux distros and macOS, but not on:

  • Windows + Git Bash (MinGW) → /usr/bin/bash
  • Some minimal NixOS / Alpine setups
  • Custom Homebrew bash installs

Fix

Change shebang from #!/bin/bash to #!/usr/bin/env bash.

/usr/bin/env is part of POSIX and is the portable form recommended by autoconf, the Filesystem Hierarchy Standard, and cross-platform shell-script style guides. It resolves bash via PATH, so:

  • Linux / macOS with bash at /bin/bash → still works (env finds it via PATH)
  • Git Bash on Windows (/usr/bin/bash) → now works
  • Nix / Alpine / Homebrew custom bash paths → now works

Zero behavior change on systems where the original shebang already worked.

Diff

--- a/plugins/ralph-loop/hooks/stop-hook.sh
+++ b/plugins/ralph-loop/hooks/stop-hook.sh
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/usr/bin/env bash

 # Ralph Loop Stop Hook
 # Prevents session exit when a ralph-loop is active

1 file changed, 1 insertion(+), 1 deletion(-).

Related work also surfaced during this debug

While investigating the Windows hook errors, I also found that the hookify plugin's hooks.json calls python3. On Windows with Python.org's installer, only python.exe is registered — python3.exe falls through to the Microsoft Store stub:

Python was not found but can be installed from the Microsoft Store: ms-windows-store://...

I did not propose a python3 → python upstream change because that would break Ubuntu/Debian users who lack the python-is-python3 symlink. The proper fix is more nuanced (Python launcher py.exe, wrapper script, or doc note about App Execution Aliases). Worth a separate issue / discussion if there's interest.

PR

I prepared the one-line shebang fix as a PR but the repo auto-closes external contributions: anthropics/claude-plugins-official#1938. Reproducing the diff here so the team can apply it directly if they'd like.

Environment

  • OS: Windows 10 Pro 19045
  • Shell used by Claude Code on Windows: Git Bash (C:\Program Files\Git\usr\bin\bash.exe)
  • Plugin: ralph-loop@claude-plugins-official
  • Symptom-side patched locally on my machine; reporting upstream so other Windows users benefit.

What Should Happen?

Stop hook executes silently when the assistant turn ends. No /bin/bash error spam in the hook error feed.

After the fix (#!/usr/bin/env bash), Git Bash on Windows resolves bash via /usr/bin/bash, the script body runs as designed, and stderr stays clean.

Error Messages/Logs

PreToolUse:Write hook error
PostToolUse:Write hook error
PreToolUse:Read hook error
PostToolUse:Read hook error
PreToolUse:Edit hook error
PostToolUse:Edit hook error

Failed with non-blocking status code: /bin/bash: /bin/bash: cannot execute binary file

Steps to Reproduce

  1. Use Claude Code on Windows (Git Bash as default shell)
  2. Enable the ralph-loop plugin: /plugin enable ralph-loop@claude-plugins-official
  3. Send any prompt and let the assistant turn complete
  4. Observe stderr in the hook error feed: /bin/bash: cannot execute binary file
  5. Inspect plugins/ralph-loop/hooks/stop-hook.sh line 1 — shebang is #!/bin/bash
  6. On Windows + Git Bash, bash is at /usr/bin/bash, no /bin/bash symlink exists

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.145 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Local workaround applied on my machine: patched cache + marketplace copies of stop-hook.sh to use #!/usr/bin/env bash. Patches survive until next plugin update / git pull from marketplace, hence reporting upstream.

I also opened anthropics/claude-plugins-official#1938 with the same one-line diff but it was auto-closed (repo blocks external PRs). Filing here so an Anthropic team member can pick it up.

Related sibling bug not reported here: hookify plugin's hooks.json calls python3, which on Windows resolves to the Microsoft Store stub. Worth a separate discussion — fix is more nuanced than the shebang change.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING