Workspace trust, and what a repo can make an agent do
Which files run once you trust a folder, and how does prompt injection steer an agent? We read five tools’ docs and two attacks.
Summary. A repository reaches a coding agent in two ways: through files that run code (hooks, tasks, MCP servers, git config) and through text that steers the agent (rules files, pull request descriptions, comments). On 20 October 2026 we read the documentation of Claude Code, OpenAI’s Codex, GitHub Copilot (CLI and VS Code), Cursor and Google’s Antigravity CLI, the primary sources on two attacks from August and September, and two studies.
- The trust prompt decides whether the repository’s files run. All five tools have one; in Cursor’s editor it is off by default. Trust is given to a folder once. The npm worm in August also committed its hooks to repositories’ branches, so that they would run on the machine of the next developer to open the repository.
- In CI, the trust prompt never appears. Claude Code’s
-pmode uses the hooks in the repository’s settings file; Copilot CLI doesn’t load them in an untrusted folder, and Cursor CLI stops. In Gemini CLI, the vulnerability through which non-interactive mode trusted the folder automatically (CVSS 10.0) was fixed in April. - No trust prompt filters the text that steers the agent. In the PRWeaver study, AI review agents caught 50%–60% of hidden attacks when pull requests were reviewed one by one, and at most 22% when 24 pull requests were reviewed together.
- Against text, you have two things: where the rules are read from and what the agent may do. If the rules are read from the pull request’s branch, review a change to the rules file like code. In CI, don’t let the agent load the project’s configuration, give the job read-only permissions, and keep secrets out of the environment.
What is workspace trust, and what does trusting a folder turn on?
In the hooks post we covered the commands an agent runs on its own, in the MCP security post the servers added to a repository, and in the sandbox post what limits the agent’s commands. This post looks at the question all three share: when you open a repository with a coding agent, what can the repository make the agent do? The short answer:
Workspace trust is there for the first path. The first time you open a folder, the tool asks whether you trust it, and until you do, it leaves part of the repository’s configuration unloaded. According to VS Code’s documentation, the aim is to prevent code from running automatically; that is why Restricted Mode disables or limits agents, the terminal, tasks, debugging, workspace settings and extensions. Here is what stays off in the five tools until you trust the folder:
| Tool | Trust prompt | Off until you trust | Where the decision is stored |
|---|---|---|---|
| Claude Code | In an interactive session, at startup in a folder you haven’t trusted; never in -p or the SDK | The project’s allow rules and additional directories, subagents’ hooks, plugins from the repository; .mcp.json servers get a prompt of their own | ~/.claude.json, for the repository root |
| Codex | At startup or with /permissions, depending on your setup | The project’s .codex/ layer: config, hooks, rules. It may start read-only until you trust | ~/.codex/config.toml, trust_level |
| GitHub Copilot | The CLI asks at startup; VS Code opens a folder it doesn’t know in Restricted Mode without asking | In the CLI, the repository’s hooks, MCP servers and plugin settings; in VS Code, agents, tasks, the terminal and debugging | In the CLI, ~/.copilot/config.json; in VS Code, the Workspace Trust list |
| Cursor | Off by default in the editor; the CLI asks at startup | Project hooks (.cursor/hooks.json), and in the CLI the setup commands in worktrees.json; MCP connections need their own approval | Not stated in the documentation |
| Antigravity CLI | At first launch, before the agent starts indexing files | Not stated in the documentation; according to the release notes, .agents/hooks.json loads after you trust the folder | Not stated in the documentation |
Source: the tools’ documentation and release notes, 20 October 2026. “Not stated in the documentation”: in the pages we read that day, we found no sentence that describes this. In Gemini CLI, the decision is stored in ~/.gemini/trustedFolders.json.
The tools share one thing: trust is given to the folder, not to what is in it. Claude Code ties trust to the repository root, and it covers the whole repository. In Copilot CLI, once you trust a folder for future sessions, the prompt doesn’t come back; Gemini CLI also asks only once per folder. So a hook that arrives later in a repository you trust can run without a new prompt. The npm worm below used exactly this path.
In VS Code, trusting a parent folder means trusting every folder under it. The documentation suggests this as a layout: keep the repositories you trust in one folder and the ones you don’t know in another, and trust only the first. If you start Claude Code directly in your home directory, trust is held for that session only and not written to disk.
For Gemini CLI, two sources say different things. The Trusted Folders page (updated on 23 April) says the feature is off by default; the v0.59.0 release notes (8 September) say the trust policy was made “fail-closed”. Check the security.folderTrust.enabled setting in your own installation. On 18 June 2026, Google stopped serving Gemini CLI to free users and to Google AI Pro and Ultra subscribers and pointed them to Antigravity CLI; with a paid API key you can keep using Gemini CLI.
Which files let a repository run code?
When a coding agent opens a folder, several files can run code on their own. Most of them enter the repository by commit and show up in the pull request’s diff. One never shows up in any diff:
More than one tool can read the same file: Copilot CLI also reads the repository’s .claude/settings.json, and Cursor CLI merges Claude Code’s hooks with its own. We covered hooks in detail in the hooks post and MCP files in the MCP post. Here we look at how attackers use these files; both examples are from August and September.
According to Aikido’s report, on 4 August attackers took over the GitHub account of the maintainer of the keyv library and put a credential-stealing worm into the packages. By the next day, at least 444 packages and 1,381 versions were affected. If the worm found a GitHub App token among the credentials it stole, it committed to the repositories it could reach, up to 50 branches per repository. These commits added hooks to .claude/settings.json and .vscode/tasks.json; their author was claude and their message chore: update config.
According to Elastic Security Labs’ analysis, what was added for Claude Code was a SessionStart hook that runs on every new session, and what was added for VS Code was a folderOpen task that runs when the folder opens. Elastic’s conclusion: opening the repository is enough for a developer to be infected. According to Aikido, not even npm install was needed.
The trust prompt may not come into play here at all: trust is given to a folder once, while the new hook arrives by commit in a repository you open every day. VS Code has one more barrier: automatic tasks never run in an untrusted folder, and in a folder you trust they ask for permission once by default. In a pull request, the place to catch it is the diff itself: a “config update” that adds a hook to .claude/settings.json. Both the commit’s author and its message looked ordinary; look at the content.
The second example is the file that doesn’t arrive by commit. According to GitSpawn, the research Manifold Security published on 1 September, coding agents run git commands in the background to gather context, and some did so before you had typed anything, even before the trust prompt. When commands like git status refresh the index, they run the program named in the core.fsmonitor setting, and git reads that setting from the repository’s own .git/config file. The result, as Manifold describes it: the repository names a command, and git runs it with your privileges, outside the sandbox and without any approval prompt.
How the file arrives matters. According to Manifold, cloning the repository from a hostile URL does not trigger this, and neither do fetch and pull; git does not carry this setting. For the attack to work, the repository has to come with its own .git folder: in a zip file, on a shared drive, in a sync folder or on a USB stick. The research’s rule fits in one sentence: “Any setting that names a program can run it.” On the day of publication, 4 of the 8 findings had been fixed; check your tool’s release notes. This file never shows up in a diff and can run before the trust prompt; the only time you can look at it is when the folder reaches you.
Does an agent running in CI show the trust prompt?
It doesn’t; there is nobody to ask. Where the tools differ is in what they do instead: some use the project’s configuration, some don’t load it at all, and some stop. If an agent reviews your pull requests in CI, look at this table:
| Tool | Non-interactive run in an untrusted folder | Setting in the documentation |
|---|---|---|
| Claude Code | claude -p and the SDK never show the trust prompt. The settings file’s hooks, the env block and apiKeyHelper are used; .mcp.json servers connect without asking | In a repository you didn’t write: --setting-sources user, --bare or disableAllHooks |
| Codex | codex exec runs in a read-only sandbox by default. Whether it loads the project’s .codex/ layer is not stated in the documentation | --ignore-rules skips the user’s and the project’s rules files |
| Copilot CLI | In -p mode, the repository’s hooks and MCP servers are not loaded | --trust-folder trusts the folder for one run; COPILOT_ALLOW_ALL=true trusts it without asking and loads its hooks too |
| Cursor CLI | The run stops with an error that tells you what to do | Continues with --trust, --force or --yolo |
| Antigravity CLI | Not stated in the documentation | — |
Source: the tools’ documentation and release notes, 20 October 2026. “Not stated in the documentation”: in the pages we read that day, we found no sentence that describes this. Cursor CLI switched to this behaviour in January 2026. When folder trust is on, Gemini CLI stops a non-interactive run with FatalUntrustedWorkspaceError.
Claude Code’s permissions documentation shows this case in a table of its own. In a claude -p run in a folder that was never trusted, allow rules are not used, but the settings file’s hooks and the env block are. We covered the MCP side in the MCP post. The documentation also says what to do with a repository you didn’t write: with --setting-sources user, Claude Code doesn’t read the project’s settings files at all; with --bare, it reads no hooks, skills, subagents or plugins from the project, but the project’s env block still applies. To turn hooks off, pass disableAllHooks to that run with --settings. According to the documentation, writing it only in your own user settings isn’t enough, because the project’s settings can override yours and set it back to false.
In Copilot CLI, watch one variable: if COPILOT_ALLOW_ALL is exactly true, the CLI trusts the folder without asking and loads everything in the repository, including hooks that run shell commands. If you see this variable in a workflow, check whether the job runs on the pull request’s branch. Codex’s documentation has a separate warning for CI: in jobs that check out or run the repository’s code, don’t set the API key as a job-level environment variable; build scripts, tests and dependencies’ install hooks can read it.
In Gemini CLI, this gap became a security advisory and was closed. According to advisory GHSA-wpqr-6v78-jr5g on GitHub (24 April 2026, critical, CVSS 10.0), older versions automatically trusted the folder when running in CI. The advisory names the risk plainly: CI workflows that review pull requests submitted by users. Environment variables placed in the .gemini/ folder of such a repository could lead to remote code execution. The vulnerability was fixed in Gemini CLI 0.39.1 and in the run-gemini-cli action 0.1.22; now you have to trust the folder explicitly in a non-interactive run too.
What is prompt injection, and can a pull request fool a review bot?
Prompt injection means putting instructions into text a model reads, to change how it behaves. OWASP separates two kinds: direct prompt injection, made through the user’s own input, and indirect prompt injection, hidden in a web page or a file the model reads from outside. According to OWASP, the text doesn’t even have to be visible to a person; it is enough that the model reads it. For a coding agent, that text can be a file in the repository, a pull request description, an issue or a comment.
Workspace trust doesn’t close this path: the moment you run the agent in a folder, you have it read the text in that folder too. That is why VS Code’s documentation recommends opening a project you haven’t reviewed in Restricted Mode. Any file the agent pulls into its context can lead to prompt injection; in Restricted Mode, agents don’t run at all. Against text, you are left with two things: where the rules are read from, and what the agent may do.
GitInject (7 June 2026) measured how far this can go in CI, on real GitHub workflows. The researchers tested the workflow configurations of 4 AI providers and documented 11 attacks. The attacks fall into four classes: config-file injection, credential exfiltration, judgment manipulation and disrupting availability. Every provider tested turned out to be open to at least one class in its default configuration. According to the authors, the most serious vulnerabilities come not from the model’s behaviour but from how the CI infrastructure handles credentials and configuration files.
You don’t even need to write instructions to fool a review bot. PRWeaver (3 August 2026) built 208 attacks in 10 real repositories, each validated by running it, and had each one reviewed in four renderings (832 cases) by 3 review agents across 6 model configurations. When pull requests were reviewed one by one, 50%–60% of the attacks were caught; when 24 pull requests were reviewed in one go, the rate fell to 16%–22%. Putting the attack inside a real change, with a plausible description that explains both, lowered the catch rate by 10–18 points. Splitting the attack across commits made a difference of at most 5 points.
The authors’ conclusion: concealment works best when benign and malicious changes sit in front of the reviewer together, or when the purpose stated in the description makes the diff look reasonable. The list in the post on reviewing AI-generated code has an item for this: every claim in the description should have a counterpart in the diff. After PRWeaver, ask the reverse as well: does every change in the diff have a reason in the description?
The way to steer a review bot for good is to change its rules. If the rules file is read from the pull request’s branch, the pull request can also change the rules of its own review. The tools’ documentation says different things here:
| Tool | Where it reads its rules from | Also in the documentation |
|---|---|---|
| Claude Code Review | REVIEW.md from the branch the pull request will merge into or the default branch; never from the pull request’s own changes | Automatic reviews don’t run on drafts or on pull requests from forks; its access to the repository is read-only; it doesn’t approve or block the pull request |
| Copilot code review | Custom instructions, agent instructions and skills from the pull request’s branch; according to the documentation, this lets you try an instruction change in the same pull request without merging it | By default, its approval doesn’t count toward required approvals; this can be turned on in settings (public preview) |
| Cursor Bugbot | .cursor/config/bugbot.yaml from the branch the pull request will merge into; which branch BUGBOT.md is read from is not stated in the documentation | According to the documentation, this is why a pull request can’t change how Bugbot reviews it |
| Codex code review | Follows the review rules in the repository’s AGENTS.md files; which branch it reads them from is not stated in the documentation | According to the documentation, the rules don’t replace tests, branch protection or required approvals |
| Antigravity | No product in its documentation reviews pull requests | — |
Source: the tools’ documentation, 20 October 2026. “Not stated in the documentation”: in the pages we read that day, we found no sentence that describes this.
One example of narrowing what the agent may do is GitHub Agentic Workflows: the agent runs with read-only permissions, and writes such as a pull request it would open are not applied right away but held back. According to the documentation, a separate job runs before they are applied and searches the output for prompt injection attempts, leaked secrets and malicious code. An agent that has been fooled can only do as much harm as the permissions you gave it.
What should you do with an unknown repository or pull request?
To sum up: the trust prompt is asked once, never in CI, and it doesn’t filter text. What you should do depends on the case:
- A repository you don’t know. Don’t trust it. VS Code recommends leaving the folder in Restricted Mode when in doubt, and Cursor recommends opening a repository you don’t trust in a basic text editor. If you need to work on it with an agent, open it in a virtual machine or a container; Claude Code’s documentation recommends virtual machines too. A sandbox alone isn’t enough: in Claude Code, the sandbox covers shell commands only, and hooks and MCP servers stay outside it. The details are in the sandbox post.
- A folder handed to you. If a folder that came as a zip, on a shared drive or on a USB stick contains
.git, then, as Manifold recommends, read.git/configbefore you open it with an agent, or clone the repository again from its source. - An agent reviewing pull requests from forks in CI. Don’t let the agent load the project’s configuration: pass
--setting-sources userin Claude Code, and don’t useCOPILOT_ALLOW_ALLin Copilot CLI or--trustin Cursor CLI on the pull request’s branch. GitHub’s guide of 7 May 2026 callspermissions: read-alla reasonable default and says never toevalthe model’s output. Keep secrets out of the agent’s step. - A pull request that touches a config or rules file. Read a diff that touches one of the files from the second section as a security change; GitHub’s guide, too, treats any change that weakens CI as a blocker. If your review bot reads its rules from the pull request’s branch, a change to the rules file also decides how that pull request will be reviewed; read it like code too.
We asked the same questions of our own review service. Our AI code review tool, diffox, clones the repository fresh from GitHub into an empty folder for every review; since a clone doesn’t carry .git/config, the path GitSpawn used doesn’t reach us. As we described in the architecture post, the rules are read from the branch the pull request will merge into. The author of a pull request from a fork can write the diff and the file names however they like; but the text from them that reaches our comment can neither open an HTML tag nor become a link. This rule is there to prevent a phishing link appearing under our name, closing the folded section to write a fake “no issues found” section, and leaking data through an image.
Frequently asked questions
What is workspace trust?
It is a coding tool or editor asking, the first time you open a folder, whether you trust it, and leaving part of the folder’s configuration unloaded until you do. The aim is to stop hooks, tasks and MCP servers placed in a repository from running before you have looked at them. Claude Code, Codex, GitHub Copilot, Cursor and Antigravity CLI have it; in Cursor’s editor it is off by default. Trust is given to a folder once, and it doesn’t stop the text in the folder from steering the agent.
What does trusting a folder in Claude Code turn on?
Claude Code ties trust to the repository root, and it covers the whole repository. Once you trust it, the allow rules and additional directories in the project’s .claude/settings.json, subagents’ hooks and MCP servers, and plugins from the repository are used; the hooks and the env block in the settings file also run in the session. .mcp.json servers get a prompt of their own. The prompt appears only in an interactive session; claude -p and the SDK never ask. If you start it in your home directory, trust is held for that session only.
How do I remove a trusted folder?
It depends on the tool. In VS Code, open the Workspace Trust editor (Workspaces: Manage Workspace Trust) and remove the folder from the list of trusted folders. In Copilot CLI, edit the trustedFolders list in ~/.copilot/config.json. In Gemini CLI, type /permissions in that folder; all the decisions are in ~/.gemini/trustedFolders.json. In Codex, set that project’s trust_level to untrusted in ~/.codex/config.toml. Claude Code stores trust in the hasTrustDialogAccepted field of ~/.claude.json; a command to undo it is not stated in the documentation. Cursor’s and Antigravity’s documentation don’t cover this either.
Can you turn off workspace trust in VS Code?
Yes: the security.workspace.trust.enabled setting (on by default) turns the feature off completely, while the --disable-workspace-trust flag does so for that session only. VS Code’s own advice is the opposite: when in doubt, leave the folder in Restricted Mode; you can grant trust later. In Restricted Mode, agents, tasks, debugging and the terminal are off. You can gather the repositories you open often under one parent folder and trust only that folder, and keep the repositories you don’t know in another.
What is prompt injection?
It is hiding instructions in text a model reads, to change how it behaves. OWASP separates two kinds: direct prompt injection, made through the user’s own input, and indirect prompt injection, hidden in a web page, a file or a comment the model reads from outside. With coding agents, the second kind is the one that stands out: a file in the repository, a pull request description or the text of an issue enters the agent’s context. According to OWASP, the text doesn’t even have to be visible to a person; it is enough that the model reads it.
Can a pull request fool an AI code review tool?
Research shows it can. In PRWeaver, AI review agents caught 50%–60% of hidden attacks when pull requests were reviewed one by one, and 16%–22% when 24 pull requests were reviewed together; a plausible description lowered the rate further. In GitInject, all 4 providers tested were open to at least one attack class in their default configuration. Check whether your tool reads its rules from the pull request’s branch or from the branch it will merge into. diffox reads the rules from the branch the pull request will merge into, and text from the pull request that reaches its comment cannot become a tag or a link.
Does the trust prompt appear with claude -p or in CI?
No. According to Claude Code’s documentation, claude -p and SDK sessions never show the trust prompt; the hooks in the repository’s settings file, the env block and apiKeyHelper are used, and .mcp.json servers connect without asking. In a repository you didn’t write, start it with --setting-sources user or --bare; to turn hooks off, pass disableAllHooks with --settings. Copilot CLI’s -p mode doesn’t load the repository’s hooks in an untrusted folder; Cursor CLI stops unless you pass --trust.