# The Scoop Installer: One Line That Sets Up a Windows Package Manager

> The ScoopInstaller/Install repository is a single PowerShell script that installs Scoop into the current user's profile, and its documentation is mostly about the two things that stop it from running: the PowerShell language mode and the execution policy. It also documents proxies, custom directories, an admin mode that is off by default, and the exit code behaviour that CI pipelines depend on.

**ScoopInstaller/Install** — 📥 Next-generation Scoop (un)installer

- Repository: https://github.com/ScoopInstaller/Install
- Website: https://get.scoop.sh
- Stars: 1,303 · Forks: 155
- Language: PowerShell
- License: Unlicense
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/scoopinstaller-install

## One Script, Two Things to Get Right

The Scoop (un)installer is a single PowerShell script, install.ps1, and the whole installation for most people is one line:

```powershell
irm get.scoop.sh | iex
```

The command is run from a non-admin PowerShell, and it installs Scoop with the default configuration into C:\Users\<YOUR USERNAME>\scoop.

The catch, and the reason this repository has a README rather than a single file, is that the script is subject to two PowerShell settings that are outside the script's control. The language mode is required to be FullLanguage to run the installer and Scoop, and the execution policy is required to be one of RemoteSigned, Unrestricted or ByPass.

The execution policy is the one people hit, because on a managed Windows machine the default policy often blocks downloaded scripts. The fix the README gives is scoped to the current user, which is the least invasive form:

```powershell
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
```

The prerequisites are also stated in terms of what you need installed: PowerShell at the latest version, or Windows PowerShell 5.1.

## The Default Install Goes Into the User Profile

The location of the install is the decision with the longest tail, and the default is deliberate.

Scoop is installed to C:\Users\<YOUR USERNAME>\scoop rather than to a machine wide directory, which means the installation is per user, requires no administrator rights, and disappears with the user profile. A team that wants a shared installation for a build agent has to say so explicitly.

The reason the default path matters more than it looks is what it implies about upgrades. A per user install can be updated by that user, and a shared one cannot be updated by anyone who is not an administrator, which is the usual reason a shared install goes stale.

The script itself is fetched over the network and executed immediately, which is why the advanced path exists at all. Downloading the script first means you can read it before you run it:

```powershell
irm get.scoop.sh -outfile 'install.ps1'
```

The README treats this as the normal way to do an advanced installation, and the one-line command as the convenient one. The script accepts parameters, and the way to see them is to ask the script itself with the question mark switch:

```powershell
.\install.ps1 -?
```

The project has a CI badge and a test/ directory, and the PSScriptAnalyzerSettings.psd1 file at the root shows that the script is linted with PSScriptAnalyzer rather than only being tested.

## Proxies and Custom Directories

Two situations are called out with their own recipes, and both are the kind of detail that otherwise turns into a support question.

The first is network trouble reaching GitHub, since that is where Scoop fetches its manifests. The proxy can be passed to the download and to the installer itself:

```powershell
iex "& {$(irm get.scoop.sh -Proxy 'http://<ip:port>')} -Proxy 'http://<ip:port>'"
```

or set through the standard environment variables before running the normal command, with HTTP_PROXY and HTTPS_PROXY set to the proxy address.

The second is the location. The advanced parameters let you install Scoop to a custom directory, configure Scoop to install global programs to a custom directory, and bypass the system proxy during installation, with the custom directories required to be absolute paths:

```powershell
.\install.ps1 -ScoopDir 'D:\Applications\Scoop' -ScoopGlobalDir 'F:\GlobalScoopApps' -NoProxy
```

The legacy method is also still supported, using the SCOOP and SCOOP_GLOBAL environment variables, with the global one also written to the machine environment so that later sessions see it, and then the normal one-line install.

The split into a global directory and a per user directory is worth understanding, because it is the difference between a tool everybody on the machine can run and a tool only your account can run, and the second parameter is how you choose between them.

## Admin Installs Are Disabled on Purpose

The installer runs as administrator only if you ask for it, and the README is explicit about the reason.

Installation under the administrator console has been disabled by default for security considerations. If you know what you are doing and want to install Scoop as administrator, you download the installer and manually execute it with the -RunAsAdmin parameter in an elevated console.

The two documented forms are the downloaded script with the parameter, and a one-line command that fetches the script and runs it with the same parameter:

```powershell
iex "& {$(irm get.scoop.sh)} -RunAsAdmin"
```

The reasoning behind the default is not stated in detail, but the shape of it is clear. A package manager that installs to a machine wide location and runs with elevated rights is a much larger blast radius than the same tool installed into one user's profile, and an installer that defaults to the elevated path would be a bad neighbour on a shared machine.

So the parameter exists, the documentation explains when to use it, and the default is the conservative one. That is a sensible design for a script whose whole job is to be run by someone who has just read a one-line command.

