AI Agent Safety: Keep Downloads Out of Your Workspace
If you use an AI coding assistant, check its working folder before your next session. Keep it out of Downloads and review project instructions before giving it permission to run commands.
The short version
What you need to know
- The risk is an assistant acting on untrusted local instructions—not a Markdown file executing itself.
- Forever Security reports a blocked installation on a customer's machine; browser delivery and related Claude Code attacks were separate tests, not confirmed events on that machine.
- Already ran an agent in a suspect folder? Stop the session and review commands and configuration; moving folders or deleting the file may not undo earlier changes.
Before your next agent session
1. Choose the folder. Start in the specific project the assistant needs, not Downloads or your whole home folder. Keep incoming downloads separate. A project folder is not automatically safe: an untrusted repository can contain instructions too.
2. Review the instructions. Open unfamiliar AGENTS.md, CLAUDE.md and similar files as text yourself before starting the agent. Pause if they ask to install a package, register a tool server or change an API destination. Do not let the same unsandboxed agent investigate by following the file's setup steps.
3. Check permissions. Keep command approvals and sandboxing enabled; do not bypass them just because a setup note says to. Test untrusted projects in an isolated environment without your normal credentials. These are precautions, not a guarantee that a malicious instruction will be caught.
What was found—and what remains unknown
In its 22 October research, Forever Security says it blocked an AI coding agent's attempt to install a malicious npm package and traced the instruction to an AGENTS.md file in a customer's Downloads folder. The company says it stopped the attempt before code ran; this is not evidence of a successful payload on that customer's machine.
AGENTS.md and similar files hold project instructions for coding assistants. Plain text does not execute by itself, but an agent that treats it as trusted guidance may use its own tools to carry out the instructions. In this case, Downloads was also the agent's working directory.
The original delivery method remains unknown. The researchers separately demonstrated browser delivery and attacks against Codex and Claude Code. Those tests show a possible attack path, not proof that every browser visit or downloaded Markdown file compromises a device. BleepingComputer notes that browser download notifications and approval behaviour vary.
Why changing folders is only the first step
In the Codex demonstration, the malicious instructions changed machine-wide agent configuration so an unwanted tool could load in later sessions. The researchers also tested a Claude Code instruction file that redirected API traffic and exposed an authentication token. These are separate test findings, not confirmed outcomes on the original customer's computer.
A narrow workspace reduces exposure, but it is not a complete security boundary. An untrusted repository can contain instruction files too, and moving out of Downloads does not undo configuration changes already made. This differs from the earlier BragJack browser-extension research: the entry point here is a local instruction file trusted by a coding agent.
If the agent already followed a suspicious file
Stop using that session. For a work computer, involve your security team before resuming automation. Have the executed commands and agent configuration reviewed, including newly added tool servers and changed API destinations. In the Codex test, the persistence point was ~/.codex/config.toml; checking only the Downloads folder would miss it.
Revoke exposed tokens and sessions through the official service from a clean device. Deleting the instruction file alone may not remove persistence or invalidate a stolen token. If you cannot establish what ran, get qualified help to assess the device before giving an agent fresh credentials. These are recovery precautions, not a claim that every suspicious file caused a compromise.
Why a VPN is not the fix
A VPN encrypts the connection between your device and the VPN server. It cannot decide which local instruction files deserve trust, reverse a configuration change or stop an authorised agent from sending a token to the wrong destination. Permissions, reviewed instructions and credential recovery address this risk; changing your public IP address does not.
Primary reading
Sources and further reading
We add plain-English context and practical advice. These links let you inspect the underlying reporting, research and official guidance directly.
