[BUG] Windows path resolution bug in plugin hooks
Resolved 💬 2 comments Opened Feb 15, 2026 by evaldas-pq Closed Feb 15, 2026
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The problem is in hooks.json line 9. The hook command uses ${CLAUDE_PLUGIN_ROOT} which resolves to a Windows path like C:\Users\USER\.claude\plugins\cache\... — but then it's passed to /bin/bash which can't parse Windows backslash paths.
What Should Happen?
the ${CLAUDE_PLUGIN_ROOT} variable is resolved by Claude Code internally before passing to the shell, and it's producing a Windows-native path instead of a MSYS-compatible one (/c/Users/...). This is a bug in how Claude Code handles plugin hook paths on Windows.
Error Messages/Logs
Stop hook error: Failed with non-blocking status code: /bin/bash: C:UsersUSER.claudepluginscacheclaude-plugins-officialralph-loop2cd88e7947b7/hooks/stop-hook.sh: No such file or directory
Steps to Reproduce
run claude in vscode terminal
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude Code v2.1.42
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