Can A Malicious Git Folder Make Codex, Claude, And Grok Run Code Before Approval?

September 5, 2026

A copied Git folder can make AI coding agents run code before approval. Learn the affected tools, clone exception, fixes, and FOLDER safety check.

An AI coding agent can run attacker-controlled code before showing a trust or command-approval prompt if you open a received project folder that still contains a malicious local .git configuration. A normal git clone does not copy that configuration. OpenAI has patched three related Codex paths, but researchers reported comparable paths across Claude Code, Grok Build, Qwen Code, Hermes Agent, goose, and Cursor.

Research cutoff: September 4, 2026 (America/Chicago). Product versions can change quickly; check the vendor's current release and security notes before relying on a version number below.

Who This Is For

This guide is for developers, consultants, security teams, and anyone who opens project folders in an AI coding agent. It is especially relevant when a repository arrives as a ZIP file, shared drive folder, synced directory, backup, customer handoff, or USB copy instead of through a fresh clone from a trusted remote.

The key question is not whether the code in the working tree looks suspicious. The dangerous setting can live inside .git/config, a local file that many reviews ignore because it is not normally committed or shown in a pull request.

What Is Confirmed

Manifold Security's GitSpawn disclosure documents eight findings across seven AI coding agents. The researchers found that several products automatically ran ordinary Git commands to collect branch, status, or diff context. Those Git subprocesses inherited repository-local configuration, allowing a setting that names a helper program to launch code on the developer's machine.

The confirmed boundary failure is unusually important:

The code can run outside the coding agent's command sandbox.
The agent's normal tool-approval flow may never see the subprocess.
In some tested products, execution occurred before a workspace-trust prompt, before authentication, or before the first message was sent.
The payload runs with the privileges and environment available to the signed-in user.
An ordinary clone is not enough. The malicious repository-local configuration must arrive intact.

OpenAI's CVE records describe three distinct Codex mechanisms. CVE-2026-19590 covers a repository-controlled hooks path in Codex Desktop. CVE-2026-19592 covers the core.fsmonitor helper used by Codex CLI and Desktop. CVE-2026-19593 covers a Desktop path involving attr.tree and a configured clean or process filter.

OpenAI's public Codex fix for the filesystem-monitor path makes metadata reads independent of repository core.fsmonitor configuration and includes regression coverage proving that the helper is not invoked while Codex still detects working-tree changes.

The same general weakness was not unique to Codex. The reviewed goose security advisory says goose review could run a repository's core.fsmonitor helper before the model was contacted. The advisory rates the issue High and says versions before 1.44.0 are affected.

Why A Normal Git Clone Is Different

A standard clone creates a new local .git/config. It does not copy the source repository's local configuration file. That is why this is not a claim that clicking any GitHub link or cloning any public repository automatically compromises a machine.

The risk appears when the project arrives as a complete directory with its .git metadata preserved. Common examples include:

a ZIP archive made from an existing working copy;
a customer or colleague's shared folder;
a cloud-drive or file-sync copy;
a restored developer backup;
a copied virtual-machine or container volume; or
removable media containing the whole workspace.

That distinction should be prominent in every warning. Calling this a universal malicious-repository exploit would overstate the evidence. It is a preserved-local-configuration exploit path.

How Ordinary Git Plumbing Became Code Execution

AI coding agents frequently want immediate project context. They may ask Git for the active branch, changed files, a diff, or worktree state before the user requests an action. Those are reasonable product behaviors.

Git configuration can also name executable helpers. The current Git configuration documentation explains that core.fsmonitor may contain the pathname of an external filesystem-monitor command, and that core.hooksPath changes where Git looks for hooks. Git's attributes documentation describes clean and process filters that can launch programs while Git transforms content.

The vulnerability emerges from the combination:

A received folder contains attacker-controlled repository-local Git configuration.
The coding agent starts and gathers project context automatically.
Its background Git command permits the local execution-capable setting.
Git launches the named helper with the user's privileges.
The agent's approval and sandbox UI never mediates that subprocess.

