Hook scripts shipped with CRLF line endings → "/bin/bash^M: bad interpreter" on macOS/Linux

[jenahl]

Summary

All shell scripts in the warp plugin (v2.1.0) are shipped with Windows CRLF (\r\n) line endings. On macOS/Linux the carriage return becomes part of the shebang, so the OS looks for an interpreter literally named /bin/bash\r and the hook fails:

Failed with non-blocking status code: /bin/sh:
/Users/<me>/.claude/plugins/cache/claude-code-warp/warp/2.1.0/scripts/on-post-tool-use.sh: /bin/bash^M: bad interpreter: No such file or directory

Affected files

Every .sh in scripts/ and scripts/legacy/ (14 files) has CRLF terminators, e.g.:

• scripts/on-post-tool-use.sh
• scripts/on-notification.sh
• scripts/on-permission-request.sh
• scripts/on-prompt-submit.sh
• scripts/on-session-start.sh
• scripts/on-stop.sh
• scripts/warp-notify.sh
• scripts/build-payload.sh
• scripts/emit-terminal-sequence.sh
• scripts/should-use-structured.sh
• scripts/legacy/*.sh

Confirmed via:

$ file scripts/on-post-tool-use.sh
... Bourne-Again shell script text executable, ASCII text, with CRLF line terminators
$ head -1 scripts/on-post-tool-use.sh | od -c
0000000   # ! / b i n / b a s h \r \n

Environment

• Plugin: warp v2.1.0
• OS: macOS (darwin, arm64); same failure mode applies to any Linux host

Suggested fix

1. Re-commit all *.sh with LF line endings.

2. Add a .gitattributes to keep them LF regardless of contributor platform / core.autocrlf:

   *.sh text eol=lf

Workaround

Strip the carriage returns locally (reverts on plugin reinstall):

find ~/.claude/plugins/cache/claude-code-warp -name '*.sh' -print0 | xargs -0 perl -i -pe 's/\r$//'

[jaranimo95]

Confirming this still reproduces on a fresh install of v2.1.0 (gitCommitSha bb6c1cf2f5cd7eb609678a2b175e7f4504ca61c2) on macOS (darwin 25.5.0, arm64). The post-tool-use hook fails with:

Failed with non-blocking status code: /bin/sh: .../claude-code-warp/warp/2.1.0/scripts/on-post-tool-use.sh: /bin/bash^M: bad interpreter: No such file or directory

All 14 .sh files under scripts/ and scripts/legacy/ still ship with CRLF terminators:

$ head -1 scripts/on-post-tool-use.sh | xxd | head -1
00000000: 2321 2f62 696e 2f62 6173 680d 0a   #!/bin/bash..

The 0d 0a (\r\n) on the shebang is what produces the /bin/bash^M interpreter path.

+1 on the suggested fix — committing the scripts with LF plus a .gitattributes (*.sh text eol=lf) would prevent regressions from contributors on Windows / core.autocrlf=true. The local perl -i -pe 's/\r$//' workaround resolves it until the next plugin reinstall, at which point the cache is repopulated with CRLF again.

[nodlles]

Also reproduces on macOS (darwin 24.6.0, arm64) with v2.1.0 — in my case the failing hook is the Stop hook (scripts/on-stop.sh), so this affects more than just post-tool-use:

Stop hook error: Failed with non-blocking status code: /bin/sh: .../claude-code-warp/warp/2.1.0/scripts/on-stop.sh: /bin/bash^M: bad interpreter: No such file or directory

Confirmed all 10 .sh files under scripts/ ship with CRLF. The local perl -i -pe 's/\r$//' scripts/*.sh workaround clears it until the next plugin reinstall repopulates the cache with CRLF again.

+1 on committing with LF + a .gitattributes (*.sh text eol=lf) to prevent regressions.