Describe the bug
gortex init ran on Windows creates hooks like this:
{ "command": "C:\\Users\\Borislav\\AppData\\Local\\Programs\\gortex\\gortex.exe hook", "statusMessage": "Injecting Gortex orientation snapshot...", "timeout": 3000, "type": "command" }
And I am getting this error when a hook is fired:
/usr/bin/bash: line 1: C:UsersBorislavAppDataLocal
Programsgortexgortex.exe: command not found
To Reproduce
Steps to reproduce the behavior:
- Run
gortex init from Window 11 terminal - either powershell or cmd
- make Claude invoke the hook
Expected behavior
The hook will execute the command without errors
Environment:
- OS: Windows 11
- Go version: 1.26.2
- Gortex version: v0.35.2+547451f
Additional context
Getting Claude to fix it itself produces this:
`Root cause: Claude Code on Windows defaults to running hook commands
through bash (not PowerShell). Bash doesn't understand Windows
backslash paths, so C:\Users... becomes C:Users... — all backslashes
stripped.
Fix applied: Added "shell": "powershell" to all four Gortex hooks in
.claude/settings.local.json. PowerShell handles Windows paths
correctly.
You'll need to open /hooks or restart the session for the change to
take effect.
❯ what if I change the paths to C:/Users/Borislav...?
● Yes, that would also work — Git Bash (which is what's running your
hooks, as shown by /usr/bin/bash in the error) translates C:/Users/...
forward-slash paths to Windows paths correctly.
Both approaches are valid:
┌───────────────────────┬─────────────────────────────────────────┐
│ Approach │ How it works │
├───────────────────────┼─────────────────────────────────────────┤
│ "shell": "powershell" │ Runs the command in PowerShell, which │
│ (current fix) │ natively understands backslash paths │
├───────────────────────┼─────────────────────────────────────────┤
│ C:/Users/... forward │ Git Bash auto-translates C:/ paths to │
│ slashes │ C:\ when invoking .exe files │
└───────────────────────┴─────────────────────────────────────────┘
The shell: "powershell" I already applied is slightly more robust
since it doesn't rely on Git Bash's path translation, but either would
have solved it. The root cause was bash receiving C:\Users... and
treating \U, \B, etc. as escape sequences, collapsing all the
backslashes.
✻ Worked for 21s
❯ so three backslashes would resolve it as well?
● No — three backslashes (\) in JSON is actually malformed. JSON only
recognizes \ as an escape sequence for a single backslash; a lone
trailing \ before most characters (\U, \B, etc.) is invalid JSON.
To make it work via bash you'd need four backslashes (\\ in JSON →
\ as the actual string → bash interprets \ as a single literal ).
But that's ugly and fragile.
The shell: "powershell" fix is the cleanest approach for this — no
escaping gymnastics needed.`
Describe the bug
gortex init ran on Windows creates hooks like this:
{ "command": "C:\\Users\\Borislav\\AppData\\Local\\Programs\\gortex\\gortex.exe hook", "statusMessage": "Injecting Gortex orientation snapshot...", "timeout": 3000, "type": "command" }And I am getting this error when a hook is fired:
/usr/bin/bash: line 1: C:UsersBorislavAppDataLocal
Programsgortexgortex.exe: command not found
To Reproduce
Steps to reproduce the behavior:
gortex initfrom Window 11 terminal - either powershell or cmdExpected behavior
The hook will execute the command without errors
Environment:
Additional context
Getting Claude to fix it itself produces this:
`Root cause: Claude Code on Windows defaults to running hook commands
through bash (not PowerShell). Bash doesn't understand Windows
backslash paths, so C:\Users... becomes C:Users... — all backslashes
stripped.
Fix applied: Added "shell": "powershell" to all four Gortex hooks in
.claude/settings.local.json. PowerShell handles Windows paths
correctly.
You'll need to open /hooks or restart the session for the change to
take effect.
❯ what if I change the paths to C:/Users/Borislav...?
● Yes, that would also work — Git Bash (which is what's running your
hooks, as shown by /usr/bin/bash in the error) translates C:/Users/...
forward-slash paths to Windows paths correctly.
Both approaches are valid:
┌───────────────────────┬─────────────────────────────────────────┐
│ Approach │ How it works │
├───────────────────────┼─────────────────────────────────────────┤
│ "shell": "powershell" │ Runs the command in PowerShell, which │
│ (current fix) │ natively understands backslash paths │
├───────────────────────┼─────────────────────────────────────────┤
│ C:/Users/... forward │ Git Bash auto-translates C:/ paths to │
│ slashes │ C:\ when invoking .exe files │
└───────────────────────┴─────────────────────────────────────────┘
The shell: "powershell" I already applied is slightly more robust
since it doesn't rely on Git Bash's path translation, but either would
have solved it. The root cause was bash receiving C:\Users... and
treating \U, \B, etc. as escape sequences, collapsing all the
backslashes.
✻ Worked for 21s
❯ so three backslashes would resolve it as well?
● No — three backslashes (\) in JSON is actually malformed. JSON only
recognizes \ as an escape sequence for a single backslash; a lone
trailing \ before most characters (\U, \B, etc.) is invalid JSON.
To make it work via bash you'd need four backslashes (\\ in JSON →
\ as the actual string → bash interprets \ as a single literal ).
But that's ugly and fragile.
The shell: "powershell" fix is the cleanest approach for this — no
escaping gymnastics needed.`