Hook `command` field is wrapped in bash -c '...'; substituted paths with apostrophes brick the session

Summary

Plugin hooks declared as {"type": "command", "command": "node ${CLAUDE_PLUGIN_ROOT}/setup.js"} are wrapped in bash -c '...' for execution. When ${CLAUDE_PLUGIN_ROOT} (or any other interpolated value) expands to a path containing an apostrophe, the apostrophe terminates the outer single-quote and bash exits with unexpected EOF while looking for matching '. The hook fails before any tool call can run; with a PreToolUse hook this bricks the entire session - every tool call errors before executing.

Repro

1. Windows machine with home path containing an apostrophe (e.g. C:\Users\Jane O'Neill\...).
2. Install any plugin with a PreToolUse or SessionStart hook of the form:

``json
{
"type": "command",
"command": "node ${CLAUDE_PLUGIN_ROOT}/.claude-plugin/setup.js"
}
``

1. Launch a Claude Code session. Every subsequent tool call fails with the bash EOF error. (Real-world hit: corbin-claude-skills plugin, multiple users.)

Why no plugin-side fix works

• Quoting the substitution (e.g. "${CLAUDE_PLUGIN_ROOT}" or '\''...'\'') doesn't help - the apostrophe is inside the expanded value, not in the command string the plugin author wrote. Any escaping is applied before substitution.
• Argv-form invocation would solve this cleanly, but the hook command schema is a single shell string today; there's no args array.
• Same failure class affects spaces, backticks, ampersands, parentheses, and other shell-special characters - apostrophes are just the most common Windows-username case.

Requested fix

Either:

1. Add argv-form support to the hook schema, e.g.:

``json
{
"type": "command",
"command": "node",
"args": ["${CLAUDE_PLUGIN_ROOT}/.claude-plugin/setup.js"]
}
``

so Claude Code can execvp directly without any shell interpretation; or

1. Properly escape interpolated values before composing the bash -c argument (escape ' to '\'' inside the expansion).

Argv-form is the more robust answer - it sidesteps shell quoting entirely for any path with any special character on any shell.

Workaround for affected users

setx CLAUDE_CONFIG_DIR C:\ClaudeHome (or any apostrophe-/space-free path) and re-launch.