What should a CLI install script do? A safety checklist

A safe install script does nothing until the whole script has downloaded, installs into a user-owned directory, verifies the binary against a published checksum before moving it into place, and tells the user what it changed. Those four habits cover most of what goes wrong.

Why the script itself matters

Many developer tools are installed by fetching a script and piping it to a shell. Whether that is acceptable for your users is a separate question, and we cover it in is curl pipe to shell safe to run. If you ship such a script, you can at least make it behave well.

The checklist

1. Wrap everything in a function and call it on the last line. A shell reads and runs a script as it arrives. If the connection drops halfway, a half-written command can run. When all the work sits in one function that is invoked at the end, a truncated download defines nothing and runs nothing.
2. Fail fast. Use the shell options that stop on the first error and on unset variables, so one failed step does not lead to a wrong later step.
3. Do not ask for root. Install to a directory under the user's home, such as a local bin folder. If a system install is needed, say so and let the user run it deliberately.
4. Download to a temporary directory, verify, then move. Fetch the binary and its checksum from your release page, compare, and only then place the file. If the check fails, delete and exit with a clear message.
5. Use HTTPS and refuse redirects to plain HTTP. Pass the flags your download tool provides for failing on errors and for limiting protocols.
6. Detect platform and architecture explicitly. Print what was detected. If it is unsupported, stop rather than guess.
7. Never edit shell profiles silently. Print the line the user should add to their PATH, or ask first.
8. Print what you did. A final summary of the files created and the version installed gives a reviewer something to check.
9. Keep the script small and readable. People will read it before running it, and a short script can be reviewed.
10. Version the script URL. Offer a pinned version of the installer so it cannot change between review and use.

Checksum versus signature

A checksum on the same server as the binary proves the download was not corrupted. It does not prove who made it, because an attacker who can change the binary can change the checksum. A signature verified against a key the user already has does more. See checksum or signature, which to trust for the difference. If you can only offer a checksum, publish it somewhere separate, such as in the release notes or another host.

Test it like an attacker would

Run the script with the network cut mid-download, with a wrong checksum, on an unsupported architecture, and as a non-root user. Each should fail safely with a readable message.

Quick check

Safeguard publishes CLI installers (curl and PowerShell) on its download page, and a free scan is available at gold.safeguard.sh/scan.

Last reviewed: 19 October 2026.