[Bug] Hook executor mangles Windows paths - backslashes stripped when expanding ${CLAUDE_PLUGIN_ROOT}

Bug Description

On Windows, the hook executor strips backslashes from paths when expanding ${CLAUDE_PLUGIN_ROOT}, causing hook scripts to fail with "No such file or directory".

Environment

• OS: Windows 11
• Claude Code version: Latest (as of 2026-02-07)
• Plugin: ralph-loop (uses Stop hook)
• Shell: Default Windows environment (Git Bash available)

Steps to Reproduce

1. Install the ralph-loop plugin on Windows
2. Run /ralph-loop "Test task" --max-iterations 2 --completion-promise "DONE"
3. Complete the first iteration and let the stop hook trigger

Expected Behavior

The stop hook should execute successfully, intercepting the exit and feeding the prompt back for the next iteration.

Actual Behavior

The stop hook fails with the following error:

Stop hook error: Failed with non-blocking status code: /bin/bash:
C:UsersYKL.claudepluginscacheclaude-plugins-officialralph-loop2cd88e7947b7/hooks/stop-hook.sh: No such file or directory

Root Cause Analysis

The issue is in how the hook executor resolves and passes paths on Windows:

1. hooks.json defines: "command": "${CLAUDE_PLUGIN_ROOT}/hooks/stop-hook.sh"
2. ${CLAUDE_PLUGIN_ROOT} expands to a Windows path: C:\Users\YKL\.claude\plugins\cache\...\ralph-loop\2cd88e7947b7
3. When the expanded path is passed to the shell, all backslashes are stripped:

• Expected: C:\Users\YKL\.claude\plugins\cache\...\stop-hook.sh
• Actual: C:UsersYKL.claudepluginscache...stop-hook.sh

Additionally, the executor tries to use /bin/bash which doesn't exist on Windows (Git Bash installs to C:\Program Files\Git\bin\bash.exe).

Impact

This affects all plugins that use hook scripts (.sh) on Windows, not just ralph-loop. Any plugin defining hooks via hooks.json with ${CLAUDE_PLUGIN_ROOT} will have the same path mangling issue.

Suggested Fix

The hook executor should:

1. Properly handle Windows-style paths (backslashes) when expanding variables
2. Detect the platform and use an appropriate shell (e.g., bash.exe from Git for Windows, or PowerShell)
3. Alternatively, convert Windows paths to forward slashes before passing to bash (bash on Windows accepts /c/Users/... style paths)