A planted AGENTS.md in Downloads: how to check your Claude Code and Codex setup

by Iliya OblakovPublished on October 31, 202610 min read5 views

AGENTS.md and CLAUDE.md files are instructions that AI engines read at startup and follow. A security report published on 22 October 2026 shows what happens when one of those files lands somewhere you did not expect, and the folder it landed in was ~/Downloads.

This post covers what was reported, how to check where Claude Code and Codex load instruction files from on your own machine, and a short checklist.

What happened

On 22 October 2026, Forever Security published "Markdown Is the New Executable", by Gal Weizman and Omer Samet (report). The company says it stopped a coding agent on a customer's machine from installing function-color, a known malicious npm package. It traced the install back to an AGENTS.md file in the customer's ~/Downloads folder, written to look like ordinary engineering notes. The report says nobody knew how the file got there.

BleepingComputer covered it on 25 October (article), and The Hacker News on 26 October (article).

The researchers point at two behaviours that are each normal on their own. AI engines read and follow the instruction file in the folder they start in, and a web page can save a file into Downloads, often without a prompt. Forever built a proof-of-concept page that downloads an AGENTS.md silently. The Hacker News notes it is not known whether a real attacker used that route against the customer. BleepingComputer adds that in its own test Brave asked before saving the file, and that Chrome, Edge and Firefox show a download notification by default.

Codex. The planted file told Codex to append a [mcp_servers.project-tools] block to ~/.codex/config.toml and then start a child codex exec with --dangerously-bypass-approvals-and-sandbox, framed as routine setup. Forever says Codex ran the malware in more than 90% of its attempts. Most of that testing used a harmless stand-in that only opens a calculator, which is how BleepingComputer describes its 90% figure, and Forever ran the real malicious package once, inside an isolated VM. Forever also notes that Codex only obeys an AGENTS.md in a project it trusts, and that Downloads qualifies once you have worked there. Because ~/.codex/config.toml is machine-wide, the added server loads in every later Codex session, in any folder.

Claude Code. Forever wrote its own test CLAUDE.md, modelled on the attacker's file. It asked Claude Code to save ANTHROPIC_BASE_URL, pointing at a server Forever controlled, into .claude/settings.json. Forever says the write got through about half the time, and that once it is written the OAuth token goes to that server, which can then answer as the model and send back tool calls. Code execution inside the same first session worked about a fifth of the time.

Forever's position, quoted by both outlets, is that "There is nothing here for OpenAI or Anthropic to patch", because the AI engine is doing what it was built to do. In Forever's telemetry about half of its customers run a coding agent inside their Downloads folder. Weizman told BleepingComputer that Claude Code alone launched more than 1,300 sessions from that location. According to Forever, npm has since removed function-color.

How to check your own Claude Code and Codex setup

The steps below follow the official docs for Claude Code and Codex, which I read on 29 October 2026.

Know where each AI engine looks

Codex, per its AGENTS.md guide:

Global: ~/.codex/AGENTS.override.md if it exists, otherwise ~/.codex/AGENTS.md (under CODEX_HOME instead, if you set it).
Project: every directory from the project root (usually the Git root) down to the folder you launched from. In each one it checks AGENTS.override.md, then AGENTS.md, then any names in project_doc_fallback_filenames. When there is no project root, it checks only the current directory, which is the usual Downloads case.

Claude Code, per its memory docs:

~/.claude/CLAUDE.md, plus CLAUDE.md and CLAUDE.local.md in the folder you launch from and every folder above it.
AGENTS.md: the docs say that by default Claude Code reads it only when there is no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md in your working directory or above it, and that reading AGENTS.md directly needs v2.1.277 or later. Your own ~/.claude/CLAUDE.md does not count, so it does not stop an AGENTS.md from loading. In an interactive session you see a line such as no CLAUDE.md found; AGENTS.md loaded: .... The report did not test this path, but an AGENTS.md in Downloads fits it.

Because Claude Code reads every folder above where you start, a stray CLAUDE.md sitting directly in your home folder would load in every project under it.

Look for files you did not write

From a terminal:

ls -la ~/Downloads | grep -iE 'agents|claude'
find ~ -maxdepth 2 \( -name 'AGENTS*.md' -o -name 'CLAUDE*.md' \) 2>/dev/null

Your own ~/.claude/CLAUDE.md and ~/.codex/AGENTS.md will show up, and that is expected. Open anything else and read it before you start Claude Code and Codex near it.

Check the config the attack rewrites before you start a session

