An 'Instruction File' Dropped in Your Downloads Folder Can Drive the Agent — Codex Obeyed a Web-Planted AGENTS.md Over 90% of the Time
When a web page silently dropped an AGENTS.md into the Downloads folder, Codex acted on it more than 90% of the time and Claude Code about 50%. A look at the "unpatchable" hijack Forever Security uncovered—and how to defend against it.
It Started From a Place You "Just Opened"
While investigating a customer environment, the security firm Forever Security found a single AGENTS.md sitting in ~/Downloads (the Downloads folder). An AGENTS.md is a plain-text instruction file that tells a coding agent, "behave this way in this project." But this one file was trying to make the agent install the malicious npm package function-color (a known rogue package said to have circulated unnoticed for about two years). The user had no memory of visiting a malicious site or typing any suspicious command. According to reports, the attack was confirmed to reproduce on OpenAI's Codex, Anthropic's Claude Code, and Cursor CLI.
Why the Downloads Folder Becomes the Weak Spot
The attack succeeds where two individually harmless "givens" overlap.
- A web page can silently write files into the Downloads folder. By default, Chrome, Edge, and Firefox don't ask where to save each time—they drop files into
~/Downloads. In other words, merely opening a page can leave anAGENTS.mdthere without you noticing. - An agent automatically reads the instruction file in its working directory. If you launch an agent where an
AGENTS.mdorCLAUDE.mdsits, it reads and follows those instructions as a legitimate project document before taking on the actual request.
These two cross paths the moment you launch an agent with the Downloads folder itself as the working directory. This place, where files tend to get tossed in haphazardly, is—put another way—"the only folder the web can write to without your consent." In Forever Security's investigation, Claude Code alone reportedly had over 1,300 sessions launched from the Downloads folder, suggesting the risk is more familiar than you might expect.
Codex and Claude Code Were Hit in Different Ways
Even with the same core idea, "what gets rewritten" differed by tool, and so did the success rate. The experiments also used a harmless proof-of-concept payload (which launches a calculator on success).
| Item | OpenAI Codex | Claude Code |
|---|---|---|
| Reported success rate | Over 90% (lab environment) | About 50% |
| Target of the rewrite | ~/.codex/config.toml (machine-wide settings) | .claude/settings.json |
| What it makes the agent do | Registers a malicious MCP server under the guise of "setting up the local development environment" and installs function-color | Points ANTHROPIC_BASE_URL at the attacker's gateway, rerouting all API traffic |
| What happens | Gets the agent itself to write settings that disable approvals and the sandbox, leading to arbitrary code execution | OAuth tokens leak, and code execution is reached through malicious tool responses |
On the Codex side, what stands out is how it slipped in under a pretext like "if there is no server named project-tools, append it" to the config file, and even had the agent write flags to bypass approvals and the sandbox. The Claude Code side was designed to steal credentials and hijack traffic at the same time by re-pointing the API's connection target to the attacker's server.
The Trouble of "There's No Patch to Apply"
What makes this problem hard is that there's no vulnerability to speak of. As the researcher put it, "There's nothing for OpenAI or Anthropic to fix. An agent that follows an AGENTS.md in your own folder is just behaving exactly as it was built to." In other words, this isn't a bug but a design-level premise of trust—"the folder I work in can be trusted"—being quietly undermined by the web. Both companies are said to recommend running agents in a project-dedicated directory rather than a broad location like the Downloads folder.
Steps You Can Take on the Ground Right Now
Since this isn't the kind of issue where you wait for a product-side fix, you have to protect yourself through operational habits. Reduced to verifiable actions, they look like this.
- Don't launch agents in the Downloads folder. Limit work to the project root and treat Downloads as an "untrusted location."
- Visually inspect the instruction file before launching. Check whether an unfamiliar
AGENTS.mdorCLAUDE.mdhas slipped in. - Audit your config files. Look for an MCP server you don't recognize in
~/.codex/config.toml, and a suspicious connection target in.claude/settings.json. - Keep approval gates and the sandbox enabled. Be suspicious of any instruction that tries to get you to turn them off.
- If you suspect a compromise, revoke and reissue your authentication tokens immediately.
What's Really at Stake Behind the Convenience
Agents are useful precisely because they run without a human in the loop, but that very "no human present" premise erases the last line of review that traditional security has relied on. As the researcher notes, "Defenses built around a human break the moment an agent takes the human's seat," and such concerns are expected to spread to entry points beyond the Downloads folder over time. There's no need to assume attacks will suddenly proliferate, but the more unattended operation expands, the more it seems worth closing—one by one—the paths that let an agent act merely by "reading."
References: Forever Security — Markdown Is the New Executable / BleepingComputer / DEV Community explainer / RuntimeWire
