Skip to content

2.5.1: native Windows install - #11

Merged
plur9 merged 3 commits into
mainfrom
fix/windows-install
Sep 26, 2026
Merged

plur9 merged 3 commits into
mainfrom
fix/windows-install

Conversation

@plur9

@plur9 plur9 commented Sep 26, 2026

Copy link
Copy Markdown
Contributor

The first Windows user got ✗ Failed to install for all seven tools, with nothing streamed. Every install spawned /bin/bash, which doesn't exist on Windows.

Fixed in the same pass, because each one alone would still have broken the install:

  • which → where. Without it every tool looked missing, so init tried to install node from inside a running node.
  • npm .cmd shims are spawned through a shell. Node refuses them otherwise (CVE-2024-27980).
  • npm global binaries are looked up as <prefix>\x.cmd, not <prefix>/bin/x.
  • HOME is unset on Windows, so ~/Data resolved to the relative path Data. It now falls back to USERPROFILE.
  • winget installs by exact id with agreements pre-accepted, so an agent-driven run can't stall on a prompt.
  • After a winget install, PATH is re-read from the registry.
  • .claude is created as a junction (no admin needed), the venv interpreter is Scripts\python.exe, and python is added as an interpreter candidate.

All spawning now goes through src/lib/exec.ts. On macOS and Linux it's a passthrough. A guard test fails if /bin/bash, which or process.env.HOME || show up anywhere else.

Verified on windows-latest (new workflow). The run removes HOME to match a real user's machine, then checks:

  • where resolution
  • the npm.cmd shim runs
  • cmd.exe handles &&
  • a real npm install -g @plur-ai/mcp through runShell, and the binary is found afterwards
  • the packaged CLI's doctor detects git, node and python

Not verified: a winget install itself, and a full datacore init end to end on Windows.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GSzwHUALnUZdoW7v21dDtr

plur9 and others added 3 commits September 26, 2026 18:03
…cmd shims, USERPROFILE

The first Windows user saw "Failed to install" for all seven tools with
nothing streamed: every install spawned /bin/bash, which Windows does not
have. Behind it: `which` (absent) made every tool look missing, npm's .cmd
shims cannot be spawned without a shell, HOME is unset so ~/Data became the
relative path "Data", winget stopped on agreement prompts, and a tool it
installed stayed off PATH for the rest of the run.

All spawning now goes through src/lib/exec.ts; a guard test fails if
/bin/bash, `which`, or `process.env.HOME ||` reappear elsewhere. A
windows-latest workflow runs the real paths, since nothing here ever
executed on Windows before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GSzwHUALnUZdoW7v21dDtr
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GSzwHUALnUZdoW7v21dDtr
@plur9
plur9 merged commit a972b7d into main Sep 26, 2026
2 checks passed
@plur9
plur9 deleted the fix/windows-install branch September 26, 2026 16:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant