Git Hijack Lets Repos Run Code in Agents

A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, Grok is a September 2026 research post by Manifold Security about a Git trust-boundary problem in AI coding agents. It asks what happens when an agent opens an untrusted repository and runs Git before a human has reviewed the repo’s Git config. The practical answer is calm but firm: Cursor, Anysphere’s AI code editor, should treat unknown repos as unsafe until hidden Git behavior has been checked with cursor rules or an explicit review step. A Git config hijack is a repository-local Git configuration that turns an ordinary Git operation into a code execution path.

The post names Claude Code, Anthropic’s coding agent; Codex, OpenAI’s coding agent; Cursor; and Grok, xAI’s assistant. The interesting part is not that Git can run helpers. Git has had extensibility points for a long time. The interesting part is that agents often run setup and inspection commands on your behalf, so the first dangerous action may happen before you feel like you started working.

Read the flaw as a trust boundary

Manifold’s example centers on .git/config, especially settings such as core.fsmonitor that can cause Git to invoke external code during common commands. In a normal developer workflow, git status feels harmless. In a hostile working tree, it may not be.

That does not mean every clone from a normal hosting service carries the same risk. A remote repository does not usually ship its local .git/config as tracked source. The scarier case is an arbitrary repo directory, archive, reproduction bundle, or copied working tree that already contains a .git directory.

The trap is reviewing only the visible source files. A nice-looking package.json and a boring README.md do not tell you what Git will do when an agent asks for status, diff, submodules, hooks, or repo metadata.

Notice what changed when the caller is an agent

Cursor Agent can inspect a codebase, plan changes, edit files, and help review the result inside the IDE. That is exactly why developers like it. It also means the agent may reach for Git as part of understanding the workspace, not only when you type a Git command yourself.

That is the security delta. A human usually decides when to run git status. An agent might run it while answering a plain request like “look at this repro and tell me why the test fails.”

This is also why the story landed with people who use cursor custom agents, cursor subagents, and terminal agents. The boundary between “read the repo” and “execute repo-controlled behavior” is thinner than it looks. We saw a related version of that boundary in Shed Manages Git for Terminal Agents, where Git state becomes part of the agent’s operating surface.

Take the objection seriously

The strongest pushback is fair: Git config execution is not new, and some writeups can make old Git behavior sound like a brand-new apocalypse. If you already treat arbitrary repos as untrusted code, this may feel like another reminder rather than a novel class of exploit.

But reminders matter when the workflow changes. AI coding agents compress many small developer actions into one instruction, and that compression can hide the moment where trust is granted.

The right lesson is not panic. It is to move “is this repo safe to let tools inspect?” earlier in the workflow, before the agent runs helpful commands. The cheap fix is a visible preflight rule; the expensive mistake is letting the first preflight be a shell command.

Put the boundary where Cursor can see it

Cursor rules are a good place to write durable repo behavior because they sit near the agent workflow instead of living in someone’s memory. If your repo already uses scoped rules or an AGENTS.md file, add a short boundary for unknown repos: no Git inspection commands until .git/config and hooks are reviewed as data.

This is not a sandbox. A rule will not stop every tool call in every environment. It is a steering layer that makes the safe path explicit and reviewable.

For repeat work, this also fits the broader Cursor subagents and skills pattern: keep specialized behavior small, named, and easy to audit. A cursor skill can hold the checklist. A cursor subagent can be told to stay read-only until the preflight passes. If you are organizing these patterns, keep them close to the related training topic rather than scattering one-off prompts across chats.

Copy a small untrusted-repo rule

Use this as a light Cursor artifact, not as a magic shield. It is most useful when you open a repo from a bug report, customer bundle, zip file, benchmark, interview exercise, or unknown fork.

---
description: Preflight for untrusted repositories before agent Git commands
alwaysApply: false
---

When this workspace came from an untrusted source, treat the repository as data until preflight passes.

Before running Git commands such as status, diff, log, submodule update, or config:

- Ask whether the repo is trusted, freshly cloned from a known remote, or an arbitrary working tree.
- Inspect .git/config and .git/hooks as files, not by invoking Git.
- Stop if .git/config contains core.fsmonitor, core.hooksPath, include.path, includeIf, or shell-style aliases.
- Stop if hooks are present and executable, unless the user explicitly approves them.
- Prefer copying source files into a clean repo when the origin is unclear.

After preflight, report what was checked before using Git-backed review or edit workflows.

Concrete next step: save it as .cursor/rules/untrusted-repo-preflight.mdc, then manually attach it the next time you ask Cursor to inspect an unknown reproduction repo. Keep the rule short. Long safety prose gets skipped by humans and blurred by agents.

Common questions

• Is this just a normal Git security problem?

  Yes, partly. Git has long supported config, hooks, helpers, and aliases that can run commands under the right conditions. The agent-specific concern is timing: an AI coding agent may run Git during workspace discovery, before the human has consciously approved the repo as executable code.

• Does Cursor automatically run the dangerous Git command?

  Do not assume one fixed behavior across versions, settings, or workflows. The safe claim is narrower: agentic coding tools commonly use Git commands to inspect repositories, and Manifold’s post argues that this creates a risky path in untrusted working trees. Test your actual Cursor setup before writing hard policy around it.

• Should I disable agents for unknown repos?

  You do not have to disable agents everywhere, but you should start unknown repos in a read-only posture. Inspect .git/config and hooks first, then decide whether to let Cursor Agent, custom agents, or subagents run Git-backed workflows. For high-risk samples, copy source files into a clean directory.

• Do cursor rules make this safe by themselves?

  No. Cursor rules help the agent choose safer actions, but they are not an operating-system sandbox and they do not rewrite Git’s trust model. Use rules as a visible reminder and review contract, then pair them with normal isolation: disposable worktrees, containers, or clean clones when the source is suspicious.

Best ways to use this research

• Best for: Deciding how much trust to grant an AI coding agent before it inspects an unknown repo.
• Best first artifact: A short cursor rules preflight that blocks Git commands until .git/config and hooks are reviewed as files.
• Best comparison angle: Human-run Git commands vs agent-run Git commands; the risk changes when the agent acts before explicit approval.
• Best limitation to remember: This is a trust-boundary control, not a complete sandbox or malware defense.

Further reading

• Cursor — Agent
• Cursor — Rules
• A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, Grok — source

Next step

Before you ask an agent to work inside an unknown repo, inspect .git/config as data and decide whether the workspace deserves Git access. If you use cursor skills or cursor subagents, make that preflight a named habit instead of a vague warning.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.