The mental model most developers have of a coding agent is that it sits there inertly until you ask it something. Datadog Security Labs has shown that trusting a repository is itself the action.

Their finding: repository-controlled code can run before you send the first prompt.

Two paths, both without a prompt

Codex. Project-scoped Model Context Protocol configurations cause Codex to start an attacker-controlled process. The MCP config lives in the repository; opening the project starts what it names.

Claude Code. A project-controlled PATH caused Claude's own automatic Git probes to run a wrapper tracked in the repository. Claude runs Git to orient itself in a new project — entirely reasonable behaviour — and the project got to decide which binary "git" resolves to.

The second is the more elegant of the two, because nothing malicious is invoked. The agent does exactly what it was designed to do, and the repository has quietly redefined what that means.

Datadog is explicit that neither path needed a model response or a shell command approval. There is no trick required to make the user interact, and no need to call the MCP server. Open the project, and it executes.

Why the approval prompt doesn't help

Agent security has largely been built around a single control: the agent proposes a command, the human approves it. That control assumes the dangerous moment comes after the model produces output.

Here it comes before. The execution happens during project initialisation — while the agent is reading configuration, resolving tools and orienting itself — which is upstream of everything the approval flow governs.

It is worth being precise: this is not prompt injection. Nobody manipulated the model. The model was not consulted.

The surface is larger than two files

The specific issues can be patched. The shape of the problem is what generalises, and Datadog lists the places a project can influence what runs:

  • hooks
  • skills
  • MCP servers
  • editor tasks
  • development-container settings
  • environment variables
  • runtime startup files
  • ordinary repository executables

Their summary is the line worth keeping: an attacker only needs one hiding place, but a reviewer has to find them all.

That asymmetry is the whole problem. Reviewing a dependency for malicious code is hard but bounded. Reviewing a repository for anything that could influence agent startup means checking eight categories of configuration, several of which most developers have never audited and some of which they may not know exist.

Where this actually bites

The realistic scenarios are ordinary ones.

Reviewing a pull request from outside your organisation. Checking out a contributor's branch and opening it in an agent is routine, and the branch controls all eight surfaces.

Cloning something to evaluate it. Assessing an open-source project by opening it is the normal way to assess it.

Contract or agency work. Client repositories are opened by people who did not write them and are not resourced to audit their tooling configuration.

In each case the developer has done nothing careless. They opened a folder, which is the action the tool exists to perform.

What follows from it

  • Treat "trust this project" as executing it. The dialog reads like a preference. It functions as consent to run whatever the repository has configured.
  • Open unfamiliar repositories somewhere disposable. A container or VM, not the machine holding your cloud credentials and SSH keys. This is the only control that survives the eight-surface problem.
  • Look at MCP configuration and PATH-affecting files as part of review — the two demonstrated paths. Not sufficient, but the highest-yield check.
  • Keep agents out of environments they don't need. An agent on a machine with production credentials is a much worse outcome than the same agent on a machine without them.

The pattern with the CI flaws we covered last week

Both come from the same place. Novee's finding was that one component marked a value safe while another acted on it with more authority. Datadog's is that the dangerous action happens before the component doing the checking gets involved at all.

Neither is a coding error in the usual sense. Both are consequences of putting a system that reads untrusted text and decides what to do into a position with real permissions — and then trying to bolt a boundary onto it afterwards.

The approval prompt is a good control for the thing it governs. It just governs less than people think.