How to Review a GitHub Repo Before an AI Agent Executes It

"Find a library that does X and set it up" is one of the most natural things to ask a coding agent — and one of the most dangerous, because the agent may clone a repository, run its setup script, and install its dependencies before you've looked at any of it. With campaigns like the 10,000 fake repositories mapped by the researcher Orchid — clones built specifically to bait automated tools into executing malware — "the agent will figure it out" is no longer a safe default. You need a fast, repeatable way to review a repository before you let an agent execute anything in it.

This is that checklist: the five things to inspect, what a red flag looks like in each, and how to do it in a couple of minutes. The goal isn't a full security audit — it's a triage that catches the obvious traps that automated malware campaigns rely on you (and your agent) skipping.

Why a pre-execution review is now mandatory

The threat has shifted from "malicious package on install" to "malicious repository on open." The Miasma worm that hit Microsoft in June 2026 ran a credential-harvesting payload when a repo was opened in an AI coding tool, using committed config files. The Orchid clones, per Cybernews, were SEO-tuned to outrank the originals in search and updated every few hours to evade detection — built on the theory that AI agents, not humans, would take the bait, because an agent resolving a dependency is more easily fooled than a person eyeing a suspicious ZIP.

So the review below targets exactly the surfaces those campaigns abuse: scripts that auto-run, shell commands, network calls, and the repo's history and reputation signals.

1. Read the package scripts before anything installs

This is where install-time code execution hides. Open the manifest and read every script field — these run automatically on install, build, or test:

• package.json → scripts, especially preinstall, postinstall, prepare. A postinstall that pipes a remote script into a shell is the classic attack.
• setup.py / pyproject.toml → custom build steps and cmdclass overrides that run arbitrary code at install.
• Makefile, *.sh, justfile, Taskfile → anything the README tells you (or the agent) to run.

Red flags: a script that downloads and executes remote code (curl … | bash, wget … | sh, iwr … | iex), base64-encoded blobs passed to eval, calls to node -e/python -c with long inline strings, or obfuscated one-liners. A legitimate postinstall is usually a short, readable build step — not an encoded payload.

# quick triage
cat package.json | grep -A20 '"scripts"'
grep -rn "curl\|wget\|Invoke-WebRequest\|base64\|eval" --include=*.sh --include=*.js .

2. Hunt for shell commands and network calls in the code

Beyond install scripts, scan the source for code that shells out or phones home. Malware needs two things: execution and exfiltration. Look for both.

• Execution: child_process.exec/spawn, os.system, subprocess, eval, Function(), exec().
• Network / exfiltration: fetch/axios/requests/urllib to hardcoded IPs or unfamiliar domains, raw socket connections, DNS-based exfiltration, or POSTs of environment data.

grep -rniE "child_process|subprocess|os\.system|eval\(|exec\(" --include=*.{js,ts,py} .
grep -rnE "https?://[0-9]{1,3}(\.[0-9]{1,3}){3}|\.onion|paste\.|discord\.com/api/webhooks" .

Red flags: a "utility" library that reads process.env and POSTs it somewhere, hardcoded IP addresses, Discord/Telegram webhook URLs (a favorite exfiltration channel), or network calls that have nothing to do with the library's stated purpose. A JSON-parsing helper has no business opening a socket.

3. Check recent commits and the commit pattern

The Orchid campaign's tell was behavioral: fake repos were updated every few hours, with commits deleted and re-added to dodge scanners. Commit history is reputation you can read:

git log --oneline -20
git log --pretty='%an %ae %ad' -20 --date=short

Red flags: a repo created days ago with a sudden burst of activity; near-identical commit messages on a tight cadence; a single brand-new author with a generic name; a README or config file changed in the last hour with no corresponding code reason; or a "popular" project whose history is suspiciously shallow. Compare against what a real, organically maintained project looks like — years of varied commits from multiple contributors.

4. Read the issue tracker and the repo's reputation

A genuinely used project has a social footprint; a freshly minted clone doesn't.

• Issues and PRs: real projects have real bug reports, discussions, and closed issues. A repo with thousands of stars but zero substantive issues is suspicious.
• Stars vs. engagement: stars are cheap to fake; conversations are not. Look for evidence that humans actually use it.
• Is it the original or a clone? Search the project name. If a near-identical repo with more history and engagement exists under a different owner, you may be looking at a poisoned clone that out-ranked the real one — exactly the Orchid pattern.

Red flags: no issues, no external contributors, a description copied verbatim from a more-established project, or a name one character off a popular library (typosquatting).

5. Verify dependencies and lockfiles

Finally, the transitive surface. The repo's own code may be clean while a dependency is not.

• Diff the lockfile against what the manifest declares; watch for packages pinned to a single odd version, a git URL, or a tarball link instead of the registry.
• Check for typosquatted dependency names (reqeusts, lodahs).
• Prefer installing against a registry you control or with --ignore-scripts on the first pass, so install hooks don't run while you're still evaluating.

Do the review in a sandbox, not on your laptop

Even this review should happen with the safety net on. Clone into a container or VM with no host mounts beyond the project and no network, so that if you accidentally trigger something while poking around, it's contained. Our guide on never giving a coding agent your whole machine on the first run covers that setup; treat this checklist as what you do inside that sandbox before granting the agent permission to execute.

FAQ

This sounds like a lot — do I do it for every dependency? No. Do the full pass for unfamiliar repos you're about to let an agent execute, especially ones the agent found via search. Well-known, widely-used libraries from the official registry with long histories need far less scrutiny.

Can't the agent review the repo for itself? It can help — but the agent is the thing being targeted, and prompt injection in a README can steer it. Keep a human in the loop for the go/no-go on execution, and run the agent's review in a sandbox.

What's the single highest-value check? Reading the install/build scripts. That's where code runs automatically without you asking, which is the attacker's favorite foothold.

How do I tell a clone from the original? Compare commit history depth, contributor diversity, and issue activity, and search for an older repo with the same code under a different owner. The original almost always has more organic history than a recent clone.

Bottom line

Letting an agent execute an unreviewed repository is the exact behavior that automated malware campaigns are built to exploit. A two-minute triage — read the package scripts, grep for shell-outs and network calls, check the commit pattern, weigh the issue-tracker reputation, and verify the dependencies — catches the traps that those campaigns depend on you skipping. Do it inside a sandbox, keep a human on the go/no-go, and you turn "the agent ran something it found online" from a routine risk into a deliberate, reviewed decision.

Sources and further reading