AGENTS.md in Downloads can hijack Codex and Claude Code

If anyone on your team uses Codex or Claude Code, there is one habit to stop today: opening the agent inside the Downloads folder. A security firm found a planted instructions file there on a real customer's computer, and the file told the coding agent to install malware.

This post explains what happened, what to check on each machine, and the simple team rules we would put in place. Everything about the attack comes from Forever Security's write-up, Markdown Is the New Executable, published October 22, 2026, which we read on October 27, 2026. The Hacker News and Help Net Security covered it too.

Coding agents read a plain text file in the folder they start in and treat it as standing instructions. Codex reads `AGENTS.md`. Claude Code reads `CLAUDE.md`. Teams use these files for normal things, like "run the tests before you commit" or "use this folder for new components."

That is useful in a project folder you control. The problem is a folder you do not control.

Forever says its product stopped a coding agent, mid-session, from installing `function-color`, a known malicious npm package. They traced the order back to an `AGENTS.md` file sitting in the customer's `~/Downloads` folder. Nobody knew how it got there.

Their point is simple. Downloads is the one folder a website can write to on its own. A web page can save a file there with no click, and it picks the name and the contents. An `AGENTS.md` is plain text, so none of the protections built for downloaded programs apply to it. It just sits there until an agent opens that folder and reads it.

The planted file was a long, boring "Engineering Work Guidelines" document. Near the end, one section told Codex to do some "setup" before starting the user's task:

1. 1Add a new tools server called `project-tools` to `~/.codex/config.toml`, which is Codex's settings file for the whole computer.
2. 2That server entry ran a command that installed `function-color` from npm.
3. 3Then run a second Codex session with the flag that turns off approvals and the sandbox, framed as a needed check.

Forever ran the real attacker file in an isolated virtual machine. They report that Codex ran the malware in more than 90% of attempts. Because the change lands in the machine-wide settings file, every later Codex session on that computer loads the attacker's server, in any project.

Forever also notes Codex only follows an `AGENTS.md` in a folder it trusts, and Downloads qualifies once you have worked there before.

The real file targeted Codex. Forever then wrote their own `CLAUDE.md` to test Claude Code. It told Claude to save a project setting that sent its API traffic to a server Forever controlled, dressed up as a company "gateway." Claude needs a person to approve that kind of file write, and it often refuses ones that look wrong.

Even so, Forever says Claude followed through about half the time. Once that setting is in place, Claude sends its login token to the fake gateway, which is enough to take over the account. On the next launch in that folder, the fake gateway could answer as the model and tell Claude to run commands.

Forever argues there is nothing for OpenAI or Anthropic to fix, because both agents are doing what they were built to do: follow the instructions file in the folder they start in. The risk comes from starting an agent in a folder the web can write to. That means the fix is in how your team works.

Forever's checklist needs no new software. In plain terms:

1. 1Never start a coding agent in Downloads. Not Codex, not Claude Code, not anything else. Move a file into a real project folder first if the agent needs it.
2. 2Look for instruction files nobody wrote. A stray `AGENTS.md` or `CLAUDE.md` in Downloads, or in a repository someone just cloned, should be read by a person before any agent opens that folder.
3. 3Open the agent's own settings. In `~/.codex/config.toml`, look for an `[mcp_servers]` entry you did not add or a changed base address. In a project's `.claude/settings.json`, look for `ANTHROPIC_BASE_URL`, a proxy, or any address you did not set.
4. 4Leave approvals and the sandbox on. Be very suspicious of any instruction, in a file or a chat, that tells the agent to turn them off.
5. 5If you find one, rotate. Assume the login token leaked and replace it from a different device. Forever lists `function-color` as the warning sign, so a machine where it was installed should be treated as compromised.

Picture a small business where a few people use coding agents for scripts, reports or website changes, and nobody owns security full time. For a team like that, here is what we would put in place.

• One working folder rule. Agents run only inside a named projects folder. Downloads, Desktop and the home folder are off limits. Write it down where people will see it.
• A short weekly config check. A small script that lists the tools servers in each agent's settings file and flags anything new. If the list changed and nobody changed it, someone looks the same day. This is the same idea as the approval rules in our post on AI agent permissions and human approval.
• Approvals stay on for anything that installs or rewrites settings. The attack worked by getting the agent to change its own configuration. A person should approve any write to those files.
• Separate accounts for agents that browse. Forever notes that agents now browse on their own. An agent that visits websites should not be the same one, on the same login, that can change your code or settings. Our guide to trust boundaries for self-hosted AI agents covers how we split those jobs.
• Only approved tools servers. If your team uses MCP servers, the tools that connect agents to your apps, keep a short list of approved ones. Our post on securing a production MCP server covers what we check before one goes live.

Forever's broader point is that many security habits assumed a person was doing the clicking and approving. When an agent takes that seat, those habits stop protecting you. We expect more attacks that plant text where an agent will read it: cloned repositories, shared drives, support tickets and web pages.

So the question for any agent you run is the same: what can it read, what can it change, and who checks before it changes something that matters? Our post on retries and approval controls for MCP tools goes deeper on that last part.

If nobody on your team uses a coding agent on their own computer, this specific attack does not reach you. If you use a hosted chat assistant that cannot run commands or change files, it does not apply either. Spend the time where agents can actually run code or change settings.

Ask everyone who uses Codex, Claude Code or a similar tool two questions: where do you usually start it, and have you ever opened it in Downloads? Then check the settings files on any machine where the answer was yes.

If you want help setting up safe defaults for the agents your team already uses, our free automation audit reviews your current tools and tells you what we would lock down first. You can also see what our AI agents and MCP development work includes.