## The Installer in a CI Pipeline

Using Scoop in CI is common enough that the README gives it its own section, and the example is a GitHub Actions step:

```yaml
- name: Install Scoop
  shell: pwsh
  run: irm get.scoop.sh | iex
```

Then comes the part that costs people an afternoon, which is the note about the exit code. If the CI environment does not have the $env:CI variable set, you might need to explicitly exit $LASTEXITCODE to propagate the installation result to the pipeline, or set $env:CI before the installation command.

```yaml
- name: Install Scoop
  shell: pwsh
  run: |
    irm get.scoop.sh | iex
    exit $LASTEXITCODE
```

The reason is that the pipeline step and the script are different things. The shell step reports the exit code of the last command, and a pipeline that sees a zero from the last line of a script does not know whether the installation itself succeeded. Propagating $LASTEXITCODE explicitly is what makes a failed install fail the job.

The silent installation section covers the same concern from the other side, since a noisy installer in a CI log is not useful. You can redirect all outputs to Out-Null or to a log file, and $LASTEXITCODE will be 0 when the installation succeeded.

## A Small Repository With an Odd Licence

The repository is small, and the size is the point. The top level holds a .editorconfig, a .gitattributes, the .github/ workflows, a .gitignore, a .vscode/ directory, the LICENSE, the PSScriptAnalyzerSettings.psd1, the README, install.ps1 and a test/ directory.

One script, one test directory and one lint configuration is the whole thing. The CI badge points at a workflow, and the release history is empty, since the project publishes no GitHub releases. The last push was on 2026-08-28, and the repository is not archived.

The licence is the notable detail. The project is released under the Unlicense License and into the public domain. That is a deliberate choice for an installer: the script is meant to be read, copied and run, and a public domain dedication removes any question about what a user is permitted to do with it, including modifying it and shipping it inside your own setup scripts.

For an organisation rolling out Windows tooling, that is the property that matters most about this repository, and it is the reason the script is also shipped in the way it is, downloadable and parameterised rather than only available as a pipe to iex.

The homepage is get.scoop.sh, and the documentation is entirely in this README, which is appropriate for a project whose interface is a command line rather than a library.

## Conclusion

The Scoop installer fits a Windows user or a CI pipeline that needs a package manager without a machine wide installer, because it installs into the user profile and needs no administrator rights in the default path. It is a poor fit if your machines have a locked down execution policy, since the script cannot run at all under a policy that forbids it, and it is a poor fit for unattended enterprise deployment, where the GPO or a software distribution system is the right mechanism. Before running it, read the prerequisites, because the two most common failures are a language mode that is not FullLanguage and an execution policy that is not one of the three allowed values, and note that the admin path is disabled by default and must be requested explicitly with -RunAsAdmin. The project is released under the Unlicense into the public domain, publishes no GitHub releases, and the last push was on 2026-08-28.

## FAQ

### How do I install Scoop on Windows?

Run `irm get.scoop.sh | iex` from a non-admin PowerShell, and Scoop is installed into C:\Users\<YOUR USERNAME>\scoop with the default configuration. You need PowerShell at the latest version or Windows PowerShell 5.1, the language mode must be FullLanguage, and the execution policy must be RemoteSigned, Unrestricted or ByPass.

### Why does the Scoop installer fail to run?

The two most common reasons are given in the README. The PowerShell language mode is required to be FullLanguage to run the installer and Scoop, and the execution policy is required to be one of RemoteSigned, Unrestricted or ByPass, which can be set for the current user with `Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser`.

### Can I install Scoop to a custom directory?

Yes. Download the installer with `irm get.scoop.sh -outfile 'install.ps1'` and run it with parameters such as -ScoopDir and -ScoopGlobalDir, which must be absolute paths, plus -NoProxy to bypass the system proxy. The legacy method uses the SCOOP and SCOOP_GLOBAL environment variables.

### How do I use the Scoop installer in a CI pipeline?

The README gives a GitHub Actions step with shell: pwsh and run: irm get.scoop.sh | iex. If the environment does not set $env:CI, you may need to add `exit $LASTEXITCODE` after the install so the installation result propagates to the pipeline.

### Can I install Scoop as administrator?

Yes, but it is disabled by default for security considerations. Download the installer and run it with the -RunAsAdmin parameter in an elevated console, or use the one-line form `iex "& {$(irm get.scoop.sh)} -RunAsAdmin"`.

## Sources

- [Issues](https://github.com/ScoopInstaller/Install/issues)
- [License: Unlicense](https://github.com/ScoopInstaller/Install/blob/master/LICENSE)
- [Project website](https://get.scoop.sh)
- [README](https://github.com/ScoopInstaller/Install/blob/master/README.md)
- [ScoopInstaller/Install on GitHub](https://github.com/ScoopInstaller/Install)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scoopinstaller-install