Sites packaging fails on Windows with GNU tar and a drive-letter archive path

Environment

• Codex Desktop on Windows
• Bundled Sites plugin: 0.1.66
• Packaging through the helper's Bash/GNU tar environment
• Observed September 12, 2026; exact Desktop and GNU tar versions were not captured

What happens

The stock Sites packaging helper fails when the output archive is specified with an absolute Windows drive-letter path.

With a valid, prepared Sites project, the following is the sanitized form of the failing command:

node "<plugin-root>/scripts/package-site.mjs" C:/work/site C:/work/site.tar.gz

The helper exited with code 1 and reported:

tar (child): Cannot connect to C: resolve failed
tar: Child returned status 128

The Node wrapper forwards its arguments to package-site.sh. That script passes the archive argument unchanged to both tar -czf and tar -tzf. GNU tar interprets the drive-letter colon as remote archive syntax. Inspection of the installed 0.1.66 helper on September 13 confirmed that argument handling.

Control and expected behavior

Changing only the archive argument to /c/work/site.tar.gz succeeded with exit code 0 in the same environment. The project path remained in Windows form; the plugin code and global configuration were unchanged.

Expected: the helper creates and validates a local archive when given a valid local Windows archive path.

Please handle archive paths for the selected Bash/tar environment in both creation and validation. The successful /c/... control applies to this environment; this report does not establish behavior for Windows BSD tar.

Start with scripts/package-site.mjs and the package-site.sh helper, tracing how the archive argument reaches both tar commands. Reproduce the provided C:/work/site.tar.gz failure and the /c/work/site.tar.gz control in the selected Bash/GNU tar environment. Done means a valid local Windows archive path works for both creation and validation without changing project-path handling.