fix(hooks): unquoted ${CLAUDE_PLUGIN_ROOT} in hooks.json breaks all hooks on Windows usernames with a space

[avilamichael]

Environment

• OS: Windows 11 Pro (build 26200)
• Warp: v0.2026.05.20.09.21.stable_03
• Claude Code warp plugin: 2.1.0
• Hook subprocess shell: Git Bash / MSYS (bash)
• Windows username contains a space: Michael Avila → home is C:\Users\Michael Avila

Summary

Every hook event fails before the script even runs, because the hook commands in hooks/hooks.json reference the script path unquoted. When the user's home path contains a space (very common on Windows, e.g. First Last), bash word-splits the path and tries to execute the first fragment.

This is a distinct, earlier failure from the /dev/tty / OSC 777 delivery problem tracked in #32, #36, #48 and #54 — those assume the script runs but can't deliver the notification. Here the script never starts, so notifications can't possibly work and Claude Code surfaces a hook error on every tool call. The space-in-username angle was already noted by @MillhioreBT in a comment on #32, but it isn't tracked as its own issue or diagnosed/fixed.

Actual behavior

On every hook event (most visibly PostToolUse), Claude Code shows:

PostToolUse:Read hook error
Failed with non-blocking status code: bash: /c/Users/Michael: No such file or directory

Because the PostToolUse hook has no matcher, it fires after every tool (Read, Edit, Bash, MCP calls, etc.), so the error repeats continuously.

Root cause

hooks/hooks.json (plugin 2.1.0) defines all six hooks like this:

{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/scripts/on-post-tool-use.sh" }

Claude Code runs the command through bash. On this machine CLAUDE_PLUGIN_ROOT expands to:

/c/Users/Michael Avila/.claude/plugins/cache/claude-code-warp/warp/2.1.0

Unquoted, bash splits on the space in Michael Avila, treats /c/Users/Michael as the command and Avila/.../on-post-tool-use.sh as an argument → No such file or directory.

Minimal repro:

PR="/c/Users/First Last/.claude/plugins/cache/claude-code-warp/warp/2.1.0"

# current (unquoted) — breaks:
bash -c "${PR}/scripts/on-post-tool-use.sh"
# bash: /c/Users/First: No such file or directory

# quoted — works:
bash -c "\"${PR}/scripts/on-post-tool-use.sh\""

Steps to reproduce

1. On Windows, use an account whose username contains a space (home dir C:\Users\First Last).
2. Install the warp Claude Code plugin with Git Bash available as the hook shell.
3. Trigger any tool in Claude Code. A hook error appears on every event.

Proposed fix

Quote the path in all six hook commands in hooks/hooks.json:

- "command": "${CLAUDE_PLUGIN_ROOT}/scripts/on-post-tool-use.sh"
+ "command": "\"${CLAUDE_PLUGIN_ROOT}/scripts/on-post-tool-use.sh\""

(applies equally to on-session-start.sh, on-stop.sh, on-notification.sh, on-permission-request.sh, on-prompt-submit.sh, and on-post-tool-use.sh.)

Alternatively, use the exec (args) form so the path bypasses the shell parser entirely:

{ "type": "command", "command": "bash", "args": ["${CLAUDE_PLUGIN_ROOT}/scripts/on-post-tool-use.sh"] }

Note: the scripts themselves already quote their internal variables correctly ("$SCRIPT_DIR/..."); only the entrypoint command in hooks.json is unquoted, so this is a one-line-per-hook fix.

Happy to open a PR with the quoting fix and test it on Windows 11.

[anishhjainn]

Reproduced on a second machine — confirming this isn't isolated.

• OS: Windows 11 Enterprise (build 22631)
• Plugin: warp@claude-code-warp 2.1.0
• Hook shell: Git Bash (bash)
• Username with space: Anish Jain → C:\Users\Anish Jain

Same failure on every hook event, most visibly Stop and PostToolUse:

Stop hook error: Failed with non-blocking status code: bash: /c/Users/Anish: No such file or directory

Your diagnosis is exactly right — ${CLAUDE_PLUGIN_ROOT} expands fine, but the unquoted path word-splits at the space and bash tries to exec /c/Users/Anish. Quoting each command in hooks.json (bash "${CLAUDE_PLUGIN_ROOT}/scripts/<hook>.sh") fixes all six hooks for me. +1 for getting this merged.

[manobendro]

Same issues

[gitfatsalty]

Independent confirmation on a second machine — plus a security escalation worth flagging.

Reproduced on Windows 11 (build 26100), Claude Code CLI 2.1.162, warp plugin 2.1.0, username joe dipadova (space). Same root cause you identified: all six hooks.json commands use bare unquoted ${CLAUDE_PLUGIN_ROOT}/scripts/on-*.sh; Claude Code runs them via bash -c "<command>", so the space word-splits the path. Because the PostToolUse hook has no matcher, it fires (and fails) after every tool call, and UserPromptSubmit after every prompt. With claude --debug, the log shows, verbatim:

[DEBUG] Hook UserPromptSubmit (UserPromptSubmit) error:
C:/Users/joe: line 1: /c: Is a directory

Security escalation: in your report C:\Users\Michael did not exist, so bash returned No such file or directory. On my machine a real 3-byte file existed at the split point C:\Users\joe — so bash actually executed it as a script, with the hook's trust, on every prompt and every tool call (the line 1: /c: … is that file's content being run). The content was harmless (/c), but this makes the bug a live instance of Claude Code #63370 (hook path word-split → wrong file executed with PreToolUse trust): on any Windows machine with a space in the username, a file dropped at C:\Users\<firstword> would be executed by the unquoted hook on every tool call. So this isn't only "notifications broken" — it's a code-execution vector.

Fix (verified locally): quote the path in all six commands —

{ "type": "command", "command": "bash \"${CLAUDE_PLUGIN_ROOT}/scripts/on-post-tool-use.sh\"" }

After that, all six hooks pass local reproduction, and in a live session the debug log shows Hook UserPromptSubmit (UserPromptSubmit) success: and Hook PostToolUse:Bash (PostToolUse) success: instead of the errors above.

One downstream note: once the quoting is fixed, scripts/emit-terminal-sequence.sh then hits the /dev/tty failure tracked in #43/#47/#49/#53 etc. — because Claude Code does not export CLAUDE_CODE_VERSION to hooks (it exports CLAUDE_CODE_ENTRYPOINT/_EXECPATH/_SESSION_ID/_TMPDIR, but not _VERSION), so it can't choose the modern terminalSequence JSON path and falls back to /dev/tty (no controlling TTY in a hook subprocess). Pairing the quoting fix with a claude --version fallback for version detection (or wrapping the /dev/tty write so the open-error is suppressed and the JSON fallback fires) would close both in one release.