safeSpawn false-positives on per-user Git install when cwd is the user's home directory (Windows)

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 31, 2026

Bug: safeSpawn false-positives on per-user Git install when cwd is the user's home directory (Windows)

Summary

When the Claude Code working directory is the user's home directory (e.g. C:\Users\<user>), and Git for Windows is installed per-user (e.g. via "Install for me only", landing under AppData\Local\Programs\Git), Claude Code's /plugin marketplace-add flow fails with:

Failed to clone marketplace repository: Command 'git' not found or is in an unsafe location (current directory)

git --version works fine from a normal terminal (cmd/PowerShell) at the same time, so Git itself is correctly installed and on PATH.

Root cause

The safe-command-resolution logic in the bundled CLI (bin/claude.exe) treats any resolved executable that lives underneath the current working directory as unsafe (PATH-hijacking mitigation):

function LFn(candidatePath, cwd) {
  let r = path.resolve(cwd).toLowerCase();
  let n = path.resolve(candidatePath).toLowerCase();
  if (path.dirname(n) === r || n.startsWith(r + path.sep)) return true; // treated as "unsafe"
  ...
}

This is a reasonable check when cwd is a project directory. But when Claude Code's cwd is the user's home directory itself (C:\Users\<user>), and Git is installed per-user under C:\Users\<user>\AppData\Local\Programs\Git\cmd\git.exe, the resolved git path is nested under cwd — so a completely legitimate, PATH-registered Git install gets flagged as "unsafe" and rejected. where.exe git finds no other candidate, so resolution returns null and the marketplace clone fails outright.

Repro steps

  1. On Windows, install Git for Windows with the "Install for me only" option (lands in %LOCALAPPDATA%\Programs\Git instead of C:\Program Files\Git).
  2. Open Claude Code with the working directory set to the user's home folder (C:\Users\<user>) — e.g. launch it directly from that folder without cd-ing into a project first.
  3. Run /plugin marketplace add <owner>/<repo> (or add any git-based marketplace/plugin).
  4. Observe: Failed to clone marketplace repository: Command 'git' not found or is in an unsafe location (current directory).
  5. Confirm Git works normally: open cmd.exe or PowerShell, run git --version — succeeds.

Workaround

cd into any directory that is not an ancestor of the resolved Git path (e.g. a project folder) before running /plugin. From there, cwd is no longer a prefix of the git.exe path, LFn returns false, and resolution succeeds.

Suggested fix

The "unsafe" check for "candidate nested under cwd" seems to conflate two different things: (a) a malicious binary literally sitting in the current directory (e.g. .\git.exe), and (b) a legitimately-PATH-registered binary that merely happens to live in a subdirectory of the user's home folder when the home folder itself is the cwd. Consider either:

  • Excluding well-known per-user install roots (e.g. %LOCALAPPDATA%\Programs) from the "nested under cwd" unsafe check, or
  • Only treating a candidate as unsafe if it is nested under cwd and cwd is not itself a broad ancestor like the user's home/profile directory, or
  • Preferring a candidate resolved from PATH entries that are absolute and not equal to/descendant of cwd, rather than rejecting outright when only one where.exe candidate exists.

Environment

  • OS: Windows 11 Pro 10.0.26200
  • Shell: PowerShell 5.1
  • Git: installed per-user via Git for Windows installer, resolves to %LOCALAPPDATA%\Programs\Git\cmd\git.exe
  • Claude Code cwd at time of failure: C:\Users\<user> (home directory)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