Windows npm install fails when Git for Windows' GNU tar is first on PATH #41

Issue

The Windows npm installation path fails when Git for Windows' GNU tar appears before the Windows system bsdtar on PATH.

The hanzo package depends on @hanzo/cli. During @hanzo/cli's postinstall, npm/install.js downloads hanzo-windows-amd64.tar.gz, verifies its published SHA-256 digest, and then invokes an unqualified tar with a drive-letter absolute archive path:

execFileSync("tar", ["-xzf", tmp, "-C", dest]);

On the affected setup, tar resolves to D:\Git\usr\bin\tar.exe (GNU tar 1.35). GNU tar interprets the colon in the D:\... archive argument as remote archive syntax, so extraction fails after the download and checksum verification have succeeded.

Steps to reproduce

1. On Windows, install Git for Windows and put its usr\bin directory before C:\Windows\System32 on PATH.

2. Confirm the resolution order:

   Get-Command tar -All

   On my machine this lists Git GNU tar first and the Windows system bsdtar second.

3. The documented global command is shown first; this reproduction used the isolated-prefix equivalent so no global state was changed:

   # Documented user path
   npm install -g hanzo@9.0.2
   
   # Equivalent postinstall path used for this reproduction
   npm install --prefix <empty-project> hanzo@9.0.2

Expected behavior

The checksum-verified Windows archive is extracted and hanzo.exe is installed.

Actual behavior

The install exits with status 1:

npm error command C:\Windows\system32\cmd.exe /d /s /c node install.js
npm error tar (child): Cannot connect to hanzo\cli\<pid>-hanzo-windows-amd64.tar.gz: resolve failed
npm error gzip: stdin: unexpected end of file
npm error tar: Child returned status 128
npm error @hanzo/cli: Command failed: tar -xzf D:\...\<pid>-hanzo-windows-amd64.tar.gz -C D:\...\@hanzo\cli\bin

I reproduced the same extraction failure twice, both in isolated prefixes: once with a fresh npm install (lifecycle scripts enabled), and once with npm rebuild @hanzo/cli in a second isolated prefix.

Control test

Using the exact same downloaded archive with the Windows system bsdtar succeeds:

C:\Windows\System32\tar.exe -xzf <same-archive> -C <empty-directory>

The extracted binary then runs successfully:

hanzo 8.5.910

This isolates the failure to extractor selection rather than the release asset, download, or checksum verification.

Root cause

npm/install.js assumes that any tar found on Windows accepts drive-letter absolute paths. That is true for Windows' bundled bsdtar, but not for GNU tar with its default remote-archive parsing.

Related: the lazy installer was introduced in #28; this is a distinct failure in its archive-extraction step.

Suggested direction

On Windows, prefer the system bsdtar by absolute path (for example, %SystemRoot%\System32\tar.exe) or another explicitly tested extractor instead of an arbitrary tar from PATH. The existing argument-array execution and SHA-256 verification should remain unchanged.

A native Windows regression test should cover an installation path containing a drive letter, spaces, and Unicode, with Git GNU tar earlier on PATH.

Version and model info

• Windows 11 23H2, build 22631.4890, zh-CN
• Node.js v24.12.0
• npm 11.6.2
• hanzo@9.0.2
• @hanzo/cli@8.5.910
• Git for Windows GNU tar 1.35
• Windows system bsdtar 3.7.7
• Model: not applicable; failure occurs during npm postinstall before Hanzo Dev starts