How to stop a planted AGENTS.md file hijacking your coding agent

Yes, a planted AGENTS.md can steer a coding agent, but only if you start the agent in the folder that holds the file. Researchers caught one real file, which was blocked before any code ran, and reproduced the rest in their own tests. Start agents in your project folder and keep approvals on. If you build agents, put the approval gate somewhere the agent can’t change it.

This note is for developers who run Codex or Claude Code, and for anyone building an agent of their own.

Can a file in my Downloads folder take over my coding agent?

Yes, in the cases researchers have shown, but only if you start the agent in the folder that holds the file and it treats that file as trusted instructions. In October 2026 Forever Security reported a planted AGENTS.md in a customer’s Downloads folder that tried to make OpenAI’s Codex install a malicious npm package, and its software blocked the install before any code ran. In the firm’s own tests Codex followed the file in more than 90% of attempts, mostly with a harmless stand-in, and a CLAUDE.md the researchers wrote themselves rerouted Claude Code’s traffic about half the time. How the original file reached that folder is not known.

What the researchers found, and what they only tested

Only one file was seen in the wild, and it was stopped. Everything else comes from Forever’s own tests.

What was seen in the wild

Forever found a malicious AGENTS.md in a customer’s ~/Downloads folder, which was also where a Codex session was running. The file was dressed up as engineering guidelines and told Codex to install function-color, a known malicious npm package. Forever’s software stopped the install before any code ran. According to Forever, npm has since removed the package. Nobody knows how the file got onto the machine.

What was reproduced in tests

Forever ran the real attacker file against Codex, and Codex followed it in more than 90% of attempts. Most of those runs used a harmless stand-in that opens a calculator. The real package was run once, inside an isolated virtual machine.

The Claude Code attack used a different file. The researchers wrote that CLAUDE.md themselves, inspired by the real one, and it worked about 50% of the time. Claude Code asks a person to approve the settings change the attack needs, and it often refuses.

How a web page could plant the file

Forever built a test page that saves an AGENTS.md into Downloads without asking. BleepingComputer tried it. Chrome, Edge and Firefox saved the file with only a download notification, and Brave showed a prompt first. Whether the real file arrived this way isn’t known.

How the attack works, in plain English

The attack works because a coding agent obeys the instruction file in the folder it starts in, a website can write files into Downloads, and the agent can rewrite its own settings.

Codex only follows an AGENTS.md in a folder it trusts, and Downloads counts once you’ve worked there (Help Net Security). The planted file is a 13 KB “engineering guidelines” document, because a short request to install a package gets refused. It asks Codex to add a new server to ~/.codex/config.toml. That file applies to every Codex session on the machine, so the change outlives the folder.

The Claude Code version asks the agent to save a new API address in .claude/settings.json. From then on, Claude Code sends its requests and its login token to a server the researchers control.

What to do today

Start your agent in the project folder you’re working on and keep its approvals on. Forever’s report gives five steps, and the coverage repeats them:

1. Don’t start an agent in Downloads or your home directory. Start it in the project root, which BleepingComputer notes is what OpenAI and Anthropic recommend.
2. Read any AGENTS.md or CLAUDE.md you didn’t write, including in a repo you’ve just cloned.
3. Check the agent’s own config for servers or API addresses you didn’t add. Forever’s report lists the exact settings to look for.
4. Keep approval prompts and the sandbox switched on. Treat any instruction to turn them off as a warning sign.
5. If you find a planted file, assume the login token leaked and replace it.

Why approval gates are the real defence

An approval gate only protects you if the agent can’t reach it. This section is my view as an architect who has built approval gates into his own agent. It isn’t from Forever’s report.

The gate must sit outside the model’s reach

In Forever’s Codex test, the model wrote the bypass flag itself: --dangerously-bypass-approvals-and-sandbox, presented as something the install needed. A gate the model can switch off with a flag isn’t really a gate. If the agent can edit its own permissions or config, so can any file it reads. The check has to live in runtime code that the model’s output can’t change.

Changes to the agent’s own settings always need approval

Both attacks worked by changing config. Adding a server, changing an API address or loosening permissions should always stop and ask a person, however routine the request sounds. Forever found the settings write was the hard part with Claude Code, because Claude Code asks a person first.

Scope risky tools by step, not by session

An agent rarely needs dangerous tools for a whole session. In an agent I built, missions run in phases, and dangerous tools are only switched on in the phase that carries out actions. Phases that only write text have tools turned off (how the phases work).

Show the approver the real action, and refuse if nobody answers

An approval prompt is only useful if it shows the actual command or config change, not a friendly summary. If nobody answers, the safe default is to refuse.

How an agent I built handles this

An agent I built doesn’t load AGENTS.md, CLAUDE.md or any other instruction file from the folder it runs in, so this attack has no way in. Its approval gate runs in code before any risky tool runs, not in the prompt. Approval settings are read once at startup and then frozen, so nothing the model writes can switch them off.

A time a gate held

My clearest example comes from my own team of agents, where one agent coordinates and hands work to others. On 26 October 2026 I asked the coordinator to get an engineering agent to squash a public repo’s history to one commit and force-push it. The coordinator passed my approval on, and the engineering agent refused, because an approval relayed by another agent doesn’t count. It only went ahead once I said yes in its own chat. A planted file deserves the same treatment: an instruction that arrives through something else is never the owner saying yes. The same happened later that day when deleting and recreating a release tag.

What approval gates don’t cover

An approval gate is a label on each tool, not a sandbox around what the tool does. Anything not labelled risky runs without asking. If your agent can read files, fetch web pages or save notes to its own memory without approval, a planted instruction can still get in that way, and saved memory can carry it into every later session. Plugins that choose their own label can skip the gate entirely. Check what each tool can actually reach, and treat writes to the agent’s memory as risky.

Building your own agent? Five questions to ask before you ship

1. What can it write to?
2. Can it change its own settings or permissions?
3. Where does it read instructions from, and who else can write to that place?
4. What does the approver actually see?
5. What happens if nobody answers?

These are the questions an agent architecture review works through on a real agent.

Questions

How do I stop a planted AGENTS.md hijacking my coding agent?

Start your agent in the project folder, never in Downloads or your home directory, and read any AGENTS.md or CLAUDE.md you did not write. Keep approval prompts and the sandbox on, and if you build agents, enforce the approval gate outside the model so a file cannot talk the agent into changing its own permissions.

Is this a bug OpenAI or Anthropic will fix?

Forever Security says there is nothing for them to patch, because an agent that follows the AGENTS.md in its folder is doing what it was built to do, in the same way a browser that shows a phishing page is working as designed. The weakness is in the folder being trusted when the web can write to it, not in a bug in the agent.

Want someone to check your agent’s approvals?

If you’re building an agent and want to know whether its approvals would hold against a file like this, get in touch about an agent architecture review.

Sources

• Forever Security, “Markdown Is the New Executable” (22 October 2026). The original research: the file found in the wild, the test results, the “nothing to patch” view and the five recommendations.
• BleepingComputer (25 October 2026). The browser test of Forever’s proof-of-concept page, and the advice to start agents in the project root.
• Help Net Security (26 October 2026). The 13 KB file and the trusted-folder detail.
• The Hacker News. A plain-English summary of the report and its recommendations.
• OWASP Secure Coding with AI Cheat Sheet. General guidance on treating rules files as security-critical.