Summary
./setup fails on Windows when upgrading past v1.34.1.0. The build npm script in package.json uses POSIX subshell-redirect syntax (( cmd ) > file) which Bun on Windows refuses to execute. This blocks every Windows user from auto-upgrading via /gstack-upgrade.
Repro
- Windows 11 (Build 26200), MINGW64 / Git Bash, Bun v1.3.13
- Global git install at
~/.claude/skills/gstack on v1.34.1.0
- Run
/gstack-upgrade (or the inline upgrade flow)
git fetch + git reset --hard origin/main succeed — checks out v1.39.1.0
./setup runs bun install which triggers the build script
Error
$ bun run vendor:xterm && bun run gen:skill-docs --host all; bun build --compile ... && bash browse/scripts/build-node-server.sh && ( git rev-parse HEAD 2>/dev/null || true ) > browse/dist/.version && ...
error: Failed to run script build due to error
Subshells with redirections are currently not supported. Please open a GitHub issue.
Root cause
package.json build script (on main @ v1.39.1.0) contains:
( git rev-parse HEAD 2>/dev/null || true ) > browse/dist/.version
( git rev-parse HEAD 2>/dev/null || true ) > design/dist/.version
( git rev-parse HEAD 2>/dev/null || true ) > make-pdf/dist/.version
(rm -f .*.bun-build || true)
Bun's built-in shell (used to run npm scripts on Windows where there's no /bin/sh) does not support ( ... ) > file. This is a tracked limitation in oven-sh/bun.
Suggested fixes
Any of these would work without dropping POSIX-shell compatibility:
- Move version-stamping into a tiny
.sh or .ts script and call it: bash scripts/stamp-versions.sh (or a bun run script).
- Use
git rev-parse HEAD > file 2>/dev/null || true — no subshell needed (the 2>/dev/null redirect goes on the command, || true swallows failure separately).
- Run the build via
bash -c "..." explicitly instead of relying on Bun's shell.
Same pattern at the tail ((rm -f .*.bun-build || true)) should be fixed too, though it's the version-stamp lines that are hit first.
Environment
- OS: Windows 11 Home, Build 10.0.26200
- Shell: MINGW64_NT-10.0-26200 (Git Bash)
- Bun: 1.3.13
- gstack: 1.34.1.0 → 1.39.1.0 (failed)
- Install type:
global-git at ~/.claude/skills/gstack
Impact
Auto-upgrade is enabled by default. Every Windows user on v1.34.1.0 or earlier will hit this on their next /gstack-upgrade. The harness rolls back, so no data loss, but they're stuck below v1.34.2.0 indefinitely.
Summary
./setupfails on Windows when upgrading past v1.34.1.0. Thebuildnpm script inpackage.jsonuses POSIX subshell-redirect syntax (( cmd ) > file) which Bun on Windows refuses to execute. This blocks every Windows user from auto-upgrading via/gstack-upgrade.Repro
~/.claude/skills/gstackon v1.34.1.0/gstack-upgrade(or the inline upgrade flow)git fetch+git reset --hard origin/mainsucceed — checks out v1.39.1.0./setuprunsbun installwhich triggers thebuildscriptError
Root cause
package.jsonbuildscript (onmain@ v1.39.1.0) contains:Bun's built-in shell (used to run npm scripts on Windows where there's no
/bin/sh) does not support( ... ) > file. This is a tracked limitation in oven-sh/bun.Suggested fixes
Any of these would work without dropping POSIX-shell compatibility:
.shor.tsscript and call it:bash scripts/stamp-versions.sh(or abun runscript).git rev-parse HEAD > file 2>/dev/null || true— no subshell needed (the2>/dev/nullredirect goes on the command,|| trueswallows failure separately).bash -c "..."explicitly instead of relying on Bun's shell.Same pattern at the tail (
(rm -f .*.bun-build || true)) should be fixed too, though it's the version-stamp lines that are hit first.Environment
global-gitat~/.claude/skills/gstackImpact
Auto-upgrade is enabled by default. Every Windows user on v1.34.1.0 or earlier will hit this on their next
/gstack-upgrade. The harness rolls back, so no data loss, but they're stuck below v1.34.2.0 indefinitely.