In the week of October 19, 2026, researchers at Forever Security disclosed a finding that is easy to underestimate because it sounds so mundane: a plain-text file sitting in a developer’s ~/Downloads folder was able to steer an AI coding agent into installing a malicious npm package. BleepingComputer and Cybersecurity News covered the research, which reproduced the attack against OpenAI Codex with a reported 90% success rate and demonstrated a related technique against Claude Code that leaked an OAuth token and allowed account hijack.
The detail that should make every platform and security leader pause is a single line from the researchers: “There is nothing here for OpenAI or Anthropic to patch.” This is not a bug in an AI tool. It is the AI tool doing exactly what it was designed to do — reading the instructions in its working directory and following them — in a situation where those instructions came from an attacker. That makes it a design-level problem for how agentic tools are being adopted, and it is squarely in the territory security teams now have to own.
This post explains what an AGENTS.md file is, how the attack chain works end to end, why it cannot be fixed with a vendor patch, and a practical set of controls that let your team keep using coding agents without leaving this door open. As with most of these agentic-AI stories, the problem is real but the response is well within reach.
What Happened
To follow the attack, you first need to know what an AGENTS.md file is. It is a plain-text Markdown file that carries project-specific instructions for an AI coding agent — the tools to use, how to run tests, coding conventions, setup steps. Several popular agents, including OpenAI Codex, read this kind of file automatically from their working directory and treat its contents as guidance for their actions. Claude Code uses a similarly named CLAUDE.md. These files are a genuinely useful feature: they are how a team tells its agent “here is how we work in this repo.”
The Forever Security team found the problem on a real customer machine. An AI coding agent on that machine had tried to install a malicious npm package called function-color. When they traced why, the answer was an AGENTS.md file sitting in the user’s ~/Downloads folder — which, in this case, was also the directory the agent had been launched in. The agent loaded the file, read the instructions, and acted on them. The instructions were not written by the developer.
The researchers then reconstructed the attack chain to understand how dangerous it was:
- Against OpenAI Codex, they used a crafted instruction file to make the agent execute code, measuring a 90% success rate with a harmless demonstration payload (it opened the calculator app — a standard “we could have run anything here” proof).
- Against Claude Code, they used a malicious
CLAUDE.mdto redirect the agent’s API traffic to a server they controlled. That exposed the agent’s OAuth token, let the server impersonate the model, and allowed it to return tool calls that executed code in roughly 50% of tests.
Two capabilities, then: make the agent run attacker-chosen commands, and steal the agent’s own authentication so you can puppet it going forward.
Why the Downloads Folder Is the Clever Part
A fair first reaction is: “fine, but how does a malicious instruction file get into my Downloads folder in the first place, and why would my agent ever run there?”
This is where the research is genuinely sharp. As Forever Security put it, ~/Downloads is special — it is the one folder the web can write to on its own. By default, Chrome, Edge, and Firefox save downloaded files there without prompting the user to choose a location. The researchers built a proof-of-concept page showing that simply visiting a malicious web page could drop a file named AGENTS.md into Downloads silently, with no click beyond the visit. (The browsers do show a download notification, and some browsers such as Brave prompt before saving — so this is not completely invisible, but it is close enough that a distracted developer would not notice.)
The second half — why an agent would ever run in Downloads — is the part that surprised us, and it is backed by data rather than speculation. Forever Security told BleepingComputer that their internal statistics show hundreds of customers running AI agents (Claude Code, OpenAI Codex, Cursor CLI) from their ~/Downloads folder, and that Claude Code alone launched more than 1,300 sessions from that location. It makes sense once you say it out loud: people download a file, then point their agent at the Downloads folder to unzip it, summarize it, clean up, or act on the thing they just downloaded. The working directory ends up being the one folder the web can write to unprompted.
Put the two halves together and the full chain is:
- A developer visits a malicious (or compromised) web page.
- The page silently drops
AGENTS.mdinto~/Downloads. - Later, the developer launches their coding agent with
~/Downloadsas its working directory — a common habit. - The agent loads the attacker’s
AGENTS.md, reads it as legitimate project instructions, and acts: installs a package, runs a command, changes a setting, or leaks a token.
No exploit. No malware delivery in the traditional sense. Just a file, a default, and a habit.
Why There Is Nothing to Patch
This is the uncomfortable core of the story, and it is worth stating plainly so nobody waits for a fix that is not coming.
The agent reading instructions from a file in its working directory is not a flaw. It is the feature. An AGENTS.md-aware agent that follows the AGENTS.md in its folder is doing precisely what it was built to do. There is no memory-safety bug, no authentication bypass, no CVE to assign. The “vulnerability” is the combination of three perfectly reasonable, individually-benign behaviors: browsers saving to Downloads without a prompt, agents reading instruction files from their working directory, and developers launching agents in Downloads.
That is why OpenAI and Anthropic cannot simply ship a patch, and why the responsibility — as the researchers note — lands on the user and the organization. It is also why this generalizes far beyond the two tools that were tested. Any agent that auto-loads instruction files from its working directory is exposed to the same shape of attack. The lesson is not “Codex and Claude Code are unsafe.” The lesson is that untrusted input and agent instructions must be kept apart, and most teams have no boundary enforcing that today.
This is the same root cause we saw when a ransomware crew talked Cursor’s agent into running an intrusion: the agent is an actor with real capability and real access, and the thing separating “assistant” from “attacker” is a block of text it was convinced to trust. Prompt injection stopped being a chatbot curiosity the moment agents got the ability to run commands and call APIs.
The Remediation Guide
The fix comes in two layers, and both are practical. The first layer reduces the chance the agent ever reads a malicious instruction file. The second — the one that actually determines how bad a compromise can get — assumes the agent will eventually be tricked and limits what it can do when it is.
Layer one: deny the agent untrusted instructions
- Never run coding agents from
~/Downloads, Desktop, or your home directory. This is the single highest-value change, and it matches the explicit guidance from both OpenAI and Anthropic: start the agent in the root of the specific project it should work on. The working directory defines the agent’s default context and, in several tools, its filesystem access boundary. Scope it to the project and the attack in this research simply does not fire. - Treat
AGENTS.md,CLAUDE.md, and similar files as code, not config. They can cause command execution, so they deserve the same scrutiny as a script. Review unfamiliar instruction files before letting an agent act on them, and bring them into code review and repository RBAC the way you would any other executable artifact in the repo. - Keep approval prompts and sandboxing on — but do not rely on them alone. They help, and turning them off to go faster is exactly how teams get hurt. That said, a prompt a developer waves away fifty times a day is a usability hint, not a control. Treat it as defense in depth, not the defense.
- Isolate untrusted code. When you do need to run or inspect something you downloaded, do it in an isolated environment, not on the machine that holds your production cloud keys.
Layer two: assume the agent gets tricked, and cap the damage
- Do not let agents hold standing credentials. The reason step 4 of the attack chain — “leak a token,” “install a package,” “call the cloud” — is dangerous is that the agent runs with the developer’s own access. If the agent reaches your cloud through short-lived, scoped, Just-in-Time grants instead of long-lived keys, a hijacked agent can only act within a narrow, time-boxed window — and every action is attributable.
- Broker agent access the same way you broker human access. An AI agent is, for access-control purposes, just another identity that occasionally needs elevated permissions. Route it through the same request-and-revoke machinery. We laid out the reasoning in why AI agents need JIT, not better key vaulting.
- Put a boundary between the agent and credential exfiltration. The Claude Code half of this attack worked by redirecting traffic to steal an OAuth token. On-host controls that watch for and block secret and token exfiltration before it leaves the machine are the layer designed for exactly that move.
- Know what a hijacked agent could reach. If an agent on a given machine were fully compromised right now, which identities, cloud resources, and data sit within reach of its credentials? Being able to answer that in one place, before an incident, is what turns a hijack into a contained event. That is the job of an attack-path-aware asset graph.
Where Cloudanix Fits
There is no product that stops a browser from writing to Downloads or stops an agent from reading its working directory — and we are not going to pretend otherwise. What you can control is the blast radius when an agent is inevitably steered by something it should not have trusted, and that is where our work sits.
- The Coding Agent Firewall is on-host DLP built for AI coding assistants. It is the control aimed directly at the Claude Code half of this attack: catching secret and token exfiltration before it leaves the developer’s machine.
- Just-in-Time access for AI coding agents means a hijacked agent is working with short-lived, scoped credentials instead of your standing keys — so “the agent ran attacker commands” is bounded by what a twenty-minute, narrowly-scoped grant allows.
- A unified asset graph answers the blast-radius question quickly when you need it, correlating the agent’s identity to everything it could touch.
If you want a read on where your coding agents currently hold standing access, a conversation or free assessment is a fast way to find the long-lived keys hiding in environment files and config.
The Takeaway
This finding is important precisely because it is boring. There is no exotic exploit, no zero-day, no clever memory corruption. There is a default, a habit, and a feature, combining into account takeover and code execution. That is the texture of agentic-AI risk going forward: the tools are doing what they were built to do, and the security work is about drawing boundaries around capability and access that the tools themselves do not draw.
The teams that handle this well will do two unglamorous things. They will scope where their agents run, so untrusted instructions never reach them. And they will make sure that when an agent is fooled — because eventually one will be — it is holding a short-lived, narrowly-scoped credential rather than a standing key to the cloud. Do both, and a hijacked agent is an annoyance you clean up, not an incident you report. That is an outcome you can build toward starting today.
