A Malicious AGENTS.md in Your Downloads Folder Can Hijack Your AI Coding Agent

A plain-text instructions file quietly placed in a developer's Downloads folder tried to turn their AI coding agent into a malware installer. The attempt was caught on a real workstation and blocked before anything ran, but the mechanics behind it apply to anyone who opens Codex, Claude Code or a similar agent in a folder they do not fully control.

What happened

The file was named AGENTS.md. Coding agents such as OpenAI's Codex read a file with that name automatically when they start in a folder and treat its contents as project guidance. This one was dressed up as ordinary engineering notes. Buried inside was a section instructing the agent to register a new tool server in its own configuration and to install an npm package called function-color.

That package is not an innocent typo. It belongs to a malware campaign tracked as MALFEX: function-color pulls in a downloader named function-flag, which in turn fetches and executes a Windows payload. Had the agent followed the notes, the developer's machine would have been infected by its own assistant.

How the file reached the Downloads folder has not been established.

Why it works

Two behaviours that are harmless on their own combine into a delivery channel.

First, an agent is designed to trust and obey the instructions file in the folder it opens. That is the feature, not a flaw.

Second, a web page can save a file into the Downloads folder without a click or a permission prompt, choosing both the filename and the contents.

Put together, any page a developer visits, or the agent itself visits while browsing, can drop a file that the agent will later read as orders. A proof-of-concept page built during the investigation confirmed that the silent-download half of the chain works exactly as described. Whether a real attacker used this precise route against the affected developer remains unknown.

Codex versus Claude Code

The attack was reproduced against two popular agents inside an isolated virtual machine to show it is not tied to a single product.

Codex. Using the actual attacker file, framed as routine project setup, Codex was told to add a server entry to its global configuration file at ~/.codex/config.toml and run a command that installed the package. Because that configuration applies to every Codex session on the machine, the attacker's server would load in every folder afterwards, not just Downloads. In testing, Codex ran the malicious install in more than nine out of ten attempts.

Claude Code. The working variant looked different and succeeded less often. A planted CLAUDE.md, framed as internal gateway setup, tried to get Claude to write an ANTHROPIC_BASE_URL value into the project's settings file, redirecting the agent's API traffic to a server under attacker control. That single change leaks the session's login token, which amounts to account takeover, and lets the rogue server impersonate the model and hand back commands for the agent to execute. Claude Code requires a human to approve a write like that and frequently refuses one that looks suspicious. Still, the long engineering-document framing got the write approved roughly half the time.

Why there is no patch

This is not a bug in Codex or Claude Code in the usual sense. An agent following the instruction file in its working folder is doing exactly what it was built to do, much as a browser rendering a phishing page is working as designed. The weakness sits in the workflow around the agent: where it is started, which files it trusts, and who is watching when a new file appears.

That matters because of how developers actually work. Telemetry gathered during the investigation suggests roughly half of monitored developer machines launch a coding agent inside the Downloads folder, and around a quarter of agent sessions open a browser on their own. Those are precisely the conditions the attack needs: an agent starting where the web can write, and often nobody present when the file arrives.

What to do

None of the following requires a new product.

• Never start an agent in Downloads. It is the one folder the web can write to without asking you. Move the work into a dedicated project directory first.
• Hunt for instruction files you did not write. A stray AGENTS.md or CLAUDE.md in Downloads, or in a repository you just cloned, is the entire attack. Read it before you let an agent anywhere near it.
• Audit the agent's own configuration. In ~/.codex/config.toml, look for server blocks or base URLs you did not add. In a project's .claude/settings.json, look for an ANTHROPIC_BASE_URL or any API endpoint you did not set.
• Keep approval prompts and sandboxes on. Treat any instruction that tells the agent to disable them as hostile.
• Assume compromise if you find a planted file. Rotate the agent's login token immediately. A stolen token is a live session, not a single intercepted request.

Instruction files and agent configuration are now part of a codebase's attack surface, and they deserve the same scrutiny as a new dependency. Our AI-assisted code review looks for exactly this class of problem across a repository: planted agent instructions, unexpected configuration changes and packages tied to known malware campaigns, flagged before an agent, or a human, acts on them.