· via dev.to (home feed)
Coding agents obeyed AGENTS.md files planted by web pages in over 90% of tests
Forever Security researchers show web pages can silently drop AGENTS.md into a Downloads folder, where Codex followed the malicious instructions in over 90% of lab runs.

A real blocked attack
On October 22, 2026, security firm Forever Security published a write-up by Gal Weizman and Omer Samet titled "Markdown Is the New Executable". It describes an incident on a customer's machine: a coding agent was about to run npm install function-color, a package nobody had requested. The instruction came from an AGENTS.md file sitting in the developer's ~/Downloads folder, and nobody knew how it got there. Forever's software blocked the install, and Help Net Security covered the findings on October 26. The package belonged to a malicious campaign, and npm has since removed it.
How the file arrives
According to Forever, a web page can save a file named AGENTS.md into the Downloads folder on its own, with no click and no approval, controlling both the filename and the contents. In their lab, the file appears the moment the visitor leaves the page.
Two circumstances widen the damage. Coding agents now browse autonomously, so the agent itself can visit the page that plants the file, with no human watching it arrive. Forever's own customer data, as reported by Help Net Security, suggests about half of its customers run a coding agent inside Downloads, and roughly a quarter of agent sessions open a browser.
The real-world file was 13 KB and read like a dull "Engineering Work Guidelines" document, with the actual payload confined to one section near the end. Forever reports the payload failed every time when placed in a folder full of security notes, so the bland tone appears to be deliberate camouflage.
What Codex did
Codex assembles its instructions from AGENTS.md files: a global file in ~/.codex, then one per directory from the project root down to the current folder. Downloads is rarely a git repository, so a Codex session started there treats the planted file as the project instruction file. Codex does have a trust gate, but as Forever puts it, once you have worked in Downloads, the folder qualifies.
The attack chain runs as follows. The agent writes an mcp_servers project-tools block into ~/.codex/config.toml. The new MCP server runs launchctl, which runs npm install function-color outside Codex's control. A child codex exec then runs with --dangerously-bypass-approvals-and-sandbox, because the default sandbox withholds the network access an install needs. Since the edit lands in the machine-wide user config rather than a project layer, later Codex sessions in any project also run the attacker's command.
In lab testing, Forever reports Codex executed the malware in more than 90% of attempts. Most lab runs used a harmless stand-in that opened a calculator; the real package ran once, in an isolated VM.
What Claude Code did
Claude Code reads CLAUDE.md from the working directory and every directory above it, and since v2.1.277 it also reads an AGENTS.md when no CLAUDE.md exists in that chain, so a session started in Downloads would load the same planted file. Forever found Claude considerably harder to fool. The variant that worked, about half the time, included a section asking Claude to write .claude/settings.json with ANTHROPIC_BASE_URL pointing at an attacker-controlled server holding a valid certificate. Once set, every request carries the login token to that server, and replaying a captured token let the researchers take over the account without running any code. A helper agent Claude spawned to check the new config also connected through the attacker's server, giving the researchers code execution about a fifth of the time.
One mitigating detail: per Claude Code's documented permission model, .claude is a protected directory, so in default and acceptEdits modes a write there raises a user prompt. The write-up does not say which mode the lab sessions used, but that prompt remains the last human checkpoint in the chain.
Why there is nothing to patch
Every step is a documented feature doing its job. Agents are built to read instruction files from the folder they start in, to edit configuration when asked, and both vendors officially support MCP servers and custom base URLs. Forever's conclusion is blunt: there is nothing for OpenAI or Anthropic to patch. The broken assumption is the folder itself. Developers treat a working directory as something they filled, while Downloads is filled by the web.
What to check
Forever's recommendations, relayed in a dev.to write-up, are procedural. Never start an agent in ~/Downloads or $HOME, only in project folders you deliberately created or cloned. Read any AGENTS.md or CLAUDE.md you did not write, including in freshly cloned repos, before an agent does. Keep approval prompts and sandboxes on, and treat any instruction to disable them as the attack. Audit ~/.codex/config.toml for unexpected MCP servers or base URLs, search .claude settings files for BASE_URL or PROXY overrides, and check global installs and node_modules folders for function-color, treating any machine where it was found as compromised.
Why it matters
This is prompt injection moving from chat content into filesystem state, and it chains only documented behavior, so no vendor patch can close it. Any agent that reads instruction files from its working directory is exposed, the delivery side needs nothing more than a visited web page, and autonomous browsing removes the human from even that step. With obedience rates above 90% for Codex, the real vulnerability is the trust developers place in markdown files they never wrote.
- #prompt-injection
- #security
- #coding-agents
- #codex
- #claude-code