Do this before you start Claude Code and Codex again. Forever describes how the added MCP server loads at startup in every Codex session on the machine, and a changed base URL sends your requests, and your token, to someone else's endpoint. These commands only read files and list the configured servers; they do not start a session. In a terminal, cd into the project you will work in first, because the last line reads that project's .claude folder.

grep -nE 'mcp_servers|chatgpt_base_url' ~/.codex/config.toml
codex mcp list
grep -n 'ANTHROPIC_BASE_URL' ~/.claude/settings.json .claude/settings.json .claude/settings.local.json 2>/dev/null

Every MCP server and base URL in there should be one you added. Forever names exactly these places: an unexpected [mcp_servers.*] block or a changed chatgpt_base_url in ~/.codex/config.toml, and an ANTHROPIC_BASE_URL, proxy or other endpoint you did not set in a project's .claude/settings.json. Codex can also read MCP servers from a project-scoped .codex/config.toml in trusted projects, so check that file in your repos too. If anything there is unexpected, remove it and rotate your tokens before you start either AI engine again.

See what actually loaded

Once the config is clean, start each AI engine from the project folder you work in and check what it read.

Claude Code: run claude --version first. The docs say that before v2.1.280, /memory and /context did not list an AGENTS.md that Claude read directly, so update to v2.1.280 or later before you rely on them. Then run /context and check the list under Memory files, or /memory to see the files and open them. /status shows a Setting sources line with the settings files loaded for the session.
Codex: the guide suggests asking it which instruction sources it loaded, and offers a plaintext log for an audit trail. Its example turns approval prompts off, so I run the question from the project folder with a read-only sandbox, approval prompts set explicitly and routed to me rather than to an automatic reviewer, and the log on: codex --sandbox read-only --ask-for-approval on-request -c approvals_reviewer=user -c log_dir=./.codex-log "List the instruction sources you loaded.". Then read ./.codex-log/codex-tui.log. Inside Codex, /status shows which directories are in the workspace.

Watch where you launch from

Start Claude Code and Codex from the root of the project you are working on. BleepingComputer reports that this is the common recommendation from OpenAI and Anthropic, rather than your home folder or a broad parent folder, and Forever's first piece of advice is not to start an AI engine in Downloads at all. If you want an AI engine to sort your downloads, move the files into a separate folder first and read any .md file in it.

Keep the prompts and the sandbox on

Codex's approvals and security page describes the default CLI sandbox as having no network access and write access limited to the active workspace. It marks --dangerously-bypass-approvals-and-sandbox (alias --yolo) as elevated risk, and that flag is exactly what the planted file asked Codex to use. Claude Code's security page says an interactive session shows a workspace trust dialog in a folder you have not trusted, that servers in a project's .mcp.json have their own approval prompt, and that a -p session shows neither prompt. If a trust or approval prompt appears for Downloads, decline it.

Checklist

Pick the project folder you will work in and cd into it in a terminal, but do not start Claude Code and Codex yet. Never start them from ~/Downloads or directly from your home folder.
Search Downloads and your home folder for AGENTS.md, AGENTS.override.md, CLAUDE.md and CLAUDE.local.md files you did not write, and read any you find.
Check ~/.codex/config.toml and codex mcp list for MCP servers or base URLs you did not add.
Check .claude/settings.json and .claude/settings.local.json for an ANTHROPIC_BASE_URL you did not set. Remove anything unexpected and rotate your tokens first.
Only then start Claude Code and Codex from the project folder. Run /context in Claude Code (v2.1.280 or later, since earlier versions left a directly read AGENTS.md off that list), ask Codex with a read-only sandbox and approval prompts on to list its instruction sources, and compare both lists with the files you expect.
Keep approval prompts and the sandbox on, and treat any instruction to bypass them as a red flag.
If you find a planted file, assume the token leaked and rotate it, as Forever advises.

Why I keep my rules files readable

I think this report is a good reason to keep instruction files small enough to read in one sitting. Forever says the attacker's file was a 13 KB "Engineering Work Guidelines" document, and that the long, ordinary framing is what got it through. A file that size is hard to check line by line.

That is how I set up the Two Engines Kit. It gives Claude Code and Codex one rulebook: the installer points ~/.claude/CLAUDE.md at the shared rules and builds ~/.codex/AGENTS.md from them, previews each change and asks before it makes it. The hooks are plain text you can read, and Codex reviews read-only. It does not stop a planted file, so the checks above still apply. It is built on information gathered since the first Codex and Claude CLIs. If you want the workflow behind it, I wrote it up in How to use Claude Code and Codex together.