[BUG] Windows: path-guard hook shared with Linux denies every Edit/Write, even on its own settings file (tool_input.file_path is D:\... but hook shell $PWD/$HOME are POSIX /d/...)

Same root cause, opposite direction — and the opposite direction is the one that doesn't announce itself.

Your guard fails closed on Windows, so you find out immediately. Ours failed open and stayed that way silently. Same project, also native Windows, also a PreToolUse guard, but the rules live in a Node script instead of a Git Bash one-liner. The matching was still written against POSIX paths, while tool_input.file_path arrives as C:\Users\...\.env. Measured before the fix:

| input | decision |
|---|---|
| /home/user/ClaudeCode/.env | deny |
| C:\Users\PC_User\ClaudeCode\.env | (no decision) |

Every deny rule and every allow rule missed. Nothing errored, nothing was logged, and the hook kept exiting 0 — so from outside, a guard that matched nothing was indistinguishable from a guard that passed everything legitimately. It only mattered where the unattended runs happen to be POSIX; the Windows path was one scheduled job away from being unguarded.

Two things that might be worth separating in the fix here:

1. The path vocabulary should be normalised where the JSON is parsed, not where the comparison is written. Moving the comparison into the runtime that receives the event (rather than a shell whose $PWD/$HOME come from a different namespace) removes the mismatch instead of translating it. In our case the whole fix was normalising separators once, at the point the field is read.
2. Your consequence #2 — the guard denying .claude/settings.json itself — may survive the path fix. Separately from path format, we measured that a hook returning allow for a path under .claude/ does not beat the sandbox's own sensitive-file prompt: the hook fired, the prompt appeared anyway, and an unattended session sat on it for 13h24m because nobody was there to answer. If that layer is also in play for you, correcting $PWD will stop the mass denials but still leave the settings file hard to edit from inside the session.

A hook that is misconfigured and a hook that is satisfied both look like exit 0. That seems worth a distinct signal.

Related, from the prevention side: the docs now say the path "arrives with backslash separators, even when your hook runs under Git Bash where $PWD looks like /c/project", and I wanted a way to catch a Linux-written guard before it bites. I added exactly this case as a synthetic event to a small hook checker (Write with "file_path": "C:\\proj\\.env" piped into every Edit|Write handler, verdict BLOCKS / ALLOWS / FAIL-OPEN), so a guard that compares against $PWD shows up wrong in a dry-run instead of in a session. MIT: https://github.com/Suyann/claude-code-windows-hooks. The protect-paths hook there normalises with ${p//\\//} first, and converts the other way with cygpath when it exists, if you want a drop-in. Caveat: I have only run the bash version under Git Bash, not WSL.

_{Written with Claude Code; the checks above were run on Windows 11 / Claude Code 2.1.251 (Windows PowerShell 5.1 and Git Bash) by dry-run plus automated tests, not in a long-running real session.}

Thanks, both comments add something I had not isolated.

Consequence #2 (first comment): right in general. .claude/ writes are protected paths, and a PreToolUse allow does not skip that prompt: in 2.1.280 the safety check still runs after the hook's allow. It is the permission layer rather than the sandbox, and hooks.md doesn't list it among the allow exceptions.
Here, though, that prompt is wanted: this guard never returns allow, and Edit is under ask anyway. The lock-out comes from the hook's deny, which leaves no prompt to answer. The documented way out is restarting with --settings '{"disableAllHooks": true}', which drops every hook for that run; the terminal /hooks menu is read-only.

Docs quote (second comment): confirmed, hooks.md → PreToolUse input. Normalizing separators is enough for a deny-list, not for an allow-list anchored on the project root: ${f//\\//} gives D:/… while $PWD is /d/…, so the guard still fails closed. A dry-run would need a control Write inside the project, expected to pass, to tell a working allow-list from a fail-closed one.

Data point (2.1.280 bundle): in shell-form hooks under Git Bash, CLAUDE_PROJECT_DIR is the native path with \ replaced by /; exec-form and PowerShell hooks get it unchanged. One hook sees the same directory three ways:

| source | spelling |
|---|---|
| tool_input.file_path | D:\… |
| $CLAUDE_PROJECT_DIR | D:/… |
| $PWD | /d/… |

So after ${f//\\//} the project-root test can use $CLAUDE_PROJECT_DIR without cygpath, as long as the drive-letter case matches. The memory dir and the scratchpad have no such variable, and none of this is documented.

Scope of the ask. Tools inside a hook have to use the OS's own paths, so this is not a request to translate paths in general. But Claude Code chooses the hook shell and builds the JSON, so it is the one party that knows both spellings. Narrowly:

1. document one path format per hook type, and use it for tool_input paths, cwd and CLAUDE_PROJECT_DIR alike (or add normalized fields next to the raw ones);
2. expose the memory dir and the scratchpad the same way;
3. the hook if field already takes permission-rule syntax, which is portable, but it holds a single rule with no negation or list, so an allow-list like "project, memory dir, scratchpad" cannot be expressed; negation plus a list would let a guard like this be written with no shell path code at all;
4. a recovery path when a hook denies edits to the settings file that defines it.

Nothing in the 2.1.271–2.1.280 changelog changes hook path formats or CLAUDE_PROJECT_DIR, or adds a terminal recovery path.