Windows: `Rel: can't make <file> relative to <base>` on every Write/Edit when the project is on a different drive from the plugin

[namlh-mx]

Summary

On Windows, when the project lives on a different drive letter than the base the hook relativizes against, every Write/Edit injects this into the model's context as additionalContext:

Rel: can't make D:\Projects\App\src\Foo.cs relative to C:\Users\me\.claude\plugins\cache\claude-plugins-official\semgrep\2.1.2

Go's filepath.Rel returns an error for paths on different Windows volumes (golang/go#13259) — there is no relative path between C:\… and D:\…. Plugins are always installed under ~/.claude on C:, so any project on D: (or any other drive) hits this on every single file write.

This looks like a regression from the fix for #49 / #50: the old bug was filepath.Join($PWD, absolutePath); the fix appears to have moved to relativizing against a base, which introduced a cross-volume failure the previous code did not have.

Environment

• Plugin: semgrep@claude-plugins-official v2.1.2 (latest; hook-windows-amd64.exe)
• Claude Code 2.1.211
• Windows 11 26200.8875, x86_64, Git Bash (OSTYPE=msys, bash 5.2.37) — not WSL
• Project on D:, plugin cache + ~/.semgrep on C:

Reproduction

With Claude Code open on a project on D:, any Write or Edit produces the error above as additionalContext. It also reproduces by piping a payload straight into the binary — and note the base is not the payload's cwd field, it tracks the process $PWD (consistent with the observation in #49 that the binary ignores stdin cwd):

cd /d/Projects/App
python - <<'PY'
import json
BS = chr(92)
p = {"session_id":"probe","transcript_path":"C:"+BS+"temp"+BS+"t.jsonl",
     "cwd":"D:"+BS+"Projects"+BS+"App",
     "hook_event_name":"PostToolUse","tool_name":"Write",
     "tool_input":{"file_path":"C:"+BS+"Users"+BS+"me"+BS+"scratch"+BS+"x.cs","content":"class X {}"},
     "tool_response":{"success":True}}
open("payload.json","w").write(json.dumps(p))
PY

HOOK=~/.claude/plugins/cache/claude-plugins-official/semgrep/2.1.2/scripts/hook.sh
bash "$HOOK" claude PostToolUse < payload.json

Observed:

{"hookSpecificOutput":{"additionalContext":"Rel: can't make C:\\Users\\me\\scratch\\x.cs relative to D:\\Projects\\App","hookEventName":"PostToolUse"}}

The base is whichever side the process happens to be on, so the error fires in both directions: a D: project writing a C: file, and a C:-rooted process touching a D: file.

Impact

1. Context pollution: a misleading Rel: can't make … line is fed to the model on every file write. It reads like a real failure, and the agent has no way to tell it is a plugin-internal path bug.
2. It makes the hook's behaviour on Windows unexplainable from the outside — this error is the only output the hook ever produces here (see the companion issue: Windows: hook binary is inert — every event returns {}, no findings ever, no guardian-cache written #59 — the hook returns {} and reports no findings even when the paths are on the same drive).

Likely fix

Don't relativize for the purpose of opening/scanning a file — filepath.Rel has no valid answer across volumes. If a repo-relative path is needed for reporting, guard it:

rel, err := filepath.Rel(base, file)
if err != nil {
    rel = file // different volume (or otherwise unrelatable): fall back to the absolute path
}

and keep using the absolute path for I/O. A filepath.VolumeName(base) != filepath.VolumeName(file) check up front would make the intent explicit.

Related

• path/filepath: confusing error message for Rel golang/go#13259 — filepath.Rel error message across drives
• Pre/PostToolUse hook prepends $PWD to absolute file_path → doubled path, "no such file or directory" #49 / Hook binary doubles absolute file_path (no IsAbs check) → open: no such file noise + silent SAST no-op in git worktrees #50 — the path-doubling bugs this appears to have regressed from
• Windows: guardian MCP server fails to launch (.mcp.json runs hook.sh via /bin/bash → path mangled) → infinite login loop #53 — Windows .mcp.json launcher (same platform, adjacent area)

[liukatkat]

Thanks for the report! I have filed a ticket internally (GDN-149) about this issue

[namlh-mx]

Follow-up on v2.1.3 — good news / bad news.

Good news: the exact repro I posted above (project on D:, plugin cache on C:, edited file inside the D: project) is fixed. Re-tested today:

# cwd = D:\Projects\<my-project>, plugin cache still on C:
# wrote a real vulnerable C# file (hardcoded SQL connection password) *inside* the D: project

→ the PostToolUse hook fired normally, returned a real finding (sqlconnection-hardcoded-secret, correct line), no Rel error. That matches #59 too — same-drive-as-project edits are getting scanned again.

Bad news: there's a narrower case that still reproduces the identical Rel failure — editing a file that itself lives outside the project, on a different drive than cwd. E.g. from a Claude Code session with cwd = D:\Projects\<my-project>, editing an unrelated file at C:\Users\<me>\.some-tool\config.json (not under the project at all) immediately gives:

Rel: can't make C:\Users\<me>\.some-tool\config.json relative to D:\Projects\<my-project>

Same signature as my original report, just a stricter reproduction: instead of "project drive vs. plugin-cache drive," it's "edited-file drive vs. cwd drive," which doesn't require the project and the plugin cache to be on different drives at all — it happens on this machine (project on D:) any time an edit touches something outside the project tree (dotfiles, a global config, etc.).

Given GDN-149 is already filed for the general Rel issue, flagging this in case the original fix scoped itself to "file is somewhere under the project directory" rather than the general cross-volume case — the filepath.Rel(base, file) guard I suggested in the issue body (fall back to the absolute path on err != nil, or check filepath.VolumeName up front) would need to cover this path too, not just project-root-relative paths.

Environment: plugin semgrep@claude-plugins-official v2.1.3 (haven't tried 2.1.4 yet — will update and re-test if useful).