AGENTS.md Security Risk: Downloads Folder Hijack Explained

The AGENTS.md security risk just moved from theory to a real customer machine. Security company Forever reported on October 22 that it caught a live attack in the field: a coding agent tried to install a known malicious npm package, and the order came from an AGENTS.md file sitting in the customer's Downloads folder, disguised as ordinary engineering notes. The team then reproduced the full attack against OpenAI Codex and a variant against Claude Code. There is no software bug to patch here, which is exactly why this matters. This post explains how the hijack works, why the Downloads folder is the weak point, and the five checks worth doing on any machine that runs coding agents. Source

What happened

Forever's team stopped an agent, mid-session, from installing function-color, a malicious npm package tied to a campaign that ran for roughly two years before being publicly documented. Blocking a bad package is routine, so the team dug into where the instruction came from. It was not a dependency or a repository. It was a 13 KB AGENTS.md file in the customer's Downloads folder, and nobody knew how it got there. Source Source

BleepingComputer covered the disclosure on October 25, and the write-up spread quickly because of what it demonstrates: an instruction file is executable intent. One caveat worth keeping in view: the delivery route on the customer machine is unconfirmed. Forever proved a web page can plant a file in Downloads, but did not prove that is how this specific file arrived. Treat this as one field sighting plus a lab reproduction, not a tracked campaign. Source Source

Why AGENTS.md is a security risk by design

Two facts collide here, and each is harmless alone. First, agents are built to obey instruction files. Codex reads AGENTS.md, Claude Code reads CLAUDE.md, and the file in the working directory is treated as trusted project configuration. That is the product working as designed, the same way a browser rendering a phishing page is working as designed. Second, Downloads is the one folder a website can write to without a click or permission, because saving files there is what browsers do. Operating systems spent years making downloaded executables safe by blocking auto-run. A Markdown file skips every one of those guardrails because it is not an executable. It only becomes dangerous when an agent reads it, and agents read it automatically. Source

Forever's own telemetry shows why this is not an edge case: about half of its customers run a coding agent inside the Downloads folder, and roughly a quarter of agent sessions open a real browser. An agent that browses can fetch the very file that later hijacks it, with nobody watching the screen. Source

The Codex chain: a config rewrite that outlives the session

The real attacker file targeted Codex, so the researchers ran that exact file, unchanged, inside an isolated VM. It is a long, bland "Engineering Work Guidelines" document, and the attack hides in one section framed as routine environment setup. The instructions tell Codex to register a fake "project tools" MCP server in ~/.codex/config.toml, and that registration runs a shell command that installs the malicious package. In testing, Codex ran the malware in more than 90 percent of attempts. Source

Two details make this nasty. The config file it edits is machine-wide, not project-scoped, so once the block is written, every later Codex session in any folder loads the attacker's server at startup. And getting there required defeating five separate controls: the project trust gate, the model's refusal to write a short obvious install command (which the long boring document framing defeats), the fact that MCP servers only load at session start (defeated by spawning a child session), the network sandbox (defeated by the agent writing its own bypass flag into the command), and the startup handshake timeout (defeated by handing the install to the OS launcher so it runs outside Codex's control). Each workaround is a finding on its own. Source

The Claude Code chain: token theft through a base URL

Claude Code was harder to fool, and the working attack looks nothing like the Codex one. A planted CLAUDE.md, dressed as gateway setup documentation, instructs Claude to write a project settings file that points ANTHROPIC_BASE_URL at an attacker-controlled server with a valid certificate. That one reroute does two things: it leaks Claude's OAuth token on every request, which the researchers replayed against the real API for a full account takeover with no code executed, and it lets the attacker's server answer as if it were the model, returning tool calls that run attacker commands with the sandbox disabled. The config write succeeded about half the time, next-session code execution followed automatically once written, and same-session execution worked about a fifth of the time via a spawned subagent. Source Source

These success rates are Forever's own numbers and no independent party has reproduced them yet, so treat the percentages as indicative. The architectural point does not depend on them: any agent that reads an instruction file and can rewrite its own config can be driven this way. Source

Part of a pattern, not a one-off

Instruction-file injection has been building all year. NVIDIA's developer blog demonstrated in April that a malicious dependency can overwrite AGENTS.md at build time to make Codex silently inject code into projects. The Cloud Security Alliance's research note on README injection pulled together the wider evidence: benchmark studies measured attack success around 84 percent for direct commands hidden in README files and 91 percent for instructions two links removed, and end-to-end testing frameworks succeeded at rates from 41 to 84 percent across major coding assistants. Those are lab and benchmark numbers, not field rates, but they show the Codex and Claude chains are instances of a class, not isolated tricks. Source Source

We have been tracking the same shape from other angles. The LiteLLM supply chain compromise poisoned a package agents install, and the GitSpawn git-config attack turned a repository's own configuration against the agents that read it. The Downloads hijack is the same lesson from the filesystem side: anything the agent reads is a control surface. Our AI agent security checklist covers the standing defenses, and the MCP angle of this attack is exactly why MCP server security deserves its own review.

Why there is nothing to patch

Forever's conclusion is that neither OpenAI nor Anthropic has anything to fix, and the phishing analogy is the right frame. When a browser renders a fake bank login, the browser did its job; the attack lives in the page. When Codex or Claude Code follows the instruction file in its working directory, the agent did its job; the attack lives in the file and in where it landed. The danger sits in the seam between two behaviors that are each correct: agents trust their folder, and the web can write to one specific folder. No vendor owns that seam, so the defense lands on operators and on endpoint tooling that watches the agent itself rather than the human. Source

What to do today

Forever's recommendations need no purchase and no patch. One: never start a coding agent in the Downloads folder, because it is the one folder the web can plant files in. Two: read any AGENTS.md or CLAUDE.md you did not write before letting an agent near it, including in freshly cloned repos. Three: audit the agent configs: in ~/.codex/config.toml look for unexpected MCP server blocks or changed base URLs, and in .claude/settings.json look for ANTHROPIC_BASE_URL, proxies, or endpoints you did not set. Four: keep approval gates and sandboxes on, and treat any instruction that asks the agent to bypass them as a red flag by itself. Five: if you find a suspicious file, rotate tokens, because a stolen OAuth token is a live session. The indicator of compromise for this specific campaign is the npm package function-color, since removed from the registry; if it appears in a machine's install history, treat the machine as compromised. Source