[Bug] v2.1.30 regression: CLI freezes when SessionStart hook errors (Windows)
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?
Claude Code v2.1.30 freezes completely on startup when a SessionStart hook returns an error. The CLI displays SessionStart:startup hook error then becomes permanently unresponsive — no input accepted, no timeout, requires force-kill.
This is a regression. In earlier versions, hook errors were displayed as warnings but the CLI continued functioning normally.
The freeze is triggered by the known Windows hook execution failure (see #21468), but the freeze itself is a separate bug — hook errors should never render the CLI unresponsive.
What Should Happen?
When a SessionStart hook errors, Claude Code should:
- Log the error
- Display a warning to the user
- Continue startup normally
Error Messages/Logs
SessionStart:startup hook error
After this message, the CLI is completely frozen. No prompt appears, no input is accepted.
Steps to Reproduce
- Install Claude Code v2.1.30 on Windows 11
- Enable the superpowers plugin (
superpowers@claude-plugins-official: true) - Launch
claudefrom any project directory - Observe:
SessionStart:startup hook errorappears, CLI freezes indefinitely
Note: Any SessionStart hook that errors should reproduce the freeze — superpowers is just the most common trigger on Windows due to #21468.
Claude Model
None
Is this a regression?
Yes — earlier versions displayed the error but continued to a working prompt.
Last Working Version
~v2.1.27 (hook error was displayed but CLI remained functional)
Claude Code Version
2.1.30
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Git Bash 5.2.37 (MSYS2)
Additional Information
Compounding factor
Large accumulated session .jsonl files in ~/.claude/projects/ (370MB+) appear to exacerbate the hang duration. Cleaning these files (see #22041) helps but does not fix the root cause.
Why this is NOT a duplicate of #21468 / #22337
Those issues track the hook execution failure on Windows (.sh scripts not executing, path handling). This issue tracks a separate bug: Claude Code's error handling when any hook fails — the CLI should not freeze regardless of why the hook errored.
| Issue | Bug | Status |
|-------|-----|--------|
| #21468 | Hook script never executes on Windows | OPEN |
| #22337 | Path handling strips backslashes | OPEN (duplicate) |
| This issue | CLI freezes when hook errors | NEW |
Workaround
Disable the plugin to prevent the hook from running:
{
"enabledPlugins": {
"superpowers@claude-plugins-official": false
}
}
Also clean up large session files to reduce hang severity:
find ~/.claude/projects -name "*.jsonl" -size +10M -delete
Suggested Fix
The hook runner in Claude Code should have:
- A timeout for hook execution (e.g., 30s)
- Graceful error recovery — catch hook failures and continue startup
- Never block the main event loop waiting on a failed hook
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Same issue with v2.1.31 on windows 11 with the "simplest" possible settings.json:
{
"permissions": {
"allow": [],
"deny": []
},
"hooks": {
"SessionStart": [
{
"hooks": [
{
"type": "command",
"command": "cmd /c exit 0"
}
]
}
]
}
}
Retested the failing startup path on Windows with the current Claude Code release and could not reproduce the freeze.
Environment:
2.1.207CLAUDE_CONFIG_DIRTest settings:
The debug log recorded the intentional failure:
Claude Code then immediately continued through the remaining startup path and reached authentication/API handling instead of hanging. The entire process completed in under two seconds.
This confirms graceful recovery from a non-zero SessionStart hook in the current non-interactive startup path. Unless the interactive TUI path still behaves differently, the v2.1.30 regression appears fixed and this issue can likely be closed.