This is a product integration flaw, not evidence that Git itself has been compromised and not proof that the language model chose to run malware.

Which Products Were Affected?

The status differed by product at the disclosure cutoff.

Codex CLI and Codex Desktop: OpenAI published CVE records and fixes. The reporting reviewed by The Hacker News lists Codex CLI 0.102.0 through 0.130.0 as affected by the core.fsmonitor path and 0.131.0 as fixed. It also lists fixed Desktop builds for macOS and Windows.
goose: the reviewed advisory lists versions before 1.44.0 as affected and 1.44.0 as patched.
Claude Code: Manifold says the core.fsmonitor path was fixed in 2.1.196. A separate ultrareview path using a different withheld Git setting was still reproducible in 2.1.252 on September 1.
Qwen Code: Manifold says the issue remained reproducible in 0.22.3 on September 1.
Grok Build: Manifold says the issue remained reproducible in 1.0.13 on September 1.
Hermes Agent: Manifold says the issue remained reproducible in 0.21.0 on September 1.
Cursor: Manifold says the related path was patched.

These are disclosure-time observations, not permanent labels. A product described as unpatched on September 1 may have shipped a fix after the research cutoff. Conversely, updating one product does not update every other agent installed on the same machine.

What Is Still Unclear

No reviewed source in this research establishes that attackers exploited these GitSpawn paths against real users. The affected-user count is also unknown.

Several details remain product-specific or undisclosed:

Manifold deliberately withheld the exact setting used by the still-open Claude ultrareview path.
Public reporting does not provide one complete version matrix for every platform, package channel, and agent.
A fixed startup path does not prove that every review, worktree, nested-repository, extension, or plugin path applies the same Git configuration sanitization.
The disclosures do not show that the models themselves understood, selected, or approved the hidden command.
The reports do not establish that a clean-looking working tree is safe when the local Git metadata came from someone else.

Absence of known exploitation is not proof that exploitation never occurred. It means the current public evidence supports a serious vulnerability and practical mitigation, not a claim of a confirmed breach campaign.

Use The FOLDER Safety Check

Before opening a received workspace in any coding agent, use the FOLDER check.

F — Find Out How The Folder Arrived

Was it freshly cloned from a trusted remote, or copied with .git intact? Treat archives, shared drives, backups, and customer handoffs as the higher-risk path.

O — Open Metadata As Text, Not Through Git

Inspect .git/config with a plain text viewer before running git status, git diff, an IDE, or an agent in that folder. On Windows PowerShell, a direct file read can look like this:

Get-Content -LiteralPath .git\config

On macOS or Linux, use a plain file viewer that does not invoke Git. If .git is a file rather than a directory, read that file first to understand where it points.

L — Look For Execution-Capable Settings

Investigate unexpected core.fsmonitor, core.hooksPath, filter commands, include paths, aliases, or other settings that name programs or external files. Do not assume this short list covers every possible Git execution sink.

D — Determine Every Installed Agent's Version

Inventory Codex, Claude Code, goose, Qwen Code, Grok Build, Hermes, Cursor, and any other tool that automatically inspects repositories. Compare each version with its vendor's current security guidance.

E — Establish A Disposable Inspection Boundary

For an untrusted handoff, inspect or reconstruct it in a disposable virtual machine or other isolated environment without production credentials, SSH keys, cloud tokens, browser sessions, or writable sensitive mounts. A container is not automatically sufficient if it inherits powerful host mounts or sockets.

R — Recreate The Repository From Trusted Content

When practical, start with a fresh clone from a trusted remote and copy only the working-tree files you need after review. Do not carry the received .git directory into the new workspace. Verify that branches, ignored files, submodules, Git LFS content, and uncommitted work are handled intentionally rather than blindly copied.

If You Already Opened A Suspicious Folder

Do not assume that closing the agent reverses code that may already have run.

