A Dropped AGENTS.md Makes Your Coding Agent Write Its Own Config

Your browser writes files into one directory without asking you first. Your coding agent reads instructions out of whatever directory you start it in. Those two defaults were designed by different people for different reasons, and on most developer laptops they now point at the same folder.

Forever Security found the collision on a customer machine. A coding agent tried to install an npm package called function-color. The install was blocked, and the trail led back to an AGENTS.md file sitting in the user's ~/Downloads directory, which was also the directory the agent had been started in. Gal Weizman and Omer Samet published the write-up on October 22, 2026. The researchers could not establish how the file reached the machine, and they say plainly that there is nothing here for OpenAI or Anthropic to patch.

Who this reaches, and who can close the tab

This reaches you if anyone in your organization runs a terminal coding agent on a laptop that also downloads files from the web. That is Claude Code, OpenAI Codex, Cursor CLI, and every tool that follows the same convention of reading a Markdown instruction file from its working directory. It reaches you harder if your developers run agents outside a project checkout, which Forever's own telemetry suggests is common: the firm says about half its customers have started an agent in ~/Downloads, and that Claude Code alone accounted for more than 1,300 sessions launched from there. Those are vendor-supplied numbers from a company that sells agent monitoring, so weigh them accordingly. They match what I see on developer machines.

You can stop reading if your developers run agents only inside container images or remote development environments where the home directory is rebuilt per session and no browser runs. You can also stop if nobody at your company runs an autonomous agent at all. There is no server here to patch, no CVE to track, and no exposure that reaches you over the network. The whole attack needs a file on local disk and a human who starts an agent in the wrong folder.

For the owner reading this: the short version is that a Markdown file downloaded from a web page can give instructions to the AI tools your developers now use to write code, and those instructions can change the tool's permanent settings. The fix costs nothing. It is a rule about which folder people start the tool in, plus two files somebody should look at this week.

The file is a config-write primitive

Most coverage described this as prompt injection, which undersells what the payload actually asked for. The interesting instruction was not "run this command." It was "write this line into your own configuration."

Against Codex, the planted file asked the agent to add a Model Context Protocol server entry to ~/.codex/config.toml and then start a second Codex session with approval prompts and sandboxing turned off. That path matters because of where it writes. OpenAI's configuration reference documents ~/.codex/config.toml as the user-level file, with an mcp_servers table and two base-URL keys, chatgpt_base_url and openai_base_url. The same page notes that Codex ignores both base-URL keys when they appear in a project-local .codex/config.toml. A per-project file is contained. The home-directory file applies to every project on the machine, so one write in a Downloads folder follows the developer into the production repository they open tomorrow. Forever reports the Codex chain succeeding in more than nine of ten attempts, with a harmless calculator payload standing in for the real one during most of that testing.

The Claude Code variant used a CLAUDE.md file and went after credentials instead. It asked the agent to write a project .claude/settings.json that pointed API traffic at a server the attacker controlled. A redirected endpoint sees the OAuth token on every request, and it can answer with tool calls of its own choosing, which turns the agent into an execution channel. The researchers measured the file write landing about half the time and execution inside the same session in roughly one attempt in five.

The package at the end of the chain was already known. Checkmarx tracked function-color as part of the MALFEX campaign, where it acts as a wrapper around function-flag, whose install routine pulls down and runs a Windows payload and fails quietly on macOS and Linux. The delivery method is new. The payload is ordinary npm malware that has been in circulation since late September.

Audit the two files your agents write to

Detection here is a configuration diff, not a hunt for malicious behaviour. The attack leaves its evidence in two well-known paths plus any stray instruction file. Run this on developer workstations, or wrap the same checks in whatever you use for fleet queries.

#!/usr/bin/env bash
# Agent configuration audit. Read-only. Run as the developer, not as root,
# because every path below lives in that user's home directory.

echo "== Instruction files in directories nobody should start an agent in =="
for d in "$HOME/Downloads" "$HOME/Desktop" "$HOME/Documents" "$HOME"; do
  find "$d" -maxdepth 1 \( -name 'AGENTS.md' -o -name 'CLAUDE.md' \
    -o -name '.cursorrules' -o -name 'GEMINI.md' \) \
    -printf '%TY-%Tm-%Td  %p\n' 2>/dev/null
done

