feat(cli): Add a PowerShell installer for Windows

[sentry-junior]

Windows users can now install the standalone CLI without Git Bash or WSL:

irm https://cli.sentry.dev/install.ps1 | iex

To keep install and install.ps1 from drifting, both now resolve releases the same way. They ask Sentry's release registry (apps/sentry/{latest|<version>}) for the version, the download URL and the sha256 checksum of the asset. The registry covers old getsentry/cli releases too, so the GitHub tag probing and the legacy fallbacks are gone from the bash installer. Downloads are now checksum-verified, preferring .gz and falling back to the raw asset. GitHub is only used, unverified and with a warning, when the registry is unreachable. A shared scenario table (test/lib/install-scenarios.ts) runs against both scripts with the same mock contract, so any behavior difference fails CI.

install.ps1 hands off to sentry cli setup --install --method curl, so sentry cli upgrade keeps working. Setup only edits POSIX shell rc files, so for now the installer adds the install dir to the user PATH itself. It writes the registry value as REG_EXPAND_SZ so existing %VAR% entries are kept, and it also writes to GITHUB_PATH in Actions. It reads SENTRY_VERSION, SENTRY_INSTALL_DIR, SENTRY_INIT, SENTRY_NO_MODIFY_PATH, and SENTRY_CLI_NO_TELEMETRY. All the code runs inside a function, so running it through iex doesn't change the caller's preferences, and failures throw instead of calling exit.

The new Install Scripts workflow smoke-tests install.ps1 on real Windows runners. It installs latest with Windows PowerShell 5.1 and with PowerShell 7, and installs pinned legacy 0.42.2 with PowerShell 7. It checks sentry --version and that sentry is on PATH in a later step.

Scope decisions:

• The PowerShell installer is stable-only (it points at sentry cli upgrade nightly) and x64-only.
• Moving install-dir resolution and Windows PATH editing into sentry cli setup is a follow-up.
• Scoop isn't part of this PR.

The docs site serves the script through a public/install.ps1 symlink. The landing page selector gets a powershell option, and the getting-started page gets a Windows section.

Closes #1510

via byk.

--

View Junior Session [Sentry]

[vercel]

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

Project	Deployment	Actions	Updated
sentry-local	Ready	Preview	Oct 15, 2026 8:38pm UTC

[BYK]

Somewhat crazy idea: how much of this you can abstract so we don't duplicate logic between install.sh and install.ps1? Maybe with like a common syntax, AST, replacing template etc? Because we want to avoid drift between these two.

[sentry-junior]

Short version: I wouldn't build a shared syntax, AST, or transpiler. I'd make both scripts thin enough that there's very little left to drift.

Why not codegen. The duplicated parts are exactly where bash and PowerShell differ most: HTTP status handling, error and exit semantics, gzip, and pipes. Generated output would also be harder to audit, and people do read install scripts before piping them into a shell.

What actually removes the duplication. The release registry already returns everything both scripts work out by hand:

• release-registry.services.sentry.io/apps/sentry/{latest|<version>} returns file_urls per asset plus sha256-hex checksums.
• That includes legacy versions: 0.42.2 resolves to getsentry/cli/releases/download/0.42.2/..., and 0.47.0 resolves to getsentry/toolkit/.../cli@0.47.0/....

Each script could then shrink to the same five steps:

1. Detect the OS and architecture, giving the asset name.
2. Fetch the registry metadata (latest or pinned).
3. Download file_urls[asset].gz, falling back to the raw asset, and verify the sha256. That's a new safety win: neither script checks checksums today.
4. Hand off to sentry cli setup --install --method curl .... This already owns placement, completions, skills and login.
5. Optionally run sentry init.

That deletes the paginated GitHub release scan, the toolkit-vs-legacy tag probing, and the legacy releases/latest fallback from both scripts. The open question is whether we keep a GitHub fallback for registry outages. I'd keep a single releases/latest/download/<asset> fallback for the latest case only, and fail pinned installs if the registry is down.

Two smaller pieces:

• Install dir: have sentry cli setup print or emit the resolved install dir, instead of each script re-implementing determineInstallDir(). That's a third copy today, after the TS and bash ones. In PowerShell, moving user-PATH registry editing into setup on win32 would also remove the PATH code from install.ps1.
• Drift guard: run one table of test cases against both scripts, covering registry latest/pinned/outage, gz-missing, setup failure and init failure. The same fixtures would back both mocks, so any behavior difference fails CI. If we want, the few shared constants (DSN, project ID, registry URL) can come from one TS module via a tiny template step.

Happy to do this either as part of this PR (bash + ps1 together) or as a follow-up that slims install first and then ports it. Which do you prefer?

[BYK]

Happy to do this either as part of this PR (bash + ps1 together) or as a follow-up that slims install first and then ports it. Which do you prefer?

Let's do it here in this PR.

[BYK]

Just gonna assume this works. Maybe have a smoke test for this in a Windows runner in GitHub Actions?

[sentry-junior]

Done in this PR, as discussed:

• Registry first. install and install.ps1 now both take the version, the download URL and the sha256 for each asset from the release registry, legacy getsentry/cli releases included.
• Simpler bash script. The GitHub tag probing and the legacy fallbacks are gone.
• Checksums. Downloads are now checksum-verified.
• GitHub fallback. GitHub is only used, unverified and with a warning, while the registry is unreachable.
• Drift guard. test/lib/install-scenarios.ts is one scenario table that runs against both scripts with the same mock contract. It already caught a Windows PowerShell 5.1 JSON-array bug in the GitHub fallback.
• Windows CI. The Install Scripts workflow smoke-tests install.ps1 on real Windows runners: PowerShell 5.1 and 7 for latest, and PowerShell 7 for pinned legacy 0.42.2.

Install-dir resolution and Windows PATH editing still live in the scripts rather than in sentry cli setup. I left that for a follow-up.

The PR description above is out of date: it still describes the old GitHub-based version lookup.

[BYK]

Install-dir resolution and Windows PATH editing still live in the scripts rather than in sentry cli setup. I left that for a follow-up.

File this as an issue and start working on it.

The PR description above is out of date: it still describes the old GitHub-based version lookup.

Update it then and then merge the PR when CI passes and no review comments left.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9c94663. Configure here.}