An AI coding agent tried to install malware after reading AGENTS.md in the Downloads folder. The installation attempt stopped there, but the file gave investigators something concrete to examine. Its instructions made an unwanted package look like part of the development setup.
The October 22, 2026 disclosure followed the observed incident with tests against Codex and Claude Code. Those experiments reached code execution and, through a separate route, exposed a login token. The results show what the test setups allowed; the blocked installation attempt has a narrower, documented outcome.
The Working Folder Supplies Instructions
Starting Codex in a folder helps select the instructions it reads before work begins. Global guidance comes first, followed by project instructions along the path to the working directory. If it cannot find a project root, Codex checks the current directory instead.
That behavior makes sense for a repository containing a team’s build commands and coding conventions. Downloads holds a less predictable collection. Someone might ask an assistant to sort a document there while an unrelated instruction file sits beside it.
Because AGENTS.md enters the startup context, the person needn’t mention it in the request. The task and the source of its instructions can come from different files in the same folder.
Browser Delivery Remains A Separate Demonstration
Nobody established how the malicious instruction file reached Downloads. The browser route came from a later demonstration, in which a website delivered a file with that name. It offers a plausible delivery mechanism, while leaving the original incident’s entry point unresolved.
In a separate browser check, the demonstration page downloaded a harmless AGENTS.md. Chrome, Edge and Firefox saved it without asking for a destination under the tested settings, although download notifications remained visible. Brave asked for approval.
From there, another event was necessary. An agent had to start in Downloads and read the file. Markdown could sit on disk without doing anything; the coding tool turned its contents into requests for actions.
A Setup Request Changes The Agent’s Reach
The Codex file asked for an MCP tool server, presenting the registration as routine preparation. Its destination was ~/.codex/config.toml, the user’s default configuration file. A local server definition includes a launch command, so accepting that edit gave the planted instructions a way to start a program.
The scope matters here. User configuration applies across projects, whereas .codex/config.toml can hold settings for one trusted project. As a result, leaving Downloads would not undo the change to the user’s server registration.
To check the setup, the payload requested another Codex session with approval and sandbox checks disabled. A macOS service launcher also kept the package installation alive beyond the server startup timeout. These details describe the reproduced route through changed settings and a less restricted process. They don’t establish a universal escape from independently enforced restrictions.
A Different File Redirects Model Traffic
Claude Code followed a different route in the tests. A planted CLAUDE.md asked it to write .claude/settings.json as part of an apparent gateway setup. That edit pointed ANTHROPIC_BASE_URL at a test server under the investigators’ control.
Once requests reached that server, they exposed an OAuth token. The server could also answer with tool calls as though it were the model, and the tests demonstrated command execution. This was a separate experiment; the observed incident did not establish use of that path.
The base URL and the credential source do different jobs. One selects the destination for model requests. The other determines which credential travels with them. An approved gateway can use its own credential in place of a subscription login, but changing the destination alone doesn’t make that substitution.
The Package Connects To Earlier MALFEX Coverage
The attempted installation named function-color, a package already associated with MALFEX. We previously examined its role in MALFEX’s separate npm delivery paths.
That wrapper depended on function-flag, whose installation script retrieved another payload. Meanwhile, other packages in the campaign followed separate paths to a remote access trojan or a stealer. Sharing a campaign label did not make their delivered code interchangeable.
Here, the new evidence concerns how an agent received the installation request. An instruction file supplied the order before normal dependency selection could explain it. Still, a reused package name does not identify the person who planted the file or establish a particular malware family on the affected machine.
The Test Results Have Defined Limits
Most tests ended with a calculator opening. That harmless substitute showed that a command could run, while one isolated virtual-machine test used the real malicious package. The published work covers Codex and Claude Code under the tested conditions, without identifying every affected release or enterprise configuration.
On the affected machine, the installation attempt stopped before the package could run. Its unknown delivery route, total victim scope and any stolen data remain unresolved in the disclosure.
The token test adds a consequence beyond starting a local program. Credentials reached a new destination because the agent changed where it sent requests. A process record could show a command launch, but that alone would miss the account exposure. Likewise, seeing an unfamiliar connection would leave the earlier instruction-file and configuration changes unexplained. Those events occupy different parts of the same investigation.
Conclusion: Local Instructions Need Separate Authority
An instruction file can influence an agent before the requested task begins. In this case, text in Downloads supplied an installation request. The installation attempt stopped, while separate tests demonstrated execution and token exposure. Those outcomes warrant controls over what the agent can change after reading local guidance.
The critical decision concerns authority. A document that describes development setup should not authorize changes to user configuration, model destinations or execution safeguards. Otherwise, an apparently routine preparation step can alter the conditions governing later work.
Why This Threat Matters
- Location influences trust. An agent can encounter instructions because of its working directory, even when the user requests another task.
- Configuration extends the effect. A user-level server registration can affect later projects, so deleting the original file alone may leave the change active.
- Routing carries identity risk. Redirecting model traffic can expose credentials before a malicious program starts.
- Approval scope matters. Permission to inspect a downloaded document should not imply permission to weaken safeguards or register new tooling.
- Incident evidence has limits. The browser delivery demonstration explains one possible route, but it does not establish how the malicious file arrived.
Where Defensive Control Must Operate
Keep agent work in reviewed project directories and require separate authorization for sensitive configuration changes. Enforce those limits through permissions and administrative policy outside the model’s control. Otherwise, a file can ask the agent to relax the very checks meant to constrain its actions. Review model destinations and tool-server registrations before allowing a new configuration to run.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, addresses suspicious process execution and follow-on payload behavior on supported, managed endpoints. When an agent launches additional code, Execution Governance restricts unknown code’s access to real endpoint resources under the applicable policy. Behavioral telemetry also helps analysts investigate what the agent started and what that process did.
Validate those controls against the deployed platform, agent version and policy before relying on enforcement. Code running inside a trusted interpreter requires separate review of the package and runtime path. Configuration permissions and model-routing restrictions remain necessary, while credential exposure requires provider-side revocation.
Recovery Must Check Configuration And Credentials
Preserve the suspicious file and relevant records before cleanup. Then compare user and project settings with an approved baseline, remove unauthorized registrations and restore approved destinations. If evidence shows credentials reached an unapproved server, revoke the affected tokens or sessions through the provider and replace exposed secrets. Finally, verify both configuration and account state before resuming agent work. A stopped package installation answers one execution question, while routing and credential exposure require their own checks.
