fix: handle WSL bash as default shell on Windows

[zeynalnia]

Summary

• Fixes SessionStart hook error when WSL's bash.exe is the default shell on Windows
• Uses wslpath to convert Windows paths to WSL format, with fallback for non-WSL environments

Problem

When WSL's bash.exe is in PATH (either alone or before Git's bash.exe), Claude Code passes Windows-style paths that WSL bash cannot resolve, causing "No such file or directory" errors.

How to reproduce

• PATH contains only WSL's bash.exe path, OR
• PATH contains both WSL and Git bash.exe paths but WSL comes first

Fixes #275

Test plan

• Test on Windows with WSL bash as default shell
• Test on Windows with Git Bash only
• Test on native Linux/macOS

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Improved Windows Subsystem for Linux compatibility when running hooks by preferring a WSL-friendly path and automatically falling back to the original path if conversion fails, ensuring more reliable hook execution across environments.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Updated the SessionStart hook command to attempt converting CLAUDE_PLUGIN_ROOT to a WSL-style path with wslpath -u, then fall back to the original path if conversion fails.

Changes

Cohort / File(s)	Summary
Hook Configuration Update hooks/hooks.json	SessionStart hook command changed to `"$(wslpath -u '${CLAUDE_PLUGIN_ROOT}')/hooks/run-hook.cmd" session-start.sh

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related issues

• Windows: backslash path handling breaks hook execution double-shot-latte#8 — Addresses the same Windows-to-WSL path handling problem in hook invocations by preferring a WSL-converted plugin path.

Possibly related PRs

• Add Windows support for plugin hooks #134 — Modifies the same hook invocation approach; this change aligns with that PR's edits to run-hook invocation.

Poem

🐰 I hopped through paths both backslash and slash,
I nudged a hook to try WSL first, then dash—fallback!
Now startup sings without a fright,
Hooks run smooth, both day and night. 🥕✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main fix: handling WSL bash as the default shell on Windows by using wslpath for path conversion.
Linked Issues check	✅ Passed	The PR successfully addresses issue #275 by implementing wslpath-based path conversion with fallback for WSL bash compatibility.
Out of Scope Changes check	✅ Passed	The changes are focused solely on fixing the SessionStart hook command for WSL bash compatibility; no unrelated or out-of-scope modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@hooks/hooks.json`:
- Line 9: The command string in hooks.json currently uses single quotes around
${CLAUDE_PLUGIN_ROOT} inside the wslpath call which prevents environment
variable expansion; update the command so CLAUDE_PLUGIN_ROOT is expanded (e.g.,
use double quotes or no inner quotes) when calling wslpath, ensuring the
resulting path feeds into run-hook.cmd and session-start.sh correctly (refer to
the "command" value, the wslpath invocation, ${CLAUDE_PLUGIN_ROOT}, and
run-hook.cmd/session-start.sh).

[zeynalnia]

@coderabbitai The single quotes around ${CLAUDE_PLUGIN_ROOT} are intentional and necessary.

Claude Code expands ${CLAUDE_PLUGIN_ROOT} before passing the command to the shell. So by the time the shell sees it, the command is:

wslpath -u 'C:\Users\Name With Spaces\.claude\plugins\...'

The single quotes protect against word splitting when the path contains spaces. Without them:

wslpath -u C:\Users\Name With Spaces\...
# Shell splits this into multiple arguments, causing failure

With single quotes, the entire path is treated as a single argument to wslpath, which is the correct behavior.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@zeynalnia Thank you for the clarification! You're absolutely right. I understand now that since Claude Code expands ${CLAUDE_PLUGIN_ROOT} before the shell sees the command, the single quotes are essential to protect the resulting Windows path (which may contain spaces) from word splitting.

Your explanation makes perfect sense:

• With quotes: wslpath -u 'C:\Users\Name With Spaces\...' → single argument ✓
• Without quotes: wslpath -u C:\Users\Name With Spaces\... → multiple arguments ✗

I appreciate you taking the time to explain Claude Code's variable expansion behavior. This is important context for understanding the correct quoting strategy in this hook system.

---

✏️ Learnings added

Learnt from: zeynalnia
URL: https://github.com/obra/superpowers/pull/282

Timestamp: 2026-01-17T10:04:35.426Z
Learning: In the superpowers plugin for Claude Code, when using `${CLAUDE_PLUGIN_ROOT}` in hook commands (hooks/hooks.json), single quotes around the variable are necessary because Claude Code expands variables before passing the command to the shell. The quotes protect against word splitting when the expanded path contains spaces (e.g., 'C:\Users\Name With Spaces\...').

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

[obra]

This looks like it is likely to fail on everything that's not Windows. Have you tested it on Mac OS and Linux? Is it something that we can address inside the polyglot wrapper script?