Claude Code Security When You Did Not Write the Repo

A coding agent reads your repository, its dependencies, its issue titles and its CI output, and then it runs commands. Everything in that first list is input. On a repository you did not write, most of that input was written by someone you have never met.

Almost every article about Claude Code security is about the other direction: how to audit the code the model produced. This one is about the input side, because that is where the interesting failures have actually been.

If you only read one paragraph: check which mode you are in before you assume you are being asked, because Pro, Max and Team sessions now start in auto mode rather than Manual. Add a short deny list, since deny rules are the only ones that survive bypassPermissions. And run anything you genuinely do not trust in a container, because the sandbox and the classifier solve different problems and neither solves that one.

The five modes, and which one you are actually in

Claude Code has five permission modes. The names below are the config values, which matter because that is what you will see in a settings file.

The detail most people miss is the starting mode. Anthropic's documentation states that on Pro, Max and Team plans the built-in starting permission mode is auto mode. If you have not changed anything, a classifier has been approving actions on your behalf rather than you approving them. That is not a criticism of auto mode, which exists for a good reason covered below, but it does mean "Claude Code asks before it does things" is no longer the default experience for most paying users.

In Manual mode, Claude Code starts read-only and can write only inside the folder it was started in and that folder's subfolders. It also asks before reading paths outside that boundary with Read, Grep and Glob. That working-directory boundary is a Manual mode property, which is worth knowing before you assume it is protecting you in auto.

Why auto mode exists: the 93% number

Anthropic published the reason it built auto mode, and it is the most honest number in this whole subject:

Our telemetry showed users approved roughly 93% of permission prompts.

Their conclusion is the obvious one: "The more approvals a user sees, the less attention they pay to each, becoming over time much less diligent in their supervision." A permission prompt that is approved 93 times out of 100 is not a security control. It is a speed bump that trains you to click through.

So the prompt was not working, and two things were built to replace it.

Sandboxing came first. Anthropic reports that "sandboxing safely reduces permission prompts by 84%", using filesystem and network isolation "built on top of OS level primitives such as Linux bubblewrap and MacOS seatbelt". Fewer prompts because fewer actions need one, not because the check was removed.

Auto mode came second, with a classifier model reviewing actions instead of you. And here Anthropic publishes the limit as well as the feature: auto mode catches approximately 83% of problematic behaviours before execution, which means roughly 17% of overeager actions still get through.

Sit with those two figures together. You were approving 93% of prompts without much thought. The classifier that replaced you blocks 83% of the bad ones. Auto mode is a genuine improvement on an unreliable human, and it is not a boundary you should put between yourself and a stranger's code.

What YOLO mode actually removes

bypassPermissions is the mode everybody means by YOLO. You get there four ways:

claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions
claude --allow-dangerously-skip-permissions   # adds it to the cycle, does not activate it

or permissions.defaultMode: "bypassPermissions" in user, --settings or managed settings.

The flag is named the way it is on purpose, and it has guard rails that tell you what Anthropic expects to go wrong:

• It cannot be used with root or sudo privileges. The tool refuses.
• Claude Code on the web ignores the mode from settings files entirely.
• Deny rules still apply. Allow rules do not, because nothing is being asked.

That third point is the practical one and it is under-reported. Deny rules block in every mode, including bypassPermissions. If you are going to run in bypass, a short deny list is the only control you have left, and it costs one file:

