Platzierte AGENTS.md-Dateien koennen Codex und Claude Code kapern

Posted on Oct 27 • Originally published at raxxo.shop

Forever Security reported on October 22 that a planted AGENTS.md file in ~/Downloads can hijack Codex and Claude Code

In Forever's tests, a malicious AGENTS.md got Codex to run the attacker's payload in more than 90% of attempts

A matching CLAUDE.md variant shipped out a live OAuth token in roughly one Claude Code run in five

Forever says there's nothing to patch, an agent following instructions in its own working folder is behaving exactly as designed

On October 22, the security firm Forever Security published research showing that a text file sitting in a Downloads folder, nothing more exotic than that, can talk a coding agent into installing malware. It tested the attack against both OpenAI's Codex and Anthropic's Claude Code, and neither one came out looking great.

The setup is almost insultingly simple. Drop a file named AGENTS.md or CLAUDE.md into ~/Downloads, the kind of instruction file these agents already read automatically when they start a session in a folder, and fill it with instructions written as if they came from the project owner. If a developer later points a coding agent at that same folder, by opening a terminal there to sort through old files, extract an archive, or just poke around, the agent reads the planted file the same way it would read a legitimate one and starts following it.

Forever says it first caught this for real on a customer's machine. Someone's coding agent tried to install a known-malicious npm package, and Forever traced the instruction back to a file sitting in Downloads. Nobody on that team had written it. How it got there in the first place is still unclear, which is itself worth sitting with for a second.

That's the part that should bother anyone running agents daily.

It's worth saying plainly why Downloads specifically is the weak spot. Forever's own numbers describe hundreds of its customers running Claude Code, Codex or Cursor's CLI with a session opened directly inside ~/Downloads, with Claude Code alone logging well over a thousand sessions started there. Nobody picks that folder on purpose as a workspace. It's where a browser dumps a zip file, where an installer lands before you run it, where a PDF somebody emailed you ends up. Opening a terminal there to deal with whatever just arrived is such an ordinary habit that most people wouldn't think twice about pointing an agent at it too.

From there Forever ran controlled tests to see how reliably the trick worked, rather than relying on one incident. They built a planted AGENTS.md that told Codex to make a change to its own machine-wide configuration file, and a matching CLAUDE.md built to push Claude Code toward leaking credentials instead. Both files were written to look like ordinary project setup notes, the exact genre of file these tools are designed to trust without asking twice.

Codex came off worse. Forever reports that its planted AGENTS.md got Codex to add a new entry to ~/.codex/config.toml, a file the agent reads regardless of which project directory a session happens to be running in, in more than 90% of attempts. The entry pointed at a malicious npm package Forever has published as function-color. Because that config file applies globally rather than per-project, the compromise doesn't go away when the developer closes the Downloads folder and opens a real one. It's already sitting in a file Codex reads every single time it starts up anywhere on that machine.

Claude Code's numbers tell a more layered story. According to Forever's write-up, a malicious CLAUDE.md variant got Claude Code to rewrite its own settings file roughly half the time. Getting that far is not the same as a full compromise, though. Forever's figures put the share of runs that went all the way to executing code and shipping a live OAuth token out to a server the researchers controlled at closer to one run in five. Once that token left the machine, Forever says it replayed it successfully against the real API, confirming the credential was genuinely usable rather than just logged somewhere harmless.

That's a lower hit rate than Codex's, but it's not a reason to relax.

A one-in-five success rate against a widely used coding agent, from nothing more than a text file sitting where plenty of people already keep their downloads, is still a real attack surface. Forever's report notes it didn't need to break out of any sandbox to pull this off. The agent did exactly what an untrusted instruction file told it to do, inside the permissions it already had.

Worth separating the two steps Forever measured for Claude Code, because they're not the same risk. Getting the agent to rewrite its own settings file is annoying but survivable if you catch it before anything runs. Getting it all the way to executing code and sending a working credential off the machine is the part that turns an annoyance into an incident, and that's the number sitting closer to one in five than one in two.

Forever's own framing is the detail I keep coming back to: there's no single line of code in Codex or Claude Code that's actually broken here. Both agents are designed to read a setup file in whatever folder they're pointed at and follow it, because that's the entire point of AGENTS.md and CLAUDE.md as formats. The feature and the vulnerability are the same mechanism, viewed from two different angles.

That's an uncomfortable answer if you were hoping for a quick security update to fix this. A patch that made agents stop trusting instruction files in their working directory would also break the thing that makes those files useful in the first place, project-specific setup notes an agent can read once and act on without a human retyping them every session.

What Forever is actually recommending, instead, is a change in habits rather than a change in code. Don't launch a coding agent with ~/Downloads, or any other folder full of files you didn't write yourself and haven't reviewed, as its working directory. That's a smaller ask than it sounds, since most of us only end up in Downloads by accident anyway, usually to grab something right after it finishes downloading.

I've written before about the hooks I run on every file Claude Code touches ( the hooks that audit every file I write ), and this is exactly the class of problem that kind of setup is for: catching an agent about to act on something it shouldn't, before the action actually happens, rather than trusting every instruction file by default.

Treat any AGENTS.md or CLAUDE.md you didn't write, in any folder you didn't set up yourself, as untrusted input, not as project configuration. That includes a zip you just extracted, a cloned repo you haven't opened yet, and yes, anything in Downloads.

I'd go further than Forever's advice and say it's worth actually reading a new project's setup file once before the first session, the same way you'd skim a package.json before running an install script from a repo you don't recognize. It takes thirty seconds and it's the entire difference between an agent following your instructions and an agent following whoever planted the file.

Second, separate where you download things from where you run agents. If Downloads is where files land before you sort them, don't also make it where a coding agent gets pointed when you're in a hurry. Move a file to a real project folder first, then open the agent there.

This isn't a Claude Code or Codex problem specifically either. Forever's own numbers mention Cursor's CLI agent showing up in the same pattern of sessions started from Downloads, so the habit worth breaking is broader than any one vendor's tool. Any agent that reads a setup file automatically on startup is reading the same category of trust signal, and none of them currently ask you to confirm that a freshly discovered AGENTS.md or CLAUDE.md actually came from you.

Third, if you're on Codex specifically, the global config file is the single point worth checking by hand occasionally. A planted entry in ~/.codex/config.toml doesn't announce itself, and it survives across every project you open afterward until someone notices it and removes it. I keep a similar discipline around my own.claude/ folder setup, checking what's actually loaded on startup rather than assuming it matches what I remember writing.

None of this is complicated. It's the same instinct that already stops most people from running a random shell script they found online without reading it first, just applied to a folder instead of a script.

A text file in the wrong folder got Codex to run attacker-controlled code in Forever's tests more than 90% of the time, and got Claude Code to leak a working credential in about one run in five. Neither number is a bug waiting on a patch, because both agents did precisely what an instruction file told them to do, inside permissions they already had.

The fix that actually works is boring: stop pointing coding agents at folders full of files you haven't looked at, and spend the thirty seconds reading a setup file before the first session instead of after something goes wrong. I'll be checking my own Downloads folder habits after writing this, and I'd suggest doing the same before your next session rather than after you read about an incident that happened to someone else.

Forever's research doesn't name a fix date, because there isn't a version number attached to this one. That's the real takeaway buried under the percentages: some security problems in this new wave of agent tooling get closed with a changelog entry, and some just get closed by developers changing where they open a terminal. This is the second kind, and it costs nothing to fix starting today.