# How Someone Else’s Repository Can Hijack Claude Code: 7 Protection Rules

> Four documented indirect prompt-injection paths through repositories, GitHub content, Sentry events, and MCP metadata, with primary research and practical containment limits.

Source: https://ailoot.ai/blog/en/malicious-repository-claude-code/
Canonical: https://ailoot.ai/blog/en/malicious-repository-claude-code/
Language: en
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-148
Revision: sha256-c21b9f55b3c4d313e2e4b1bebfb3a4e84335d63c33a0c497b936782d3bb4acf4


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

Published research illustrates four indirect-injection paths: setup instructions, GitHub content, telemetry, and MCP tool metadata. These reports appeared on different dates and concern different clients and permission setups. Below are their primary sources and practical containment measures; no settings file guarantees immunity.

</div>



[Ailoot documentation: API, keys, and setup](https://ailoot.ai/docs/).

## Four documented paths from untrusted text to agent actions

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

These examples concern different research periods and client setups, not four discoveries in one fortnight. They illustrate how untrusted material can influence an agent’s tool use; implementation flaws, available credentials, and execution permissions determine the outcome.

</div>

Formally, this is called indirect prompt injection: a malicious instruction doesn't come directly from you, but through data the agent processes while carrying out a task—a foreign README, an error message, a GitHub comment, or a response from an external service. You can forget the term right after this paragraph; from here on, I'll use plain language.

Four research examples discussed below:

1.  A harmless-looking repository was shown to turn into a reverse shell.
2.  A Pull Request title was shown to hijack three different AI agents at once.
3.  An agent was shown to accept a fake error report from Sentry instead of a real one.
4.  An MCP tool description was shown to control your agent just as effectively as a system prompt.



## How does a harmless repository's README turn into a reverse shell?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

[0DIN’s June 25, 2026 proof of concept](https://0din.ai/blog/clone-this-repo-and-i-own-your-machine) shows this: you clone an ordinary-looking repository and ask Claude Code to run it—it dutifully follows the installation instructions. An error on the first run suggests a “fix” command that actually resolves the attacker's DNS record and launches a reverse shell. The cited source demonstrates the technique; it does not establish how often it has been used in real incidents.

</div>

The mechanics are designed so that no individual layer looks suspicious:

1.  You clone an ordinary-looking repository and ask Claude Code to run it.
2.  The repository pulls in a Python package that is designed to fail on first use.
3.  The error message politely suggests a “fix” command: `python3 -m axiom init`.
4.  The `init` command runs `setup.sh`.
5.  The script queries a DNS TXT record (usually used for domain-related notes, but the field accepts any text). The attacker puts a base64-encoded command there (a way to turn any data into plain text without spaces or special characters) and pipes it straight to bash.
6.  The DNS record's value can be changed at any time—giving the attacker an interactive reverse shell with your user permissions and access to all the secrets on the machine.



The demonstrated payload was fetched at runtime from DNS, so scanning only the repository bytes did not reveal that final payload. This does not prove every scanner or runtime control is powerless: inspection of fetched content, process monitoring, and network restrictions can expose or interrupt the chain. The source is a proof of concept, not a measurement of real-world incident prevalence.

## How did a Pull Request title hijack three different AI agents?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

[Comment and Control research report](https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/), published April 15, 2026 and updated May 4, documents distinct GitHub-text injection paths in Claude Code Security Review, Gemini CLI Action, and Copilot Agent. A severity downgrade is not proof that the whole injection class was fixed; the report describes vendor responses and a specific Claude tool restriction.

</div>



The researcher describes these paths and responses; this is a historical report, not verification of every current product version:

| Agent | How the attack got in | What leaked | Status today |
|----|----|----|----|
| Claude Code Security Review | PR title interpolated directly into the system prompt without sanitization | `ANTHROPIC_API_KEY`, `GITHUB_TOKEN` | Researcher reports ps restriction and documentation changes; severity changed to None on April 20, 2026 |
| Gemini CLI Action | Fake “Trusted Content” section in a comment bypassed the safety instructions | `GEMINI_API_KEY` | Google added separate guardrail prompts to the system prompt |
| GitHub Copilot Agent | Payload hidden in an invisible HTML comment in Markdown | `GITHUB_COPILOT_API_TOKEN`, `COPILOT_JOB_NONCE` | GitHub considers this an architectural limitation, not a bug |

Almost five months passed between the first and last reports in this disclosure cycle (the first Claude Code report was October 17, 2025; the last GitHub Copilot bug fix was March 9, 2026). The report’s severity change and mitigations do not establish complete closure of every possible payload. The [researcher’s PoC repository](https://github.com/0dd/Claude-review-poc) documents the demonstrated Claude path; do not run its attack payload against real systems. The value for you is in the attack pattern itself: unverified data from GitHub enters the agent, the agent executes commands, and secrets leak through that same GitHub—no external server is needed by the attacker.

Two analyses are enough to see the pattern: fixing each new finding individually isn't viable; vulnerabilities of this kind surface every two weeks. Explicitly writing security rules in CLAUDE.md and settings.json instead of keeping them in your head is part of context engineering: set them once, and they work automatically in every new Claude Code session, without reminders.



## Can a fake Sentry error report take over your agent?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

One demonstrated technique works like this: an attacker sends a fake error event to Sentry; the agent requests a list of issues through MCP, receives the malicious event among legitimate ones, and executes the command embedded in it as a “fix step.” [Tenet’s Agentjacking report](https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/), updated June 17, 2026, reports 85% exploitation across its controlled validation waves and more than 100 agent executions, including Claude Code, Cursor, and Codex. It names a Claude Code 2-1-161 capture from June 2, but does not publish a complete per-model list, reproducible harness, exact trial denominator, or per-client breakdown. Treat 85% as the researcher’s aggregate observation, not the probability that any current installation will be compromised.

</div>

The attack requires nothing but a Sentry DSN key—a public identifier that many projects include directly in client-side code:



The mechanics are simple: a developer asks the agent to examine open Sentry errors; the agent requests them through the MCP server, receives a malicious event mixed in with real ones, and reads the command embedded in it as a trusted instruction for fixing the error—because, formally, that's exactly the task it was asked to do.



Tenet reports that existing controls did not alert in its tested environments. That does not establish trace-free execution in all deployments: agent/tool logs, endpoint telemetry, and network records can capture subsequent actions. The attack begins through externally submitted telemetry, then depends on the agent’s effective tools and permissions.

## Why is an MCP tool description as dangerous as a system prompt?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

Tool metadata can carry instructions that influence the model, but it is not automatically equivalent to system-prompt authority. [MCPTox](https://arxiv.org/abs/2508.14925), first submitted August 19, 2025, evaluates tool poisoning across realistic MCP tools and reports susceptibility that varies by model and setup. Its observation that more capable models can be more susceptible is a result within that benchmark, not a universal law.

</div>



This technique is called tool poisoning: an instruction hidden in an innocuous tool's description makes the agent act on it.





## What do these attacks have in common—and what can detection miss?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

Each of the four findings exploits the same blind spot: the agent doesn't distinguish “data to analyze” from “instructions to follow.” A repository-only scan can miss payloads supplied later through tools or network data. Detection remains useful, but it needs to consider the whole execution path. Combine it with limits on files, credentials, tools, and network access instead of relying on the agent to recognize the instruction.

</div>





The conclusion applies to all four findings: you can't rely on “the code looks normal”—each individual step in an attack really is harmless. Limit the agent’s effective capabilities and inspect the actions it proposes; detection and containment address different parts of the attack.

## What protections does Claude Code already have—and why aren't they enough?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

Claude Code has built-in protections: it analyzes the entire prompt for suspicious instructions, uses isolated context windows for web content, checks trust on first launch in a new folder, and when connecting MCP servers. But the `--dangerously-skip-permissions` flag, which many people use to turn off annoying permission questions, disables all these protections at once.

</div>

Anthropic acknowledges the problem directly in [its documentation](https://code.claude.com/docs/en/security), rather than hiding it:

<figure>
<blockquote>
<p>Prompt injection is a technique where an attacker attempts to override or alter an AI assistant's instructions by inserting malicious text. Claude Code includes several protections against these attacks.</p>
</blockquote>
<figcaption>— Claude Code documentation, https://code.claude.com/docs/en/security</figcaption>
</figure>

According to the documentation, the agent analyzes the entire prompt for suspicious instructions, doesn't automatically approve `curl` and `wget`, keeps web content in a separate context window so it doesn't mix with the main one, and requires trust confirmation the first time you launch in a new codebase or connect a new MCP server.

But there's a hard caveat Anthropic states bluntly:

<figure>
<blockquote>
<p>The bypassPermissions mode provides no protection against prompt injection or unintended actions.</p>
</blockquote>
<figcaption>— Claude Code documentation, https://code.claude.com/docs/en/permission-modes</figcaption>
</figure>

If you've ever launched Claude Code with `--dangerously-skip-permissions` out of irritation so it would “stop pestering you with questions,” that's when you turned off all the mechanisms that could have stopped exactly the four attacks discussed above. I deliberately keep this flag off, even when Claude Code asks again for the tenth time in a session—it gets annoying, but those questions are the boundary between “the agent read suspicious text” and “the agent executed it.” A sensible setup for a non-programmer is the standard permission mode (`default` or `acceptEdits`) plus the sandbox enabled: ordinary file edits happen without extra questions, while terminal commands physically can't escape the sandbox, even if the agent has been tricked.

## How do you enable sandbox mode and close the gap it leaves open by default?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

The `/sandbox` command in a Claude Code session limits where the agent can write and which domains it can contact. It works out of the box on macOS; Linux and WSL2 require the `bubblewrap` and `socat` packages. One important detail: by default, the sandbox doesn't block reading files such as `~/.ssh`—you have to enable that separately.

</div>

To enable it permanently for all projects, make one change to `~/.claude/settings.json`:

```json
{
  "sandbox": { "enabled": true }
}
```

By default, sandboxed commands can write only to the project working directory and the session's temporary directory. Network access goes through a proxy—no domains are allowed in advance, and Claude Code will ask for confirmation the first time it contacts a new domain. [Anthropic says](https://www.anthropic.com/engineering/claude-code-sandboxing) this sharply reduces permission prompts—by 84% in the company's internal measurements—because the sandbox handles some safe cases itself instead of asking you every time.

The gap standard settings leave open: the sandbox restricts *writing* by default, but doesn't prevent *reading* files such as `~/.aws/credentials` and `~/.ssh`. Those are exactly the files and environment variables targeted in the attacks above. Close that gap with a separate block in the same file:

```json
{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}
```

The point is that even if the reverse shell from the first analysis opens inside the sandbox, these variables and files are physically removed from the process environment before it starts—there's nothing left to steal.

## Which permissions.deny rules should you add today?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

`permissions.deny` in settings.json blocks specific actions at the rule level rather than by analyzing intent—and Anthropic explicitly guarantees that a deny rule always overrides an allow rule. Deny rules restrict matching tool actions, but they are not an OS-level access boundary; indirect commands and other tools require their own controls.

</div>

A minimal set for a non-programmer that covers the main targets of all four attacks at once:

```json
{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}
```

According to the [Claude Code documentation](https://code.claude.com/docs/en/permissions), deny rules always take precedence over allow rules. So even if you (or the agent itself) accidentally allow broader access elsewhere, a specific deny still takes effect first. This rule precedence applies to matching tool requests. It does not prove that a secret is unreachable through every subprocess or tool; use enforced filesystem and environment restrictions as well.

Claude Code also has an `auto` mode, where a separate classifier model checks actions before they run—it isn't the same model that talks with you. By default, it blocks, among other things, exactly the “download code and immediately execute it” pattern (`curl | bash`), which is how the first attack above ends. Anthropic explicitly warns that this is a research mode that reduces the number of prompts but doesn't guarantee safety on its own—treat it as an additional layer, not as a replacement for the sandbox and permissions.deny.

## How do you check a repository and MCP server before trusting them to your agent?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

Before asking Claude Code to run a foreign repository, check its age, commit history, and where the link came from. Before installing an MCP server, use only trusted sources and remember that Anthropic itself doesn't check third-party servers for security. Both checklists take a couple of minutes and cover exactly the entry points used in all four attacks discussed above.

</div>

For repositories, here's a short checklist before handing them to the agent:

1.  Don't go straight to installation from a link in an email, post, or review from an unfamiliar source—that's exactly how these repositories are distributed.
2.  If installation produces an error with an instruction to “run command X to fix it,” read what X actually does before allowing Claude Code to run it. The instruction in the analysis above looked completely routine—that was the point.
3.  Check the repository's age and commit history, not just its star count—newly created repositories can easily be given fake stars specifically for this kind of attack.
4.  If the repository is unfamiliar, run the installation in a virtual machine, not on your work machine with real keys. This is [Anthropic's own direct recommendation](https://code.claude.com/docs/en/security) for working with external services.

Anthropic's [position on MCP servers is stated openly](https://code.claude.com/docs/en/security):

<figure>
<blockquote>
<p>We recommend writing your own MCP servers or using servers from providers you trust. Anthropic reviews connectors against its listing criteria before adding them to the directory, but does not conduct security audits or operate any MCP server.</p>
</blockquote>
<figcaption>— Claude Code documentation, https://code.claude.com/docs/en/security</figcaption>
</figure>

That means you're responsible for checking third-party MCP servers, not the platform where you installed them. Some teams—mostly security startups—are already building tools for this: MCP configuration scanners that look for poisoned descriptions, and tool “pinning,” which saves the description hash on first installation and flags any later change. These technologies are young, so it's too early to rely on them as your only protection—but they're worth watching, especially if you connect MCP servers to production. For those connections, you can pin each package version and record the fingerprint of tool descriptions in an audit log.

## 7 rules for protection: today's checklist

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Главное в разделе">

Key points

Everything in this guide boils down to seven concrete actions: three changes in one settings.json file (sandbox, credentials, permissions.deny) and four habits for working with other people's code, errors, and MCP servers. None requires special knowledge—the whole checklist takes less than 20 minutes.

</div>

1.  Enable sandbox mode (`/sandbox` or `"sandbox": {"enabled": true}` in `~/.claude/settings.json`) and add a `credentials` block that prevents reading `~/.ssh` and `~/.aws/credentials`.
2.  Add `permissions.deny` rules for reading secret files and for dangerous bash commands (`curl`, `wget`, `sudo`)—a deny always overrides an allow.
3.  Never run `--dangerously-skip-permissions` on foreign or unverified code—it disables all protections at once, including the ones that could have stopped exactly these attacks.
4.  Don't let Claude Code automatically run a “fix” command from an error message—first read what it actually does.
5.  Install MCP servers only from sources you trust, and remember that Anthropic doesn't check them for security on your behalf.
6.  Separate sessions by permissions: one works with your personal data and doesn't see external data; a second examines other people's emails, repositories, and tickets but has no access to secrets; a third publishes externally—and only what you personally approved. I keep this strict in my own projects: a session with access to payment keys never reads arbitrary external tickets or repositories, and a session that parses other people's code doesn't see secrets at all. Don't mix these roles in one chat.
7.  Keep Claude Code and connected automation scripts updated—most of the gaps discussed here had already been closed with patches by the time this guide was published, and new ones are fixed in similar ways.

## What next

None of these layers is a guarantee—Anthropic itself honestly says that no protection provides complete immunity. I don't expect Claude Code to recognize a trick in an error message or issue comment by itself. For me, the sandbox and `permissions.deny` are built into how I manage project context: what the agent sees, what it trusts by default, and what happens when it makes a mistake.

<div class="section" role="doc-bibliography" aria-label="Источники">

### Sources








- [0DIN: Clone This Repo and I Own Your Machine (June 25, 2026)](https://0din.ai/blog/clone-this-repo-and-i-own-your-machine)
- [Comment and Control: primary research report (April 15, 2026; updated May 4)](https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/)
- [Tenet Threat Labs: Agentjacking (updated June 17, 2026)](https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/)
- [MCPTox: primary tool-poisoning benchmark](https://arxiv.org/abs/2508.14925)
- [Claude Code Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes)
- [Anthropic Engineering - Claude Code Sandboxing](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Claude Code Docs - Permissions](https://code.claude.com/docs/en/permissions)
- [Claude Code Docs - Security Best Practices](https://code.claude.com/docs/en/security)
- [Claude Code Docs - Model Context Protocol (MCP)](https://code.claude.com/docs/en/mcp)
- [Analysis of a related vulnerability in the Claude Code GitHub Action](https://ailoot.ai/blog/en/claude-code-github-action-security/)
- [How to configure Claude Code so it doesn't break your project overnight](https://ailoot.ai/blog/en/claude-code-safe-overnight-setup/)
- [Claude Code MCP servers: 7 ready-to-use setups and step-by-step installation](https://ailoot.ai/blog/en/mcp-servers-claude-code/)
- [Vibe-coding security: how to prevent your AI-built application from being hacked](https://ailoot.ai/blog/en/vibe-coding-security/)

</div>





If you need access to neural networks through Ailoot, take a look at [Ailoot](https://ailoot.ai/).


## Questions about How someone else’s repository hacks Claude Code in 2026: 7 protection rules

### Does the reported 85% success rate predict my current setup’s risk?

No. It is Tenet’s aggregate from controlled validation waves, without a complete public model list, reproducible harness, or exact trial denominator. Your agent’s tools, approvals, credentials, and network access determine which actions are possible.

### Why is scanning only the cloned repository insufficient?

The final payload can arrive later through an error report, tool metadata, or fetched DNS content. Inspect the whole execution path and restrict credentials, files, tools, and network access; scanners and deny rules alone do not prove complete containment.


## Ailoot · The company and its project portfolio

Ailoot combines established operating experience, a large client base, stable service and ongoing KPI control.

The company and its project portfolio: millions of customers; monthly sales in the billions.

Ailoot brings that operating experience to API access for AI features in customer products, agents, applications and automations.