Disconnect the affected machine from sensitive networks if compromise is plausible.
Preserve relevant logs and the suspicious folder for authorized investigation.
Review process, endpoint, shell, Git, and agent telemetry around the first open time.
Rotate credentials that were available to the process, prioritizing SSH keys, cloud credentials, package tokens, model-provider keys, and source-control sessions.
Check persistence locations, startup items, scheduled tasks, shell profiles, authorized keys, developer-tool configuration, and CI/CD secrets.
Rebuild from a trusted image when the evidence cannot establish system integrity.

Credential rotation should happen from a known-clean device. If this concerns an employer or client environment, follow its incident-response process rather than improvising on the possibly affected host.

What This Does Not Mean

GitSpawn does not prove that every AI coding agent is currently vulnerable. It does not mean normal Git clones preserve the malicious local configuration. It does not show that a model ignored a visible approval request, because the vulnerable background process could run before the model and approval layer were involved.

It also does not prove that chatbots without local filesystem or shell authority share this specific risk. The transferable lesson is narrower: an agent's surrounding application, repository tooling, plugins, hooks, extensions, and operating-system privileges are part of the security boundary even when the model never issues a tool call.

Where OpenVeil Fits

OpenVeil is a hosted, privacy-focused AI chat workspace for adults who want browser-local normal chat history and no normal server-side chat-history record. It can be a better fit when you need conversational help, web search, uploads, voice, or image tools but do not need a local coding agent to inspect repositories and execute commands on your workstation.

OpenVeil is not a coding-agent sandbox, Git scanner, endpoint-security product, credential vault, or incident-response service. It does not patch Codex, Claude Code, Grok Build, Qwen Code, or another local tool. Active OpenVeil requests and uploads are still processed by OpenVeil and necessary providers, and browser-local history does not protect secrets you deliberately place in a prompt or file.

For more on adjacent trust boundaries, read how a malicious issue can hijack coding-agent workflows, the patched Amazon Kiro workspace injection path, and why agent-installed packages need independent verification.

Frequently Asked Questions

Can A Normal `git clone` Carry The Malicious `.git/config`?

Not through the path described here. Git creates a new local configuration during a normal clone instead of copying the source repository's .git/config. Other malicious repository content can still create different risks, so a fresh clone is not a universal security guarantee.

Is A Workspace-Trust Prompt Enough?

Not for a vulnerable path that executes before the prompt appears or before the user accepts it. Trust UI only protects operations that are actually routed through that control.

Is The Model Responsible For Running The Command?

The documented GitSpawn paths can execute during application startup or context collection before a model call. The vulnerable behavior is in the surrounding agent application and its Git subprocess handling.

Does A Sandbox Stop This Attack?

The disclosed paths ran outside the agents' normal command sandboxes. Broader operating-system isolation may still limit damage if it is correctly configured and does not expose host credentials, mounts, sockets, or sensitive network access.

Should I Disable Git Filesystem Monitoring Globally?

That may reduce one execution path, but it can affect performance and does not address every disclosed mechanism. Updating affected products, inspecting preserved local configuration, and using isolated review environments are stronger layered controls.

What Is The Safest Way To Review A Received Project?

Treat it as untrusted input. Inspect its metadata without invoking Git, use a disposable environment without valuable credentials, update every agent involved, and rebuild the workspace from a trusted clone or reviewed files before opening it in a privileged developer tool.

The Bottom Line

A folder can be more dangerous than its visible source files. If a project arrives with .git intact, an AI coding agent may trigger repository-controlled helpers while gathering context, before its normal trust and approval controls participate. OpenAI and other vendors have patched several paths, but disclosure-time gaps remained across multiple products.

The durable defense is not panic about every repository. It is a repeatable boundary: identify copied workspaces, inspect local Git metadata as plain text, update every agent, remove valuable credentials from review environments, and prove that background tooling cannot execute repository-supplied configuration before trust is established.

Sources

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.