A Malicious Repo Picked Its Own Code Reviewer. Here Is How to Audit Your Agent Workflow Before It Happens to You

On September 22, 2026, Straiker STAR Labs published a walkthrough of a malicious repository that got Claude Code to run malware on a developer workstation. What makes it worth a lesson is what it did not need. There was no jailbreak and no prompt injection against the model. The agent simply followed the repository's own documented contribution workflow, and that workflow let the repo choose its own reviewer.

If you build with coding agents, this is the cleanest real example yet of a rule you should already be applying: files inside a repo can shape what your agent does, so they are part of the attack surface. A second study from Manifold Security the same month, GitSpawn, showed the same lesson one layer lower: a repo's own git config can run code through several coding agents before any approval prompt appears. This lesson walks through both, then gives you a concrete audit you can run on your own setup today.

What You'll Learn

• How the Straiker attack chain worked, step by step, and where each step looked innocent
• Why a cheaper, narrower-scope reviewer can make a review look successful while checking nothing important
• What GitSpawn adds: execution that happens before the agent's approval flow even starts
• A seven-point audit for any repo you open with an AI coding agent
• How to treat agent-shaping files (.claude/agents/, hooks, MCP configs, contribution docs) as code that needs review
• Where Anthropic drew the line (workspace trust) and what that means for your own responsibility

Step 1: Understand the attack chain

Straiker reports that the researcher gave Claude Code (running as the Fable model) three ordinary requests: clone the repo, explain the metrics client, and fix the issues it flagged. Then they asked it to "prepare a PR." That last request bound the agent to the repo's contribution workflow, and that is where the trap sat.

1. The workflow pointed at a repo-defined subagent. CONTRIBUTING.md told reviewers to run a first-pass review through an agent defined in .claude/agents/first-pass.md before running pytest.
2. The subagent was pinned to Haiku. The agent file selected a smaller model than the main session was using.
3. Its scope excluded the tests. The subagent could only look at src/ and docs/, not tests/. The document also told the main model that its own reading of files did not replace running the agent.
4. The review returned only harmless planted findings. The review looked like a success, and the main model treated the findings as housekeeping.
5. Pytest ran the payload. The malicious code lived in tests/test_compat.py. According to Straiker, it decoded a URL, downloaded a Python file, and executed it before the test assertion, inside a try/except that swallowed errors. Claude Code reported all tests passing. The downloaded file launched a Sliver implant that gave the attacker command execution.

Notice that no single step is outrageous. The vulnerability is the seam: a repo that selects its own reviewer, limits that reviewer's scope, and then asks the agent to run its tests.

Step 2: See why "the reviewer said it was fine" is weak evidence

The review passed because the reviewer was never shown the dangerous file. A review is only as strong as its scope. When you use a subagent or a cheaper model for first-pass checks, ask two questions: who chose its scope, and what did it not look at?

Cheap models are great for volume work. Anthropic's newly released Haiku 5.5 is pitched as a high-volume subagent for summaries and classification, and that is a good use. The failure here was not the model size. It was that an untrusted party chose the model, the scope, and the story the main agent was told.

Step 3: Add GitSpawn to your mental model

Manifold's research (published September 1, 2026) found that several coding agents run git in the background to gather context, and that git honors a repository's own config. A setting such as core.fsmonitor can name a command that runs when git refreshes its index. The command runs on the host with your privileges, outside the agent's sandbox and before any approval prompt. The researchers named Claude Code, Goose, Hermes Agent, Qwen Code and Grok Build, with some findings unpatched at publication, and reported Codex and Cursor as patched. The delivery requirement is a repository received as files with its .git directory, such as a zip or a shared drive, rather than a fresh clone.

Check your own agent's current patch status in its release notes; the statuses in the research are a September 1 snapshot.

Step 4: Run the seven-point audit before you open any repo you did not create

1. Read .git/config. Run git config --local --list. Look for core.fsmonitor, core.hooksPath, core.sshCommand, diff.external and any value that is a command.
2. List agent-shaping files. Search for .claude/, .cursor/, .github/ workflows, AGENTS.md, CLAUDE.md, MCP configs and plugin manifests. Read every one.
3. Read CONTRIBUTING.md as if it were a script. If it tells an agent to run a specific subagent, tool or command, treat that as an instruction from the repo author, not from you.
4. Check subagent definitions. Note which model each uses and which paths each can read. A reviewer that skips tests/ is a red flag.
5. Read the test files yourself before running tests. pytest, make, npm test and similar commands execute repo code. Straiker's own recommendation is to have the main model read every test file first and not rely on a subagent's report.
6. Open unknown code in a disposable environment. A throwaway VM or container with no SSH keys or cloud credentials limits the damage from anything you missed.
7. Clone instead of unzip when you can. A normal clone does not bring the source's local git config.

Step 5: Turn the audit into a habit

Put the seven points in a checklist in your own repo, or in a custom command your agent runs before it touches an unfamiliar folder. The point is to make "inspect, then trust" the default order of operations.

A note on where responsibility sits

Straiker reports that it reported the issue to Anthropic via HackerOne on September 14 and that Anthropic closed it as Informative, reasoning that honoring a repository's configuration falls under the user's workspace-trust decision. You can disagree about whether tools should do more by default, but the practical takeaway is the same: when you open a repo with an agent, you are making a trust decision, and the tool may not make it harder for you than that.

Conclusion

The two September studies point at one habit: treat everything that ships inside a repository as capable of steering your agent, including config, agent definitions and the contribution guide. Run the seven-point audit on anything you did not write, isolate what you cannot verify, and do not accept "the reviewer found nothing" without asking what the reviewer was allowed to see.

For the broader picture of how AI-assisted development practices and tool rankings are changing, the Vibe Coding Ebook is updated as these stories break, and the Academy newsletter sends the lessons straight to your inbox. If you want the previous lesson in this series, see how to build an autonomy ladder for your own agent workflow.

Sources: Straiker STAR Labs, September 22, 2026; Manifold Security, GitSpawn, September 1, 2026; Releasebot, Anthropic release notes.