An AI coding agent is supposed to understand a new project before doing any work. Many tools quietly ask Git about the branch, changes, and files in the background. New security research shows why that seemingly harmless preparation can be dangerous: in several agents, Git context supplied with a project could cause code to run on the computer before a trust prompt appeared. The issue is not the first prompt. It is the invisible infrastructure that runs before it.
Key takeaways
- Several AI coding agents call Git commands to gather context when a project is opened or initialized.
- If a project folder arrives from an unfamiliar source with its Git metadata included, some Git settings can start programs.
- Manifold Security reports affected products, including historical Claude Code cases and variants in Codex and Cursor that have since been patched.
- The practical defense is simple but important: inspect unfamiliar project folders in isolation and run AI agents with minimal privileges.
Why an agent startup does more than it shows
A coding agent does not work like a plain text search tool. To review changes or plan a task, it gathers context: which branch is active, which files changed, and whether there are local edits. Commands such as git status and git diff are an obvious way to do that. Manifold Security’s new report describes several command-line agents that make such calls as early as startup. That is convenient because the agent becomes oriented immediately. It also means the environment matters before the first visible work step.
Git is not only a program for comparing text files. It reads configuration and can invoke helper programs for certain features. One intended feature is core.fsmonitor, which helps large projects identify changed files faster. If a Git configuration points to an external program, a Git call that refreshes its index can start that program. This is not an exotic flaw in Git itself. It is an intended capability that becomes dangerous at the wrong point in an untrusted environment.
According to the research, the critical case is not ordinary cloning from a URL. The issue is a project folder that already includes its .git metadata, such as one delivered in a ZIP archive, a synced folder, a USB drive, or a shared file location. Opening such a directory in an agent means trusting more than the visible source code. It also means inheriting the state Git has stored for that project. That distinction is easy to miss in everyday work.
Not a single-vendor mistake
Manifold names Claude Code, Goose, Qwen Code, Grok Build, and Hermes for the examined bug class. In an update dated September 1, the firm said Codex and Cursor had also been affected, but that the respective variants had been patched. For Claude Code, the report identifies a fix for the described startup path beginning with version 2.1.196. It also describes other, in some cases still open, issues in other tools. The important conclusion is therefore not that one assistant is inherently unsafe. It is that many agents depend on the same ordinary developer tools for context gathering and can overlook the same trust boundary.
The pattern appears beyond Git. In August, GitLab published a critical vulnerability in the Serena MCP server. A malicious project file could lead to code execution when a repository was opened, even though Serena included a trust check. The Cloud Security Alliance had earlier highlighted comparable risks when coding assistants load project-bound MCP configuration before verification. In every case, the central question is the same: does the tool treat files from an unfamiliar project as data, or does it execute them as configuration?
This matters especially because coding agents often run with the privileges of their users. A compromised process might not only see the current folder, but could potentially reach SSH keys, cloud credentials, tokens in the shell environment, or other local projects. That is unpleasant for an individual developer. For teams with production access, it can become a serious supply-chain problem. OpenAI’s recent classification of critical cyber capability in Astra concerns a different layer, but it points in the same direction: agents need more than clever answers. Their tools must be reliably constrained.
What developers should actually do now
The key rule is to treat an unfamiliar project folder like unfamiliar executable content. If a ZIP archive or folder arrives with an existing .git directory, do not open it directly in a privileged agent. First inspect it on an isolated machine or in a restricted container, check its origin, and review the Git configuration it contains. This is not a call to distrust every open-source dependency. It is a sensible order of operations: verify origin and metadata, then work with as few permissions as possible.
Updates matter just as much. Publicly documented fixes help only when the installed version is actually current. Teams should include agents, editor extensions, and MCP servers in their normal patch routine instead of treating them as harmless productivity aids. If a suspicious project has already been opened, it makes sense to assess any tokens and keys in scope and, if necessary, renew them from a clean environment. Simply deleting the project folder does not answer whether something ran with the available privileges.
Professional environments need additional technical boundaries: separate accounts or containers for experiments, no long-lived credentials in the agent process, restricted network access, and explicit approval for new MCP servers. In CI systems, agents should not process untrusted pull requests while holding broadly useful secrets. A confirmation dialog is not enough if background processes have already started. Trust must apply before execution, not only at a visible prompt.
Outlook: Agent security starts in the engine room
AI security debates often focus on prompt injection, model capability, or the quality of generated code. These cases are a reminder of a less glamorous layer: processes, configuration files, and standard commands. An agent can be cautious in its wording and still create risk if its startup procedure trusts unfamiliar metadata too much.
The good news is that much of this problem can be described clearly in technical terms. Vendors can isolate Git calls so local project configuration cannot start helper programs. Organizations can separate execution, permissions, and networks more effectively. Users can inspect unfamiliar directories first. As coding agents become more autonomous, security must depend less on an invisible startup step happening to be harmless.