echo
echo "== Codex: MCP servers and endpoint overrides in the machine-wide file =="
CODEX="$HOME/.codex/config.toml"
if [ -f "$CODEX" ]; then
  grep -nE '^\[mcp_servers|chatgpt_base_url|openai_base_url|approval_policy|sandbox_mode' "$CODEX"
else
  echo "  (no $CODEX on this host)"
fi

echo
echo "== Claude Code: endpoint and token overrides in every settings file =="
find "$HOME" -name 'settings.json' -path '*/.claude/*' 2>/dev/null \
  -exec grep -lE 'ANTHROPIC_BASE_URL|ANTHROPIC_AUTH_TOKEN|HTTPS?_PROXY' {} +

echo
echo "== Git repos carrying an agent settings file somebody may not have read =="
find "$HOME" -type d -name '.claude' -not -path '*/node_modules/*' 2>/dev/null \
  | while read -r d; do
      [ -f "$d/settings.json" ] && echo "  $d/settings.json"
    done

Three results deserve a phone call rather than a ticket. An [mcp_servers.*] block in ~/.codex/config.toml that the developer did not add. A base-URL key in either tool pointing anywhere other than the vendor. An instruction file in ~/Downloads with a modification time the developer cannot account for. Treat the last one as a live credential incident: a redirected endpoint has already seen a session token, and rotating that token is the only thing that ends the attacker's access.

Three settings that take the chain apart

The research frames this as unpatchable, and that is accurate about the agents' design. It is also incomplete, because both vendors ship documented controls that break the chain at different links. None of them are on by default.

// ~/.claude/settings.json  (user scope, applies in every project)
{
  "permissions": {
    "blockReadsOutsideWorkingDirectories": true,
    "deny": [
      "Read(~/.claude/settings.json)",
      "Read(./.claude/settings.json)",
      "Edit(~/.claude/settings.json)",
      "Edit(./.claude/settings.json)",
      "Edit(~/.codex/config.toml)"
    ]
  }
}

# ~/.codex/config.toml  (user scope)
approval_policy = "on-request"
sandbox_mode    = "read-only"

Three facts from Anthropic's settings documentation explain why this specific shape works. First, deny and ask rules apply immediately, while permissions.allow, additionalDirectories and most env values from a project file wait until the developer trusts that folder. That trust step is the gate standing between the written file and the redirected traffic, and it is a reasonable explanation for the gap Forever measured between a write landing half the time and execution following in a fifth of attempts. Second, blockReadsOutsideWorkingDirectories set to true is honoured from any scope, even when an organization's managed settings say otherwise, so a developer can tighten it without waiting on a policy change. Third, settings precedence runs managed, then command line, then project local, then shared project, then user, which means a managed deny rule deployed centrally cannot be overwritten by anything a downloaded file persuades an agent to write.

On the Codex side, sandbox_mode accepts read-only, workspace-write and danger-full-access, and approval_policy accepts on-request, never and a granular form. The planted file in this case asked for a session with both relaxed. Any instruction that asks an agent to lower its own approval or sandbox settings is the signal, whatever reason the file gives for it.

One rule for the people running the agents

Start agents in the root of the project you are working on. That single habit removes the attack, because the instruction file has to be in the working directory to be read, and a project checkout is a directory the web cannot write to on its own.

Two habits follow from it. Read any AGENTS.md or CLAUDE.md you did not write before an agent acts on it, including the one in a repository you just cloned, where the file is as much a part of the untrusted payload as the source. Keep approval prompts and sandboxes switched on, and treat a request to disable them as the thing to escalate rather than the thing to click through.

The part worth sitting with is that neither vendor can fix this from their side. An agent that reads project instructions from its working directory is doing the job it was built for. The defect is in the workflow around it, which is where your controls live anyway.

Diff the two config files before your next agent session

Run the audit block above across every machine with a coding agent on it, this week. Record what ~/.codex/config.toml and each .claude/settings.json contain today, because the value of this audit comes from the second run, when you have a baseline to compare against. Then push the deny rules and the sandbox defaults as a managed policy, so that a developer who starts an agent in the wrong folder still lands somewhere the file cannot reach.

If you want a second set of eyes on how your developers actually run these tools, or you found a base-URL override you cannot explain and need the credential rotation sequence, book a session with us. We review AI agent configurations and the permission boundaries around them for teams who adopted these tools faster than they wrote policy for them.