{
  "permissions": {
    "deny": [
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(git push --force:*)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

There is also a set of actions Claude Code will not auto-approve in any mode, bypass included. Writes to protected paths are the main one. So bypass is not quite "everything", but it is close enough that the documentation's own guidance is the right reading: containers and VMs only.

The thing a hostile repository cannot do

Here is the fact that changes how worried you should be, and it is the reason a section on untrusted repos is not simply a list of horrors.

A repository cannot raise its own permission mode. From Anthropic's documentation on where the starting mode comes from: if .claude/settings.json or .claude/settings.local.json sets defaultMode to bypassPermissions, the value does not take effect and the session starts in Manual mode. If it sets auto, that does not take effect either.

Those two files are the ones that travel with a cloned repository. Somebody who wants your agent to run unattended on their code cannot arrange it by committing a settings file, because the two settings files they control are precisely the two that are ignored for this. Only your user settings, an explicit --settings file or your organisation's managed settings can raise the starting mode.

That is a good design and it is worth knowing, because it means the attack you should actually plan for is not "the repo turns off my prompts". It is the quieter one: the repo persuades the model to ask you for something that looks reasonable, and you approve it, as you have approved 93% of everything else.

What runs before you approve anything

The permission model governs what the agent does after it starts. The interesting failures have been in what happens before.

Anthropic states that between mid-2025 and January 2026 it received reports of vulnerabilities through its disclosure programme, and that three of them "targeted code that executes before the user has consented to anything".

The public example of that class is GitSpawn, which we covered separately: git reads core.fsmonitor from a repository's own .git/config, that setting is a command, and agents run git at startup to work out where they are. A folder that arrives as files rather than as a clone can therefore run a command as you, outside the sandbox, before any prompt. The full write-up including patch status per agent has the versions and the two-command fix; a git clone is not a vector, a zip is.

One more pre-consent detail from the docs, easy to miss and easy to trip over in automation: trust verification is disabled when running non-interactively with the -p flag. The first-run trust prompt is a real control. Scripted runs do not get it.

Where the sandbox helps and where it does not

Two different problems get confused constantly, so, plainly:

Prompt injection is the model being persuaded to do something by text it read. That text can be in a README, a code comment, an issue title, a dependency's documentation or a CI log. Anthropic's listed protections against it are the permission system in Manual mode, context-aware analysis, input sanitisation, an isolated context window for web fetches, and the fact that curl and wget are not auto-approved by default.

The sandbox is a limit on what a command can reach once it runs: filesystem isolation and network isolation, configured with /sandbox.

The sandbox does not stop injection. Injection does not defeat the sandbox. You need both, and on a repository you did not write you need a third thing, which is the assumption that both will occasionally fail.

Anthropic says as much in its own warning: "While these protections significantly reduce risk, no system is completely immune to all attacks."

MCP is the part nobody audits

If you have added MCP servers, read this sentence from the security documentation carefully:

Anthropic reviews connectors against its listing criteria before adding them to the Anthropic Directory, but does not security-audit or manage any MCP server.

Listing is not auditing. An MCP server is code you granted tool access to, and its permissions are yours to configure. Treat adding one the way you would treat adding a dependency with a postinstall script.

Not every runtime has a boundary at all

Claude Code's permission model is worth understanding partly because it is unusually well documented. Other runtimes make a different trade and say so.

Kit, a coding agent runtime from Speakeasy, states in its own documentation that it "is a coding agent runtime, not a security boundary", that its --root flag "selects Kit's working directory and project context; it is not a sandbox", that it "has no general permissions or interactive approval framework for its own tools", and that without a credential file "the HTTP listener performs no authentication".

It is a small, honest tool that expects you to supply the isolation, and it makes the general point: the permission prompt you are used to is a property of one product, not of agents in general. When you swap runtimes you swap threat models, and you should read the new one's documentation before pointing it at somebody else's code.

What to actually do

Ordered by how much they buy you per minute spent.

1. Check your mode. Shift+Tab cycles it, and the status bar shows it. If you are on Pro, Max or Team and have never changed anything, you are in auto.
2. Write a deny list. Five lines, and it is the only thing that survives bypass. Secrets and network fetches are the two worth blocking by default.
3. Use the sandbox for ordinary work. /sandbox. It removes most prompts by removing the need for them, which is the honest way to fix approval fatigue.
4. Use a container for code you do not trust. Not the sandbox, not auto mode, an actual disposable container. Anthropic's own guidance for bypassPermissions is containers and VMs only, and its docs point at dev containers for isolation.
5. Read .git/config on any folder that arrived as files. One grep for fsmonitor, hooksPath and filters. Clones are fine.
6. Never run bypass as root. The tool already refuses; do not work around it.
7. Treat MCP servers as dependencies. Nobody audited them for you.
8. Run /security-review on the diff, which is the output-side check and a different job from everything above. The security guidance plugin does the same work during the session.

FAQ

What is YOLO mode in Claude Code?

The community name for bypassPermissions, the mode where Claude Code stops asking before anything. You reach it with --dangerously-skip-permissions, --permission-mode bypassPermissions, or permissions.defaultMode set to bypassPermissions. Anthropic's documentation says it is for isolated containers and VMs only.

Can a malicious repository turn on YOLO mode by committing a settings file?

No. If a project's .claude/settings.json or .claude/settings.local.json sets defaultMode to bypassPermissions, the value does not take effect and the session starts in Manual mode instead. The same applies to auto. Only user-level settings, an explicit --settings file or managed settings can raise the starting mode.

Is auto mode safe enough on a repository I did not write?

It is a real improvement and it is not a boundary. Anthropic reports that auto mode catches roughly 83% of problematic behaviours before execution, which leaves roughly 17% getting through. On code you did not write, pair it with sandboxing or a container rather than relying on the classifier alone.

Does the sandbox stop prompt injection?

No. The sandbox limits what a command can reach, through filesystem and network isolation built on macOS Seatbelt and Linux bubblewrap. It does not stop the model being persuaded to run a command in the first place. The two problems are separate and need separate answers.

What runs before I approve anything?

More than you would expect. Anthropic received reports of three vulnerabilities between mid-2025 and January 2026 in code that runs before the user has consented to anything, and the GitSpawn class of bugs let a folder's own .git/config run a command at agent startup. Trust verification is also disabled when you run non-interactively with -p.

Do deny rules still work in YOLO mode?

Yes. Deny rules block in every mode, including bypassPermissions. Allow rules have no effect there because nothing is being asked. A short deny list is the one control that survives the mode people actually complain about.

When none of this is worth it

A recommendation that is right in every case is usually not a recommendation, so: most of this is overhead you should skip on your own code.

If you wrote the repository, its dependencies are ones you chose, and you are on a machine with nothing else valuable on it, then auto mode with the sandbox on is a reasonable place to stop. The container is for other people's code, client work, anything that arrived as a zip, and any repository whose issue tracker is open to strangers. The deny list is cheap enough to keep everywhere.

And there is a real case for bypass with no container at all: a throwaway VM you can delete, doing work you can redo. That is what the mode is for. The failure is not using it, it is using it on the laptop that holds your SSH keys.

The uncomfortable version of all of this is that the strongest control on the list is still the least reliable one. You are the thing standing between a persuasive README and your shell, and Anthropic has measured how well that goes: 93% approved, most of them barely read. Set things up so that being wrong is survivable, because occasionally you will be.