Laptop puts the whole macOS workstation setup in a single file named mac

The entire tool is one file named mac

The repository is a script with documentation attached. The top level entries are .github/, .gitignore, CHANGELOG, CODEOWNERS, LICENSE, README.md, SECURITY.md and `mac`, and `mac` is the installer, the package list and the configuration language all at once. Everything thoughtbot puts on a developer Mac, Homebrew plus fzf, Universal Ctags, Git, OpenSSL, RCM, The Silver Searcher, Tmux, Watchman, Zsh, the Heroku CLI with Parity, the GitHub CLI, ImageMagick, asdf-vm, Bundler, Node.js and npm, Ruby, Yarn, Rosetta 2, Postgres and Redis, is expressed as steps in that one file. Contributing means editing `mac`, documenting the change in `README.md` and updating the `CHANGELOG`, so behavior and documentation land in review together. The upside is that you can read the entire install in one sitting before it touches your machine. The downside is that there is no module boundary: a custom change and an upstream change edit the same file, and a fork cannot take upstream improvements without replaying its own edits over the top. The copyright line dates to 2011 thoughtbot, inc., under MIT.

Idempotency is the contract, not a side effect

The script can be run multiple times on the same machine safely: it installs, upgrades, or skips packages based on what is already installed on the machine. That single decision is what makes it usable on a laptop you already own rather than only on a fresh one, and it is why the project says the install should take less than 15 minutes depending on your machine, since a later run only pays for what changed. The same rule extends to your own code, because customizations in `~/.laptop.local` are meant to be written such that they can be run safely more than once. Two helpers from the script, `fancy_echo` and `gem_install_or_update`, can be used in that file, so your additions run inside the same shell session as the install itself. The practical consequence is that review and execution live in different places. A customization can be idempotent in isolation and still fail on every run, because an earlier step in `mac` changed the state it assumed. Test your `~/.laptop.local` against a second run, not only against a first one.

Download, read, then run with the output piped to tee

Installation is manual and ordered by risk. The first step downloads the script:

curl --remote-name https://raw.githubusercontent.com/thoughtbot/laptop/main/mac

The next step is to review it, with the reminder to avoid running scripts you have not read:

less mac

Then you execute it and keep the output:

sh mac 2>&1 | tee ~/laptop.log

That log is also the debugging artifact. The last run is saved to `~/laptop.log`, you are told to read through it, and if you cannot solve the problem yourself, you copy the lines where it failed into a new GitHub issue or attach the whole log file. What is missing matters as much as what is there. There is no documented dry run, no flag that previews a step, and no uninstall or rollback path, so the only pre-flight step offered is reading the script yourself and the only recovery aid is the log. The cost of a surprise therefore lands on the reader: if a step changes something you wanted kept, the log tells you what ran, not how to put it back.

Ventura through Tahoe are supported and everything older is untested

Supported platforms are stated as four macOS releases, and this is one of the clearest commitments in the file. macOS Tahoe (26.x), Sequoia (15.x), Sonoma (14.x) and Ventura (13.x) are each supported on Apple Silicon and Intel. Older versions may work but are not regularly tested, and bug reports for them are welcome rather than fixed on a schedule. The consequence for readers is concrete: on a release outside that list the script is an untested path, so failures belong to you and the maintainers are asking for reports, not promising fixes. The list has a hard edge in the other direction too. The script targets macOS and nothing in it prepares a Linux or Windows machine, so the Homebrew layer and the dotfiles it sets up have no equivalent there. One detail matters for anyone auditing an install: the download URL points at the `main` branch, so it always serves head code that may differ from what you read last week. Pin a tag or a commit if you need the exact script you reviewed.

Rosetta 2 in the tool list means x86 binaries can still run

Among the installed items is Rosetta 2, described as being for running tools that are not supported in Apple silicon processors, while the same script claims support for both Apple Silicon and Intel. The combination tells you something about the tool set: part of what thoughtbot's developers use still has no native arm64 build, so the setup deliberately keeps a translation layer available on machines that do not otherwise need it. Day to day, the effect is that an Intel-only tool runs on your Mac instead of failing to install. If you are taking stock of a machine, it is worth knowing that having native arm64 tooling installed does not mean x86 binaries are absent or unable to execute. The language layers follow the same pattern of handing you the mechanism instead of a choice: asdf-vm manages programming language versions, Bundler manages Ruby libraries, Yarn manages JavaScript packages, and Ruby is installed as the stable release for general purpose code. Picking a version for a new project is your decision after the install, not something the script resolves.

The documented ~/.laptop.local example probes a machine with a quiet grep

`~/.laptop.local` runs at the end of the Laptop script, and the documented example installs a cask bundle, sets up a docker-machine named default, runs `brew cleanup`, and calls `rcup` when `$HOME/.rcrc` is readable. The example carries a detail worth copying deliberately rather than pasting: both guard functions rely on `grep -Fq`, the quiet flag that prints nothing when it matches. `default_docker_machine` runs `docker-machine ls | grep -Fq "default"` and produces no output even when the machine exists, and `default_docker_machine_running` pipes that empty output into its own `grep -Fq "Running"`, so the running check never sees a matching line and the start step fires again. Write your guards so they print something, or test an exit status, or the second half of your idempotent script will keep acting. The same file is where opinion enters the install, since `brew cleanup` and `rcup` in one run means a customization can rewrite your dotfiles after the base setup has finished.

Testing a change means duplicating a macOS virtual machine

The contribution path is edit the `mac` file, document it in `README.md`, update the `CHANGELOG`, and follow shell style guidelines using ShellCheck and ALE, or the deprecated Syntastic. The linter installs with:

brew install shellcheck

Testing is the expensive part. Changes are tested by running the script on a fresh install of macOS, using the free and open source emulator UTM, and the tip is to build one virtual machine with macOS installed and the user created and first launch complete, then duplicate that machine so every run starts from the same clean state. The consequence is that a one line edit to `mac` needs a full macOS installation inside a VM, and the loop depends on a machine you maintain by hand. For readers who are still deciding whether to run the script, that duplicate VM recipe doubles as the cheapest way to watch what it does, since a clean image plus ~/laptop.log tells you what changed and what did not. The repository is not archived and its last push is dated 2026-08-13, with dated releases in 2026, 2024 and 2023.

Editorial conclusion

Laptop suits developers setting up a fresh Mac who want thoughtbot's exact tool set and will read the shell script before running it as their own user. It does not suit a locked or managed machine, a Linux or Windows box, or anyone who needs a dry run or a rollback, since neither is documented. Before you run it, read the `mac` file end to end, read ~/laptop.log afterwards, and keep anything you add to ~/.laptop.local safe to run twice.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thoughtbot/laptop on GitHub