A planted AGENTS.md file can hijack a coding agent from the Downloads folder

What Forever Security found

Forever Security says it stopped a coding agent while it tried to install the malicious npm package function-color [1]. Investigators traced the instruction to an AGENTS.md file in the customer's ~/Downloads directory, which was also the agent's working directory.

The company did not determine how that file arrived on the machine. That distinction matters: the attempted malicious install and its instruction source came from customer telemetry, while silent browser delivery was a route the researchers reproduced afterward.

BleepingComputer also reported the disclosure [2] after reviewing the researchers' account. Its report also notes that the package had been removed from npm by publication time.

Why an instruction file can become an execution path

Instruction files are supposed to shape agent behavior. A project can use them to specify build commands, coding conventions and test procedures. The risk appears when an agent treats instructions from an unreviewed, externally writable directory as trusted project policy.

Anthropic's current documentation says Claude Code can load AGENTS.md at session start from the working directory and directories above it [5]. It also says CLAUDE.md and AGENTS.md are context rather than enforced configuration. A separate hook or permission boundary is needed when an action must be blocked regardless of the model's decision.

A malicious file does not execute by itself. The agent reads the text, decides to follow it and then uses its available tools. The resulting damage therefore depends on the working directory, permission mode, sandbox, network access, credentials and whether a person approves sensitive steps.

What the Codex reproduction showed

OpenAI documents AGENTS.md as a source of custom instructions for Codex [3]. Forever Security placed the customer payload in an isolated virtual machine and reported that Codex installed the real malicious package in more than 90% of attempts.[1] The instructions presented the package as an MCP-based project tool and directed the agent to add it to the machine-wide Codex configuration.

The reported chain asked Codex to start a child process with approvals and sandboxing bypassed.[1] This is an important limit on the headline result: the file persuaded the agent to weaken controls that would otherwise have blocked network access or required approval.

Because the payload changed ~/.codex/config.toml, the effect could persist after leaving Downloads.[1] A later Codex session could load the added server from another project unless the configuration was reviewed and repaired.

What the Claude Code reproduction showed

The Claude Code proof of concept used a different route. Researchers say a malicious instruction file persuaded Claude Code to write project settings that redirected API traffic to a server they controlled.[1] Once the setting existed, the server received the session's OAuth token and could return tool calls as though it were the model.

Forever Security reports that the configuration write succeeded in about half of its tests.[1] The write was the main obstacle because Claude Code often refused suspicious instructions or required approval.

Anthropic's security guide describes permission modes, working-directory prompts, sandboxing and network controls [4]. It also tells users to review commands and critical-file changes, and to use virtual machines when handling untrusted external content.

The disclosure does not establish that every version, operating system or permission configuration behaves the same way. Teams should reproduce the relevant control tests on their own managed setup.

What coding-agent users should do now

Start the agent from the root of the specific repository you intend to change. Do not use Downloads, your home directory or another broad parent as the working directory.

Before the next session, inspect unexpected AGENTS.md, CLAUDE.md and nested instruction files. Review agent settings for new MCP servers, base-URL overrides, proxies, hooks and commands that disable approvals or sandboxing.

If you find the function-color package, an unknown API endpoint or an unauthorized server configuration, isolate the host before investigating. Review ~/.codex/config.toml for unknown mcp_servers entries and .claude/settings*.json for ANTHROPIC_BASE_URL, proxy or env overrides. Remove persistence from a trusted environment, rebuild affected tooling, revoke Claude Code sessions and rotate every API key or credential the agent could access.

• Keep approval prompts and sandbox protections enabled.
• Deny network access by default for code that does not need it.
• Treat cloned repositories and downloaded archives as untrusted until their instruction files are reviewed.
• Separate agent credentials from personal browser sessions and production secrets.
• Monitor changes to user-level agent configuration as well as repository files.
• Where the tool exposes loaded instructions, preserve that list with the session audit trail.

What remains uncertain

• The researchers could not determine how the AGENTS.md file reached the observed customer machine.[1]
• The public report does not identify the affected organization, agent version, full host configuration or duration of exposure.[1]
• The reported success rates come from Forever Security's tests and have not been independently reproduced in a published technical study.[1]
• The disclosure does not show that the customer lost credentials or that the malicious package executed. Forever Security says it stopped the attempted install before code ran.[1]
• Browser download behavior varies by browser, policy and user settings, so silent delivery should be tested against the managed browser configuration in use.
• Provider controls and agent behavior can change after publication. Current release notes and security documentation remain part of the response.

How to test your setup without using a live payload

Create a disposable virtual machine with no real credentials and add a harmless instruction file that asks the agent to write a marker outside the project, modify user-level configuration and contact a local test server. Do not copy the published malware command or point the test at a public endpoint.

Run the case under the same permission and sandbox policies your team uses. The expected result is a clear refusal or approval prompt for every boundary crossing, plus an audit record that names the instruction source.

Repeat the test after agent upgrades, policy changes and new browser integrations. A passing model response is weaker evidence than an operating-system or network control that blocks the action.

Frequently asked questions

• Is AGENTS.md malware? No. It is a project-instruction format. The risk comes from malicious content being trusted by an agent with tools and permissions.
• Was a real machine involved? Forever Security says yes. It observed an attempted malicious package install on a customer machine and stopped it before execution.
• Did a website definitely plant the customer's file? The researchers did not determine the delivery route on that machine. They demonstrated browser-based delivery separately.
• Are only Codex and Claude Code affected? Those are the two products in the published reproductions. The broader issue can apply to any agent that automatically trusts local instruction files and can act on them.
• Do approval prompts solve the problem? They reduce risk, but a person can still approve a plausible setup command. Filesystem, network and credential boundaries provide additional controls.
• What should I check first? Confirm the agent's working directory, inspect instruction files, and review user-level configuration for unknown servers or endpoint overrides.