A newly demonstrated attack against AI coding agents shows how a routine review of third-party code could end with malicious commands running directly on a developer's computer or continuous integration system.
The proof-of-concept targets automated approval features in Claude Code and Codex CLI, where an AI agent is allowed to inspect files and execute commands it considers safe. By placing carefully written instructions inside an untrusted software project, an attacker may be able to persuade the agent to launch a malicious program during what appears to be an ordinary security review.
The concern is not limited to one suspicious plugin, extension or custom configuration. The reported attack worked against standard installations using their automated operating modes, without requiring additional hooks, skills, MCP servers or specially installed tools.
How a Normal Code Review Can Become an Attack
AI coding agents are increasingly used to inspect open-source packages, search for vulnerabilities, review dependency updates and automate repetitive development work.
To perform these tasks effectively, the agent often needs permission to:
Those permissions are useful when the project is trustworthy. The danger appears when the same access is granted while reviewing code controlled or modified by someone else.
In the demonstrated attack, researchers created a modified copy of a legitimate software library and placed it on a Linux system. They then instructed the coding agent to carry out security testing on that directory.
The agent explored the repository, read its documentation and encountered instructions describing a helper program as part of the security-checking process. It inspected the files, decided that running the program matched the user's original request and executed it.
The program then launched attacker-controlled code on the host.
From the developer's perspective, the agent appeared to be following a reasonable sequence of actions. It was reviewing the project, locating security-related utilities and running something that the documentation claimed was relevant.
Auto-Mode Removes the Final Approval Barrier
The attack becomes possible because auto-mode and auto-review are designed to reduce the number of interruptions during longer tasks.
Without automation, a developer may be asked to approve each shell command before it runs. While this provides an additional checkpoint, it can also become frustrating when an agent needs to execute dozens of routine commands.
Automated modes attempt to solve this by allowing an AI-based classifier to decide whether a proposed command appears safe.
That convenience creates a difficult security problem. The same agent that reads untrusted project content is also involved in deciding what actions should be allowed.
If an attacker can influence the agent's reasoning through documentation, source files or project instructions, the agent may approve a command because it appears consistent with the assigned task.
The attacker does not necessarily need to exploit a traditional memory-corruption bug. Instead, the malicious repository manipulates the agent into using its legitimate command-execution capability against the host.
The Agent Cannot Reliably Separate Code From Instructions
At the heart of the issue is a familiar problem in agentic AI systems: untrusted text can be interpreted as instructions.
A coding agent may read a README file, source-code comment, project guide or agent-specific instruction file as part of understanding the repository. However, an attacker can deliberately write that content to influence what the agent does next.
The agent may struggle to distinguish between:
This is especially dangerous when the agent has access to a shell.
A misleading sentence in a document is no longer only text when an autonomous tool can translate it into an operating-system command.
The Technique Worked Across Multiple Models
The reported proof-of-concept affected stock Claude Code CLI versions 2.1.116 through 2.1.199 when used in auto-mode. It was tested with several Claude model configurations, including Sonnet 4.6, Sonnet 5 and Opus 4.8.
The same technique reportedly worked against Codex CLI 0.142.4 using GPT-5.5 in auto-review mode.
According to the findings, the payload did not need to be rewritten for each model. The same general attack method succeeded across two different coding-agent platforms and several model generations.
That matters because it suggests the problem may not be limited to one faulty model response.
The broader weakness comes from the way the tools combine three capabilities:
Improving the model may reduce the number of successful attacks, but it may not remove the underlying risk as long as those capabilities remain closely connected.
Traditional Static Scanners May Miss the Trap
The malicious helper program used in the test was not called by the library's normal functions.
That meant conventional static analysis could inspect the legitimate code paths without necessarily identifying the hidden execution route. The dangerous action only occurred because the AI agent read the accompanying material and decided to run the separate program.
This creates an unusual attack pattern.
The package may appear harmless when tested normally. The malicious file may remain unused during standard application execution. It only becomes active when an AI coding agent is asked to explore the project and follow the planted instructions.
Researchers also found that asking the models directly whether the repository contained prompt-injection attempts did not always produce a warning.
In some tests, the agent noticed that certain files did not appear to belong to the original upstream project. Despite recognising that something was unusual, it still continued and executed the program.
Project Instruction Files Can Make the Attack Persistent
The same technique can also be placed in files that coding agents treat as project-level guidance.
Examples include files such as:
CLAUDE.md agent.md These files may be loaded automatically or treated as persistent context whenever the agent works inside the repository.
A malicious instruction embedded there may influence multiple future tasks rather than only one review session.
This creates additional risk when developers clone unfamiliar repositories and immediately launch an AI agent inside them. The agent may absorb the attacker's instructions before the developer has reviewed the files manually.
Open-Source Supply Chains Create a Realistic Delivery Path
The attack does not require an attacker to target a developer directly.
One possible route is a malicious or compromised library maintainer adding hidden instructions to a project. Anyone using an AI agent to review that package could then become a target.
A broader threat involves software supply-chain compromise.
An attacker who gains access to a popular repository could add poisoned documentation, scripts or binaries while attempting to make the changes appear legitimate. Automated dependency systems may then pull the modified version into development environments.
A continuous integration workflow could be configured to ask an AI agent to review each new dependency update. In that situation, the developer may never manually open the malicious file.
The agent becomes the first system to inspect it, and the automated review itself becomes the trigger.
CI Runners Could Be Especially Attractive Targets
Continuous integration servers often hold credentials and network access that are far more valuable than those stored on an ordinary development laptop.
A CI runner may be able to reach:
If an AI agent running inside that environment is manipulated into executing attacker-controlled code, the initial compromise may provide access to far more than the project being reviewed.
The proof-of-concept focused on demonstrating that the first stage of code execution was reachable. It did not attempt to add privilege escalation, lateral movement or production-system compromise.
However, once arbitrary code is running, an attacker may begin searching for credentials, configuration files and connected services.
Sandboxing Helps, but It Is Not a Complete Answer
Running AI coding agents inside containers or sandboxes can reduce exposure, but the protection depends heavily on how the environment is configured.
A restricted container becomes less useful if it still has access to:
Once code execution has been achieved, malicious software can inspect whatever resources are available inside the sandbox.
It may also look for configuration weaknesses, attempt to escape the restricted environment or establish persistence through files that survive after the agent session ends.
Isolation therefore needs to be designed around the assumption that the reviewed repository may be actively hostile.
Human Approval Is Also Imperfect
Requiring a user to approve every command is safer than fully automatic execution, but it does not eliminate the risk.
Developers may receive so many prompts that approval becomes routine. After repeatedly accepting harmless commands such as package listings, searches and test runs, the user may approve a dangerous command without examining it carefully.
This is a form of prompt fatigue.
Automation bias can also play a role. Users may assume that the AI agent has already inspected the command and would not recommend it unless it were safe.
The problem becomes more serious when the operator is under time pressure or does not have enough security knowledge to understand what the command will do.
Human-in-the-loop controls are valuable, but they should not be treated as the only protective measure.
What Development Teams Should Change
Organisations using AI coding agents should avoid giving them unrestricted command execution while reviewing untrusted repositories.
Practical safeguards include:
Teams should also separate security analysis from production deployment systems. An agent used to inspect unknown third-party code should not operate from the same environment that can publish releases or deploy applications.
Behavioural Monitoring Could Reveal Suspicious Actions
Credential monitoring alone may not detect this type of attack because the initial warning sign is not necessarily a stolen password.
The more useful signal may be the agent's behaviour.
For example, a monitoring system could flag when an agent:
These activities may indicate that the agent has moved beyond the expected review process.
Monitoring should therefore focus on actions taken by the agent, not only on the text it produces.
Traditional Security Controls Still Matter
AI coding tools can accelerate development, but they should not replace established software-security practices.
Dependency pinning, checksum verification, static analysis, software composition analysis and human review remain important controls when handling third-party code.
Organisations should also maintain an inventory of where AI agents are used and document what each agent can access.
The key questions are straightforward:
Without those answers, organisations may not realise how much access an agent has until something goes wrong.
Final Thoughts
The Claude Code auto-mode exploit highlights a difficult conflict at the centre of autonomous coding tools.
Developers want agents that can independently inspect projects, run tests and complete long tasks without constant interruptions. Yet those same abilities become dangerous when the project being reviewed contains instructions designed to manipulate the agent.
The attack does not depend on a developer knowingly running an obviously suspicious file. The coding agent performs the dangerous action while attempting to fulfil a legitimate security-review request.
That makes the issue particularly relevant to teams using AI for dependency analysis, vulnerability research and automated CI reviews.
Until agent architectures can reliably separate untrusted project content from executable instructions, organisations should treat every unfamiliar repository as potentially hostile. AI coding agents reviewing that material should operate inside isolated environments with minimal credentials, restricted network access and detailed runtime monitoring.
The safest assumption is that any agent capable of reading untrusted code and running shell commands may eventually be persuaded to do something the developer never intended.
Comments