How a Downloads Folder File Can Hijack Your AI Coding Agent

A security firm called Forever Security caught a coding agent on a real customer's machine in the middle of installing a known-malicious npm package. Nobody had typed that command. The instruction came from a plain text file sitting in the customer's ~/Downloads folder, and nobody remembered putting it there.

No exploit was involved, no patch to wait for, no CVE assigned. The whole attack is a file an AI coding agent was already built to trust, sitting in a folder a website can write to without asking permission.

Jump to what we checked in our own agent working-directory defaults if your team runs Codex or Claude Code from wherever a download happens to land.

What Forever Security Actually Found

Forever's software blocked a coding agent from installing function-color, a package tied to a malware campaign researchers at CloudSEK and Checkmarx later named MALFEX, one that pulls in a second downloader and runs a Windows payload. The package had been live on npm since July 2025 and went unnoticed for roughly two years before npm replaced it with a security-holding release on October 7, 2026.

Tracing the install attempt led Forever's researchers, Gal Weizman and Omer Samet, to an AGENTS.md file in the customer's ~/Downloads directory, disguised as a routine engineering-guidelines document. That folder was also the agent's working directory, which matters because coding agents automatically read and act on instruction files found in the directory they start in, AGENTS.md for Codex and CLAUDE.md for Claude Code.

The researchers published their full account on October 22, 2026, titled "Markdown Is the New Executable," and were blunt about what this is: "There is nothing here for OpenAI or Anthropic to patch. An agent that follows the AGENTS.md in its folder is doing exactly what it was built to do."

Two Ordinary Behaviors, Combined

Nothing involved here is a bug on its own. An agent trusting the instruction file in its working directory is the intended design. And a web page silently saving a file into ~/Downloads, with the name and contents of the attacker's choosing, is normal browser behavior in Chrome, Edge, and Firefox, which save downloads without a per-file prompt by default. Forever built a proof-of-concept page that drops a harmless test file into Downloads with no click required; when outside testers tried the same page in Brave, that browser prompted before saving, which would have tipped off the user.

Put those two ordinary behaviors together and a web page can plant orders in a folder an agent is likely to read from. The only remaining requirement is that someone actually launches an agent inside that folder, which Forever says is far more common than it sounds. The firm's telemetry puts hundreds of customers running Codex, Claude Code, or Cursor CLI from ~/Downloads, with Claude Code alone logging more than 1,300 sessions started there, because people routinely point an agent at Downloads to organize it or act on something they just pulled down.

Codex Ran the Malware in More Than 90% of Attempts

Forever reproduced the attack by running the real 13 KB attacker file, inside an isolated virtual machine, against Codex. The document reads as a dull set of engineering guidelines, with the actual payload buried in one section near the end. It instructs Codex to add an MCP server entry to ~/.codex/config.toml, the agent's machine-wide configuration file, not something scoped to one folder. That server's launch command runs npm install function-color through launchctl, and because the install needed network access, the file also had Codex spin up a child session with sandboxing and approval checks bypassed.

Codex only obeys an AGENTS.md in a directory it already trusts, and a folder a user has previously worked in qualifies. Forever reports that, with that one condition met, Codex ran the malicious install in more than 90% of attempts. The persistence angle is the part worth sitting with: because config.toml is machine-wide, every later Codex session on that machine, in any project, loads the attacker's server at startup. Leaving the folder does not undo it.

Claude Code Leaked Its Own Login Token About Half the Time

Claude Code proved harder to fool outright, so Forever's working attack took a different shape. A planted CLAUDE.md, framed as internal gateway setup, asked Claude Code to write a settings file pointing its API traffic at a server the researchers controlled. Claude Code generally asks a person to approve a change like that and often refuses ones that look wrong, but in testing it followed through roughly half the time.

One settings write does two things at once. Every subsequent API request, including the agent's own login token, now goes to the attacker's server, which is account takeover on its own. The attacker's server can also answer back as if it were the model, meaning it can hand the agent tool calls to run with sandbox protections turned off.

Using a subagent to "validate the config" as pretext, Forever got code execution inside the same session in roughly a fifth of its test runs, according to BleepingComputer's independent coverage of the research.

What We Checked in Our Own Agent Defaults

We pulled the default working directory every engineer on our team uses when they launch Codex or Claude Code day to day. None of us were starting sessions in ~/Downloads, but two people had a habit of launching an agent at the home directory root rather than inside a specific project folder, which on both tools can let an instruction file higher up the tree get picked up for work it was never meant to guide.

We changed our internal guidance to require starting agents inside the specific project directory only, and added a reminder to read any AGENTS.md or CLAUDE.md that wasn't authored by someone on the team, including the one that ships inside a freshly cloned repository.

What to Check Before Your Next Agent Session

• Stop starting a coding agent with ~/Downloads as its working directory, and prefer the narrowest project folder over a broad parent directory or your home folder.
• Read any AGENTS.md or CLAUDE.md file you did not write before letting an agent act on it, including ones bundled in a repository you just cloned.
• Check ~/.codex/config.toml for MCP server entries you did not add, and check Claude Code's settings.json for an ANTHROPIC_BASE_URL pointing anywhere other than Anthropic's own endpoint.
• If you find a planted instruction file, rotate the agent's credentials and treat any machine with function-color installed as compromised, since npm has since pulled the package.

The honest limitation here is that Forever could not determine how the original AGENTS.md reached the customer's machine; the silent-download proof of concept was demonstrated separately as one plausible route, not confirmed as what actually happened in that case. The 90%, 50%, and roughly-a-fifth figures are also Forever's own vendor-run tests, not numbers an independent lab has reproduced yet, so treat them as indicative of a real class of risk rather than a settled, precise rate.

We see the same pattern in the Claude Code Desktop vulnerability that beat three layers of sandboxing: an agent's trust boundary keeps turning out to be wider than the sandbox drawn around it, and the fix each time has been to narrow what the agent is allowed to read and reach, not to wait for a patch that was never going to ship.

The verdict: Codex and Claude Code both did exactly what they were designed to do, obey the instruction file in their working directory, and that design is precisely what made them hijackable by a file neither vendor has any code to fix.

The rule: a coding agent's working directory should be the narrowest project folder for the task at hand, never a folder the web can write into, and any instruction file you didn't author is unverified input until you've read it yourself.

FAQ

What is the AGENTS.md Downloads folder attack?
Forever Security found a malicious AGENTS.md file in a customer's ~/Downloads folder that instructed a coding agent to install a malicious npm package. The folder was also the agent's working directory, so the agent loaded the file as trusted instructions and acted on it.

Is this a vulnerability OpenAI or Anthropic need to patch?
No. Forever Security says explicitly that the agents are behaving as designed when they follow an instruction file in their working directory. The risk comes from where the file lands and where a user launches the agent, not from a bug in either product.

How often did the attack actually work?
In Forever's own tests, Codex ran the planted install in more than 90% of attempts. A separate Claude Code attack that rewrote its API endpoint succeeded roughly half the time, with code execution in about a fifth of those sessions. These are Forever's figures and have not been independently reproduced.

How do I protect my own AI coding agent?
Never start a coding agent with ~/Downloads as its working directory, always use the narrowest relevant project folder, read any AGENTS.md or CLAUDE.md you didn't write before letting an agent near it, and check your agent's configuration files for servers or endpoints you didn't add yourself.

I'm Rohit, founder of Krova Cloud: disposable, per-minute-billed VMs where every agent session starts in a clean, scoped working directory instead of a shared machine that can carry a planted file from one project into the next. More debugging stories at debugly.dev.