curl | bash: convenient, and exactly as trusting as it looks

Piping a remote script straight into a shell is a genuinely common install pattern, and it means trusting three things at once: the script's actual contents (which you almost never read first), the domain serving it (not compromised, not typosquatted), and the integrity of everything in between at the moment you ran it — the same URL can serve different content to a browser preview than to a piped curl request. None of that is unique to this pattern, but the "just run this one command" framing makes it easy to skip the moment of "wait, what does this actually do" that a downloaded, inspected file would prompt.

A GitHub repo's own setup steps run the same way

npm install, pip install -e ., and make aren't sandboxed by the tool running them — they execute whatever the project's install hooks, setup.py, or Makefile say to, the identical mechanism covered in how AI coding agents use your computer, minus the agent. Cloning an unfamiliar repository and following its own README's setup instructions is running code you haven't reviewed, whether or not anything about the workflow involves AI at all.

"Building from source" isn't inherently safer

There's a common instinct that compiling something yourself is more trustworthy than grabbing a prebuilt binary — sometimes true for supply-chain reasons, but it doesn't touch this specific risk at all. A build script can do anything a shell script can, because it typically is one, or invokes one. "I built it myself" tells you something about where the binary came from; it tells you nothing about whether the build process itself did something you wouldn't have wanted.

Dependencies you didn't choose to audit

Even a project whose own code you trust pulls in a dependency tree you almost certainly haven't reviewed — and any one of those transitive packages running its own install hooks is the same risk one level removed. This is the general shape of supply-chain risk, and it applies whether you're installing a tool for yourself or setting an agent loose to do the same thing.

The boundary that actually helps, either way

None of the above gets meaningfully safer by being more careful about which untrusted software you run — the fix is the same one this blog keeps arriving at for AI agents specifically: run it somewhere a bad outcome doesn't reach your actual account, covered in VM vs. container vs. sandbox on macOS. Try the install, the build, the new tool inside a disposable workspace; if it's fine, keep using it from wherever you'd normally install real tools; if it's not, close the workspace and nothing about your actual Mac was ever at risk.

Related reading: how AI coding agents use your computer, for the identical mechanism with an agent involved, VM vs. container vs. sandbox on macOS, and what a disposable development environment actually is. Or download Velo Workspaces and try it yourself.