SessionStart hook fails with ParserError on Windows (PowerShell dispatch)

[dajcajerisa95-hue]

Description

On Windows, the SessionStart hook in hooks/hooks.json fails with ParserError before bash is invoked. The hook is non-blocking, so Claude Code still starts, but the === REMEMBER === / === MEMORY === block isn't injected into the session — defeating the plugin's core function on affected launches.

The failure is intermittent: same machine, same plugin version, sometimes succeeds, sometimes fails. When it fails, the status line shows:

SessionStart:startup hook error
Failed with non-blocking status code: ParserError:

Reproduction

Steps to reproduce:

1. Install claude-remember v0.7.2 on Windows via the claude-plugins-official marketplace.
2. Open Claude Code in any project directory.
3. Observe the SessionStart status line on la

The hook command in hooks/hooks.json that f

bash "${CLAUDE_PLUGIN_ROOT}/scripts/session-start-hook.sh"

The script itself works correctly when invokevars from PowerShell:

$env:CLAUDE_PROJECT_DIR = (Get-Location).Path
& bash "$env:CLAUDE_PLUGIN_ROOT/scripts/session-start-hook.sh"
# → emits === REMEMBER === ... correctly, exi

So the failure is in how Claude Code dispatches the hook on Windows, not in the script. PowerShell's parser interacts
badly with the ${CLAUDE_PLUGIN_ROOT} substi.json command string.

Expected behavior

Hook runs on every SessionStart, prints memorode injects it into the session context.

Actual behavior

SessionStart:startup hook error / Failed witarserError: shown in the status line. Nomemory content reaches the session context. Behavior is intermittent across launches on the same setup.

Environment

• claude-remember version: 0.7.2
• Claude Code version: 2.1.150
• Shell: PowerShell 7+ (pwsh)
• OS: Windows 11 Enterprise (10.0.26200)
• Python version: 3.12.0

[fdaviddpt]

Hey @dajcajerisa95-hue — huge thanks for this report. The reproduction steps, the side-by-side with the PowerShell snippet that does work, the environment block, the note that it's intermittent on the same machine — that level of detail is gold and saved hours of guessing. Genuinely appreciate it. 🙏

Quick status from our side:

• We've shipped test: lint hooks.json for cross-shell dispatch safety #83, which adds a lint test suite for hooks/hooks.json to catch this class of bug going forward (quoting of ${CLAUDE_PLUGIN_ROOT}, stray stderr redirects, and ${VAR} patterns that risk PowerShell parse errors). It runs on ubuntu/macos/windows in CI, including a PowerShell Parser::ParseInput check on the windows-latest runner.
• That test passes on the current hooks.json — meaning the literal command string is technically valid PowerShell syntax. So we haven't reproduced your ParserError yet, and we don't want to push a "fix" that's really a guess.

To get a real fix in, could you share a bit more diagnostic info?

1. $PSVersionTable output (in the same pwsh session where Claude Code launches).
2. Your CLAUDE_PLUGIN_ROOT value at the moment of failure — easiest way: open a Claude Code session, paste echo $env:CLAUDE_PLUGIN_ROOT in a PowerShell window started from the same env, and share the resulting path. We're specifically wondering about: spaces, non-ASCII characters, OneDrive-style paths with ', or trailing/leading whitespace.
3. A failing-run transcript if you can grab one: Start-Transcript, reproduce the failure, Stop-Transcript, paste the relevant chunk. The exact PowerShell command line Claude Code actually executes is the missing piece.
4. Claude Code's installed shell, if you know it — was Claude Code installed/launched from pwsh, Windows Terminal, VS Code's integrated terminal, or something else? (Some launchers wrap the command string differently before dispatch.)

Anything you can share narrows the failure mode down. Even partial info helps.

Thanks again for filing this so cleanly.