SessionStart hook fails on Windows due to HCS sandbox blocking bash execution #417

New issue

Closed

opened 2026-02-04 19:32:49 +00:00 by Vanman989 · 1 comment

Vanman989 commented

2026-02-04 19:32:49 +00:00

(Migrated from github.com)

On Windows with WSL2 installed, the session-start.sh hook fails every startup with:

SessionStart:startup hook error

Debug log shows:

Hook output does not start with {, treating as plain text
Hook SessionStart:startup (SessionStart) error:
Logon failure: the user has not been granted the requested logon type at this computer.
Error code: Bash/Service/CreateInstance/CreateVm/HCS/0x80070569

Root Cause

Claude Code 2.1.x auto-detects .sh files in hook commands and routes them through bash execution, which on Windows triggers the HCS (Hyper-V Host Compute
Service) sandbox. On machines where corporate Group Policy restricts HCS logon types, the sandbox VM creation fails with 0x80070569
(ERROR_LOGON_TYPE_NOT_GRANTED), and the hook returns the Windows error instead of JSON.

The hook script itself is fine — running bash session-start.sh directly from Git Bash works perfectly. The issue is specifically the sandbox wrapper
around bash execution for hooks.

Environment

Windows 11, domain-joined corporate machine
Claude Code v2.1.31
Superpowers v4.1.1
WSL2 installed (Ubuntu default)
Git Bash at C:\Program Files\Git\bin\bash.exe
vmcompute service running
No Docker Desktop

Suggested Fix

Ship a PowerShell version of session-start.sh (session-start.ps1) and update hooks.json to use it on Windows. PowerShell execution doesn't go through the
bash/HCS sandbox path.

Alternatively, use a .cmd wrapper or node script that avoids the .sh extension entirely, since Claude Code specifically targets .sh files for bash
routing.

This is similar to the approach taken in v4.1.0 where hooks.json was updated to call session-start.sh directly instead of through run-hook.cmd after
Claude Code 2.1.x changed the Windows execution model.

On Windows with WSL2 installed, the session-start.sh hook fails every startup with: SessionStart:startup hook error Debug log shows: Hook output does not start with {, treating as plain text Hook SessionStart:startup (SessionStart) error: Logon failure: the user has not been granted the requested logon type at this computer. Error code: Bash/Service/CreateInstance/CreateVm/HCS/0x80070569 Root Cause Claude Code 2.1.x auto-detects .sh files in hook commands and routes them through bash execution, which on Windows triggers the HCS (Hyper-V Host Compute Service) sandbox. On machines where corporate Group Policy restricts HCS logon types, the sandbox VM creation fails with 0x80070569 (ERROR_LOGON_TYPE_NOT_GRANTED), and the hook returns the Windows error instead of JSON. The hook script itself is fine — running bash session-start.sh directly from Git Bash works perfectly. The issue is specifically the sandbox wrapper around bash execution for hooks. Environment - Windows 11, domain-joined corporate machine - Claude Code v2.1.31 - Superpowers v4.1.1 - WSL2 installed (Ubuntu default) - Git Bash at C:\Program Files\Git\bin\bash.exe - vmcompute service running - No Docker Desktop Suggested Fix Ship a PowerShell version of session-start.sh (session-start.ps1) and update hooks.json to use it on Windows. PowerShell execution doesn't go through the bash/HCS sandbox path. Alternatively, use a .cmd wrapper or node script that avoids the .sh extension entirely, since Claude Code specifically targets .sh files for bash routing. This is similar to the approach taken in v4.1.0 where hooks.json was updated to call session-start.sh directly instead of through run-hook.cmd after Claude Code 2.1.x changed the Windows execution model.

obra commented

2026-02-05 19:57:13 +00:00

(Migrated from github.com)

Partial fix update

The terminal freeze that results from hook failures has been fixed on main:

async: true (961052e): Hook failures no longer block the TUI

However, the HCS sandbox issue itself is distinct and unaffected by our fixes. The hook will still fail on corporate machines where Group Policy restricts Hyper-V sandbox creation — it just won't freeze the terminal anymore.

The CLAUDE_PLUGIN_ROOT path mangling issue is tracked at #420 (upstream at anthropics/claude-code#23204), but this HCS issue is a separate execution path problem.

## Partial fix update The terminal freeze that results from hook failures has been fixed on main: - **`async: true`** (`961052e`): Hook failures no longer block the TUI However, the **HCS sandbox issue** itself is distinct and unaffected by our fixes. The hook will still fail on corporate machines where Group Policy restricts Hyper-V sandbox creation — it just won't freeze the terminal anymore. The CLAUDE_PLUGIN_ROOT path mangling issue is tracked at **#420** (upstream at anthropics/claude-code#23204), but this HCS issue is a separate execution path problem.