Skip to content

fix(install): hand off Phantom install to phantom's own one-liner#2

Open
MasonStation wants to merge 1 commit intofix/install-auto-pathfrom
fix/install-phantom-handoff
Open

fix(install): hand off Phantom install to phantom's own one-liner#2
MasonStation wants to merge 1 commit intofix/install-auto-pathfrom
fix/install-phantom-handoff

Conversation

@MasonStation
Copy link
Copy Markdown
Contributor

Summary

Stops asking bun/npm to install phantom-secrets and calls phantom's own https://phm.dev/install.{sh,ps1} one-liner instead.

Why

Two real bugs in the bun/npm path on Windows, found by reproducing a fresh-machine install:

1. PS5.1 native-stderr-as-error. Stack was running:

& bun add -g phantom-secrets *> $null
if ($LASTEXITCODE -ne 0) { throw 'bun add -g phantom-secrets failed' }

inside a try/catch with $ErrorActionPreference = 'Stop'. In Windows PowerShell 5.1, redirecting a native command's stderr (*>) wraps each stderr line in a NativeCommandError ErrorRecord, which trips the catch even on exit code 0. Result: bun succeeds, installs the package, but Stack reports phantom-secrets install failed -- continuing; install manually later. (Resolving dependencies). The "Resolving dependencies" was bun's normal progress output.

2. Bun-on-Windows shim non-generation. Even when bun add -g phantom-secrets succeeds (verified by running it directly), ~\.bun\bin contains only bun.exe — the phantom shim from phantom-secrets' bin field never gets materialized. So phantom isn't on PATH and Stack's next-run Test-CommandExists 'phantom' keeps failing.

Net effect of the bun path on Windows: user installs Stack → Stack thinks Phantom failed → even if it didn't, Phantom isn't actually callable.

Fix

install.ps1:

  • Replace the bun add -g phantom-secrets / npm i -g phantom-secrets block with irm https://phm.dev/install.ps1 | iex (piped through a child powershell.exe so phantom's EAP=Stop doesn't pollute Stack's outer scope)
  • After install, refresh $env:Path from User+Machine registry so subsequent steps in this same shell can see the new entries

install.sh:

  • Keep Homebrew as the first preference on macOS (canonical, gives users brew upgrade for free)
  • Fall back to phantom's curl -fsSL https://phm.dev/install.sh | bash instead of bun add -g / npm i -g
  • Inject ~/.phantom-secrets/bin into the current shell's PATH so the rest of the script can reach phantom

packages/site/public/install.{sh,ps1} synced to scripts/.

Stacked on

This PR is stacked on #1 (install-auto-path). Please merge that one first; this rebases trivially.

Test plan

  • Fresh Windows VM: irm https://stack.ashlr.ai/install.ps1 | iex → confirm phantom install reports success in stack output and phantom --version works in a new shell
  • Fresh macOS without Homebrew: confirm fallback hits phantom's curl one-liner
  • Fresh macOS with Homebrew: confirm brew install phantom path still preferred
  • Fresh Linux: confirm curl one-liner runs
  • Re-running the installer when phantom is already present: confirm "phantom already installed" branch hits

Out of scope (worth filing separately)

  • The v0.5.1 phantom Windows binary is being blocked on at least one Windows install with An Application Control policy has blocked this file. Not signing-related (v0.5.0 in the same machine's Temp also runs unsigned). Likely Smart App Control reputation, but warrants investigation in phantom-secrets.
  • Bun-on-Windows shim generation issue is upstream — should be reported to oven-sh/bun.

🤖 Generated with Claude Code

The previous code shelled out to `bun add -g phantom-secrets` /
`npm i -g phantom-secrets`. On a fresh Windows machine that path
silently misbehaves in two ways:

1. PS5.1 + native-stderr-as-error: Stack invoked bun under
   `try/catch` with `EAP=Stop` and `*> $null`. In Windows PowerShell
   5.1 that turns bun's normal "Resolving dependencies" stderr line
   into a `NativeCommandError` that throws — so even though bun
   exits 0 and installs the package, Stack reports failure.
2. Bun-on-Windows shim non-generation: even when bun *does* succeed,
   `~\.bun\bin` ends up containing only `bun.exe` — the `phantom`
   shim from phantom-secrets' `bin` field never lands. Net effect:
   `phantom` is not on PATH after a "successful" install.

Switching to phantom's own curl/irm installer:
- Downloads the signed GitHub release directly (no lazy npm wrapper)
- Wires User PATH itself
- Sidesteps both PS5.1 and bun-on-Windows quirks
- Keeps Homebrew preference on macOS (it's still the canonical path
  there, and gives users `brew upgrade` for free)
- Refreshes `$env:Path` from the registry after install so subsequent
  Stack steps see the new entries

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@vercel
Copy link
Copy Markdown

vercel Bot commented Apr 26, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
ashlr-stack Ready Ready Preview, Comment Apr 26, 2026 8:03pm

Request Review

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