If you use OpenAI Codex or Anthropic Claude Code, a plain text file in your Downloads folder can be enough to compromise your machine. No executable, no exploit, no phishing link required.
Security firm Forever Security discovered a malicious AGENTS.md file on a customer’s computer that instructed Codex to install a malicious npm package called function-color. The installation was blocked before the malware ran. The firm then demonstrated the same class of attack against both Codex and Claude Code in a controlled research setting.
How the attack works
Both Codex and Claude Code support project-specific instruction files: AGENTS.md for Codex, CLAUDE.md for Claude Code. When an agent operates in a directory containing one of these Markdown files, it reads and follows the instructions inside. The files contain no executable code. The agent does all the work.
An attacker plants a malicious instruction file in a directory the agent will process. A malicious website can trigger the download without a separate approval prompt, according to Forever Security. The firm could not determine how the original file reached the customer’s machine.

What the tests showed
Against Codex, the researchers demonstrated that the malicious file could modify the agent’s machine-wide MCP server configuration and launch a new session with approval and sandbox restrictions bypassed. Codex followed the malicious instructions in more than 90% of tests. Because the rogue server was registered in the machine-wide config, it persisted into subsequent sessions even after the developer moved to a different directory.
Against Claude Code, a malicious CLAUDE.md file redirected the agent’s API traffic to a researcher-controlled server, exposing authentication tokens and allowing the server to feed commands back for execution. That manipulation succeeded in approximately half of tests. The researchers also successfully replayed a captured OAuth token against the legitimate API.
The architectural problem
Akshat Tyagi, associate practice leader at HFS Research, identified the root issue plainly:
“The deeper issue is that these tools treat following an instruction and granting a privilege as the same act.”
Instructions in project files should not be able to authorize changes to an agent’s security settings without independent human approval. That separation does not currently exist by default.
What to do now
Several analysts and practitioners offered concrete steps:
- Disable flags like
--dangerously-bypass-approvals-and-sandboxto restrict the agent’s authorization to run high-risk actions, per Jonathan Ong, senior analyst at Omdia. - Treat
AGENTS.mdandCLAUDE.mdlike source code: assign owners and require reviews before changes land, per Amit Kumar Jena, development manager for AI at Kanerika. - Keep sandboxes enabled, restrict network access, and route software installs through internal package registries or scanning proxies.
- Use isolated development environments and enterprise-controlled gateways with shorter-lived auth tokens if production credentials live on developer machines.
An Omdia Cybersecurity Decision-Maker survey found that 40% of respondents were only somewhat confident or not confident in their organizations’ ability to secure AI agents. The Downloads folder attack is one concrete reason why that number is where it is.
Sakshi Grover, senior research manager at IDC, noted the reported success rates had not been independently validated but called the research a credible early warning rather than evidence of widespread exploitation. The broader risk, she said, is not the Downloads folder specifically but the pattern of agents ingesting untrusted content while holding live credentials.

