feat(cli): Add a PowerShell installer for Windows

[sentry-junior]

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

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

Both install and install.ps1 resolve stable releases through Sentry's release registry (apps/sentry/{latest|<version>}), which provides the version, asset URLs, and SHA-256 checksums. Both prefer the .gz asset and fall back to the raw binary if that asset is unavailable; registry outages fall back to GitHub with a warning (those fallback downloads are not checksum-verified). A shared scenario table in packages/cli/test/lib/install-scenarios.ts exercises both installers against the same behavior cases.

install.ps1 hands off to sentry cli setup --install --method curl, then manages the Windows user PATH itself because setup currently edits POSIX shell rc files only. It preserves existing %VAR% entries, writes to GITHUB_PATH in Actions, and honors SENTRY_VERSION, SENTRY_INSTALL_DIR, SENTRY_INIT, SENTRY_NO_MODIFY_PATH, and SENTRY_CLI_NO_TELEMETRY. The script runs inside a function so irm | iex does not change caller preferences or close the terminal on failure.

The Install Scripts workflow smoke-tests both installers on real runners when either installer or the workflow changes: bash on Ubuntu and macOS, and PowerShell on Windows PowerShell 5.1 and PowerShell 7. Each job verifies sentry --version and that a later step can find sentry on PATH.

Scope:

• The PowerShell installer is stable-only; install stable and run sentry cli upgrade nightly for nightly.
• The PowerShell installer supports Windows x64.
• Moving install-directory resolution and Windows PATH management into sentry cli setup remains a follow-up.
• Scoop is not included.

The docs site serves install.ps1; the landing page install selector and getting-started guide include the Windows PowerShell option.

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 17, 2026 12:29am 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.}