claude-code
Untrusted Git config can run code in Claude Code
Claude News
claude-codeManifold researchers found that Git configuration embedded in an untrusted repository can cause host-side command execution in five named CLI AI agents, including Claude Code, before an approval prompt, outside the agent sandbox, and with the local user’s privileges when they perform routine context gathering.
At a glance
- At startup or once a session begins, the affected tools use Git to learn a project’s branch and changes, and may also list tracked paths, changed files, or worktrees for sub-agents.
- Commands such as git status --porcelain=2 --branch and git diff --name-only HEAD can refresh Git’s index, where core.fsmonitor instructs Git to run a helper that reports changes rather than checking every file on disk.
- Neither cloning a hostile URL nor fetch or pull transports the setting, but an archive, shared drive, sync folder, or USB stick can carry a directory whose .git folder is already present.
The finding puts an ordinary source-control lookup on a boundary that is normally treated as an internal part of an agent’s workflow. It appears to turn configuration held alongside source files into a host process before the product’s approval layer can consider the operation, and it may make the way a team receives a project as consequential as the code inside it.
Git index refresh can call a helper set in .git/config
Manifold gives two examples of Git calls from different products: git status --porcelain=2 --branch and git diff --name-only HEAD. Both are ordinary commands for checking a repository’s state. Git commands that touch a working tree commonly refresh the index before they complete. The report identifies that refresh as the execution sink.
Core.fsmonitor is a performance setting intended for large repositories. Instead of checking every file itself, Git can ask a helper program what changed while it refreshes the index. Git reads the setting from the repository’s own .git/config, where it can name the helper command. The report describes this Git behavior as documented and intended.
A project directory with .git is required for delivery
The configuration is not carried by Git when a hostile remote is cloned. Fetch and pull also do not transport it. The project must instead arrive as a directory that already contains .git; merely receiving a remote URL is not enough to trigger the behavior. That distinction limits the reported delivery path to transfers of an existing project directory.
The report identifies shared drives, sync folders, and USB sticks as other ways a directory can move without the repository being cloned. Once an agent launches Git as a subprocess, Git runs the configured command on the host. The execution occurs with the user’s privileges, outside the sandbox and before an approval prompt, so the permission model does not see it.
The report names Claude Code, Goose, Grok Build, Hermes, and Qwen Code
The five named products are Claude Code, Goose, Grok Build, Hermes, and Qwen Code. Their Git calls differ in purpose and timing. Some occur when the agent opens a project, while others run after a session begins. The tools may inspect the current branch or determine which files were modified or staged.
The report also describes requests for paths tracked by a repository, files touched by a change, and new worktrees for sub-agents. It says core.fsmonitor is not the only Git setting that can act as a command-execution sink. One finding uses a different configuration mechanism. For the described pattern, the particular Git command an agent selects does not determine the issue.
Archive-based delivery For every proof of concept described in the research, the investigators used a .zip archive that contained the project directory and its .git directory. The post names archives alongside shared storage, sync folders, and removable drives as routes for transferring an existing directory rather than obtaining its contents through normal Git cloning from a remote server.
Comments
No comments yet. Be the first.
Join the conversation
Sign in with Google to leave a comment. Your name and avatar come from your Google profile, and the comment appears after moderation.
We only use your name and avatar from Google. We never store your email address.
