AI in PracticeOctober 27, 2026·7 min read

How to Tell If a GitHub Repo Is Safe to Run

Running a repo executes someone else's code with your credentials. Five checks before you install, what AI review misses, and how to shrink the blast radius.

Running a repo executes someone else's code on your machine, with your credentials. AI agents increasingly make that decision for you: asked for the best repos for a tool, one can clone, install, and run before a human reads a line. Under a video about exactly that, a top comment asks the question the workflow rests on: how do you make sure the repositories you download are safe, and should an AI analyze the code before you install anything? The answers are a five-check routine before anything runs, and a clear look at what those checks catch and what gets through.

What you're deciding when you run someone else's code

A GitHub repo is hosted, not vetted. Anyone can publish, and the platform's job is hosting, not endorsement. Running the code executes it with your user's permissions, your network, and whatever credentials it can find on disk: .env files, API keys, browser sessions, the tokens AI coding assistants hold for their own use.

Install time is where much of the risk enters. Package managers run scripts the package declares: npm executes a package's preinstall and postinstall hooks during npm install, before you've had a chance to read anything. The Shai-Hulud worm that hit the npm registry in September 2025 delivered its payload through install hooks in hundreds of packages, with incident tracking putting the count past 500 within days (Wiz's write-up documents the mechanics). The payload used TruffleHog, a legitimate security scanner, to sweep the machine for tokens, API keys, and cloud credentials, and it used stolen npm tokens to publish infected versions of other packages the same maintainers owned, which is how one install could spread to more.

The agent in the loop adds its own exposure. A coding agent holds tokens for the model, sometimes for GitHub, sometimes for connected tools, and it runs commands nobody typed one at a time. In August 2025, attackers published malicious versions of the nx package, a build system used across JavaScript projects. The payload scanned machines for sensitive data and uploaded what it found to public GitHub repositories, and it leaned on the victims' own AI command-line tools, Claude's and Gemini's, to hunt through files for credentials, per Nx's postmortem. The malware used the assistant's access to do its searching.

The five checks before you run anything

  1. Who's behind it, and since when. Read the maintainer before the code: account age, other projects, whether the commit and issue history shows steady activity. Stars are a floor, not a proof. Shai-Hulud spread through established packages with trusted maintainers, because what got stolen was their tokens. What changes the decision: an account with no history, a project that just changed hands, or activity that stopped months ago sends you back to search for a maintained alternative.

  2. What runs at install. Install scripts execute before you read. Open package.json (or setup.py, or the Makefile) and look at the lifecycle scripts. A script that pipes a remote download into a shell, or phones home during install, deserves a closer look before the install proceeds. npm installs with --ignore-scripts skip them, at the cost of breaking packages that legitimately build themselves at install.

  3. Have the agent read the code first. The commenter's instinct is the right first layer: ask the AI what the code does before anything runs. The useful pass is specific. Which network endpoints does it call? Which files does it read? What does it do with credentials, and what permissions does it ask for? That catches the crude stuff: hardcoded webhook URLs, obfuscated blobs, code that opens .env files. It's one layer, not the decision.

  4. What it drags in. The folder you cloned can be clean while the dependency tree does the stealing. Check how many dependencies the project carries, and whether the names your agent suggests resolve on the official registry. The 2025 study behind the term slopsquatting ("We Have a Package for You!") found that 19.7% of AI-recommended packages didn't exist (21.7% for open models, 5.2% for commercial ones), and attackers register the missing names and wait for the install to come to them.

  5. Shrink the blast radius. Assume one of the above misses, and decide the damage in advance. Run unfamiliar code in a container, a virtual machine, or a devcontainer you can throw away, with no mounts into your home directory and no credentials forwarded in. Keep working secrets out of reach: a fresh API key with a spend cap rather than your main account token. The blast-radius check catches what the others let through, because it doesn't depend on spotting the attack, only on limiting what a successful one can reach.

What AI review can't catch

AI review can be steered by the thing it reviews. Assistants parse everything in a repo, and some of what they parse is instructions: a README, a config file, a comment. Pillar Security demonstrated the rules-file backdoor in March 2025: instructions hidden in Unicode characters that don't render on screen sat in a Cursor rules file and steered the agent's later sessions. HiddenLayer showed a prompt injection planted in a GitHub README that could make an assistant read and upload SSH keys. When the thing being analyzed can also do the persuading, a clean report carries less weight. Keep the review, and keep it as one layer among five.

A review is also a snapshot. The packages Shai-Hulud rode were fine the week before; what changed was a maintainer's stolen token and a new version on the registry. A clean check at install doesn't cover the update three months later.

The update question

Pin versions for anything you run but don't read, and update on a schedule you control rather than the maintainer's: inspect the changelog or the diff before you pull, and let a lockfile record exactly what you're on. An update is code from whoever pushed it, and it gets the five checks in abbreviated form: what changed, who changed it, and what the change touches. Packages need security patches, so the goal isn't to stop updating; it's to make each update a decision someone made on purpose.

The commenter asked whether to disable automatic updates for anything that doesn't come from a trusted source, and the case that argues for this setup is event-stream. It was a JavaScript package with more than a million weekly downloads. In 2018, its original maintainer, too busy to keep going, handed the project to a new contributor, and that maintainer added a dependency called flatmap-stream in a September release. It carried an encrypted payload targeting the Copay bitcoin wallet, and building with the compromised version is how the payload reached wallets. Automatic updates could have delivered the same code to machines that pulled the affected release. The attack rode years of accumulated trust.

FAQ

Is it safe to download code from GitHub?

Downloading and running are different events. A download doesn't execute code by itself; the risk arrives when install scripts and setup commands run. Treat downloading as browsing and the first npm install as the decision the five checks are for.

What is a supply chain attack in software?

An attack that enters through a dependency or an update instead of through the target's own code. You install package A and the compromise arrives inside package B that A pulls in, or in a later update to A. Shai-Hulud and event-stream are the standard examples: trusted packages became the delivery mechanism.

What is slopsquatting?

Registering a package name an AI model is likely to invent. Models recommend packages that don't exist (19.7% of the time in the 2025 study), and an attacker registers those names with malicious code so the install succeeds against the attacker's version. The defense is unglamorous: confirm the name resolves on the official registry before installing.

Can an AI code review catch malware?

Partly. A focused review catches the crude stuff: hardcoded webhooks, obfuscated payloads, credential-harvesting patterns. It misses what's engineered against it: instructions hidden in ordinary-looking files that steer the reviewer, and compromises that arrive later through an update. Pair it with sandboxing and scoped credentials.

Should AI coding agents run with full permissions?

No. Many agent tools offer approval modes that ask before running commands, and the narrow setting is the safer default: approve commands individually in unfamiliar code, keep agents out of directories holding credentials, and prefer a sandbox where the tool supports one. The August 2025 nx malware specifically hunted for AI CLI credentials, which tells you where the valuable keys sit now.

Want to go further?

Want to keep going?

Get the next one delivered.

If you liked this, the next one is worth an inbox slot.