[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_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