The git command nobody noticed
A September disclosure about malicious repository configuration is a useful reminder for every software team adopting coding agents: the dangerous moment is not only when an AI proposes a shell command. It can also be when the agent quietly gathers context before a human has even typed a prompt. Manifold Security described a class of issues it calls GitSpawn, in which command-line coding agents run ordinary Git commands such as git status or git diff to understand a repository. Those calls look read-only, familiar, and safe. But Git has configuration keys that can name programs to execute during an index refresh. If a repository arrives as a directory with its own .git/config intact, that local configuration can cause Git to run attacker-chosen code on the developer’s machine.
This is exactly the sort of failure that matters to practical AI-assisted development. It is not a hallucination in a generated function. It is not a prompt that visibly asks for permission to delete a file. It is not even, primarily, a new machine-learning problem. It is old developer plumbing meeting new autonomous behavior. Coding agents are useful because they inspect projects, call tools, modify files, run tests, prepare pull requests, and sometimes do that work with little supervision. The same usefulness means they exercise more of the workstation’s authority. When they inherit unsafe assumptions from traditional tooling, they can turn a quiet convenience into an execution path.
For Paye ta com and for any team using AI to accelerate software delivery, the conclusion is clear: human control cannot be limited to reviewing the final diff. The human in command must also govern inputs, tool permissions, repository intake, and the invisible context-gathering steps that happen before the model starts writing code. If the agent is allowed to act inside the developer environment, the environment itself becomes part of the security boundary.
Why the finding is timely
The disclosure landed in a week when coding agents were moving deeper into ordinary workflows. GitHub’s September updates describe Jira issues becoming shared canvases that Copilot can carry into investigation, implementation, and pull request preparation. The same update mentions recurring agent tasks in Visual Studio Code and centrally managed sandbox behavior for Copilot in JetBrains. In other words, agents are no longer experimental chat windows on the side. They are being wired into issue trackers, IDEs, terminals, scheduled automations, and enterprise policy settings.
That adoption is positive when teams understand the control plane. A well configured agent can reduce repetitive work, make tests cheaper to run, and help developers explore unfamiliar code. But the GitSpawn story shows why autonomy must be calibrated against the whole execution chain. A coding agent does not merely “think” about a repository. It asks the file system questions. It invokes Git. It reads configuration. It may start a subprocess before a trust dialog appears or before the developer notices that anything has happened. The more natural the workflow feels, the easier it is to forget that many small actions are occurring on behalf of the user.
What GitSpawn teaches about trust boundaries
The essential mechanism is simple. Git’s core.fsmonitor option is a performance feature. It can tell Git to ask a helper program which files changed, rather than scanning everything. That helper runs during operations that refresh the index, including commands agents commonly use to understand repository state. Git reads the setting from the repository’s own local configuration. If a hostile repository is transferred as files with the .git directory preserved, its local configuration can include a command where a developer expects only metadata.
Manifold emphasized an important nuance: a normal clone does not carry the source repository’s local .git/config. The risky path is the handoff that preserves the directory as a directory: a zip file, a shared drive, a synced folder, a USB stick, or a contractor delivery copied wholesale. That is common in real work. Agencies receive archives from clients. Freelancers receive old projects as folders. Support teams reproduce bugs from customer-provided workspaces. Internal teams pass prototypes around. AI agents make those situations more tempting because the developer can say, “open this folder and explain it,” instead of manually inspecting it first.
The trust boundary is therefore not “before the model executes a command.” It is earlier: before untrusted project material is allowed to influence any tool the agent runs. A human reviewer who waits for the agent’s proposed command list may never see the dangerous call, because the call was not proposed by the model. It was performed by the agent harness, IDE extension, or CLI wrapper as context gathering. That distinction matters for governance. Approval prompts for model-generated shell commands are useful, but they do not protect subprocesses that the product itself launches outside that approval path.
The human role moves upstream
This is where the human-in-the-loop slogan must become more precise. In agentic development, the human is not only a code reviewer. The human is also an intake controller, risk classifier, permission designer, and evidence judge. Before an agent touches a repository, someone should ask where the repository came from, whether its local configuration is trustworthy, whether it should be opened in a disposable environment, and which credentials are reachable from that environment. These questions sound operational rather than creative, but they decide whether the agent’s speed is safe enough to use.
A practical policy can be simple. Repositories cloned from known remotes can follow the normal development path. Repositories received as archives or copied directories should be treated as untrusted until inspected. If they include a .git directory, the team can remove it, inspect .git/config, or re-import the files into a fresh repository. Developers can check for risky settings such as core.fsmonitor before opening the folder with an agent. Security teams can provide wrapper scripts or containers for untrusted workspaces. Vendors can sanitize Git calls by disabling dangerous configuration on background invocations.
None of this requires fear of AI. It requires the same discipline that mature teams already apply to production deployments, secrets, dependency updates, and customer data. The difference is that AI agents compress time. A human who might have spent twenty minutes exploring a folder can now ask an agent to summarize it in seconds. That speed is useful only if the first seconds do not hand attacker-controlled configuration to a privileged process.
Sandboxing is necessary, not sufficient
Many organizations hear “agent” and immediately ask whether it runs in a sandbox. They are right to ask. Sandboxes, containers, permission prompts, and network controls are essential. But the GitSpawn disclosure demonstrates that teams must understand what the sandbox actually covers. If an agent product gathers context by running a host subprocess outside the model’s tool sandbox, then the user-facing sandbox story may not cover the earliest and most important action. A permission model is only as strong as the paths that actually pass through it.
This is a common pattern in security. Controls are designed around the obvious dangerous operation, while attackers search for the boring operation that occurs before the control starts. In coding agents, the obvious dangerous operation is “the model asked to run this command.” The boring operation is “the agent checked repository status.” A strong governance model treats both as security-relevant. It asks vendors where context is gathered, which commands are run automatically, whether repository configuration is sanitized, what happens before workspace trust is accepted, and how those events are logged.
For developers, the immediate habit is to separate untrusted analysis from trusted work. Open unknown archives in a disposable container or virtual machine, without SSH keys, cloud tokens, production environment variables, or access to private repositories. Give the agent only the minimum workspace and permissions needed to answer the question. If the task is merely to inspect code, it should not need access to package publishing credentials, customer data, or the developer’s full home directory. Human command is often implemented as boring isolation.
Reviewing code is not enough
Traditional code review focuses on the artifact that will be merged. That remains necessary, but agent-assisted development adds artifacts around the code: prompts, plans, tool logs, execution traces, test evidence, configuration files, and provenance of the input repository. A change may be correct while the route taken to produce it was unsafe. Conversely, a repository may contain no malicious source files while its local tool configuration is dangerous. If the team reviews only the final diff, it misses the operational story.
A better review packet for agent work includes a short statement of source and environment. Where did the input come from? Was it cloned, generated, or received as an archive? Did the agent run in the main developer account or an isolated workspace? Which external tools were allowed? Which tests and scans created evidence? Were any commands executed before explicit human approval? The goal is not bureaucracy. The goal is to make the invisible steps visible enough that a human can reason about them.
A practical checklist for teams
- Classify the source. Treat copied repositories, zip files, shared-drive folders, and vendor handoffs as untrusted until checked.
- Prefer fresh clones. When possible, clone from a known remote rather than opening a preserved
.gitdirectory from an archive. - Inspect local Git configuration. Look at
.git/configbefore using an agent on received folders, especially for settings that name external commands. - Use isolation for unknown workspaces. Run agents in containers or virtual machines without production secrets, SSH keys, or broad home-directory access.
- Update agent tools quickly. Security fixes for agent harnesses, IDE extensions, and CLIs matter as much as model upgrades.
- Ask vendors specific questions. Which subprocesses run automatically? Are Git calls sanitized? What happens before trust prompts? What is logged?
- Preserve human gates for authority changes. Installing dependencies, publishing packages, deploying, changing credentials, or widening sandbox permissions should remain explicit decisions.
The real lesson: govern the workflow, not just the output
The GitSpawn disclosure is valuable because it cuts through a comforting myth. The myth says the human is safe if they review whatever the AI writes. The reality is broader. A coding agent participates in a workflow that includes files, configuration, credentials, shells, network access, issue trackers, test systems, and deployment gates. The output matters, but the path to the output can carry risk too.
Keeping a human in command therefore means designing the workflow so the human can command the right things: provenance, environment, permissions, evidence, and release authority. AI can still accelerate development. It can still summarize unfamiliar code, draft patches, write tests, and prepare pull requests. But it should do that inside boundaries chosen by people who understand the business risk and the technical attack surface.
For Paye ta com, the message to clients is pragmatic. We should use AI where it increases speed and quality, but not by pretending that automation removes responsibility. The stronger promise is different: we combine AI assistance with human judgment, controlled environments, verifiable sources, and explicit review. The best teams in 2026 will not be the ones that let agents do everything. They will be the ones that know exactly where agents may act, where humans must decide, and where a quiet command like git status deserves more respect than it used to.
Sources: Manifold Security, GitSpawn disclosure; The Hacker News summary; GitHub Copilot weekly releases, September 7.
