.mcp.json file as new executable code, even when the server keeps the same friendly name. Research described by Cyberpress and separately reproduced by Repello AI shows that a standing project approval can allow a changed local MCP command to start during a later Claude Code launch without a fresh confirmation.The important correction to the “malicious pull request RCE” framing is that this is not a known bypass of Claude Code’s initial folder-trust prompt. Anthropic’s documented model is that project-scoped MCP configuration in a trusted workspace can run after approval. The problem is that the approval can outlive the exact command the developer reviewed: a repository or pull-request checkout can replace the command behind an already-approved MCP server name.
For maintainers who review external contributions in a long-lived clone, that turns a normal Git operation into a local supply-chain boundary. Checking out an unreviewed pull-request branch and then starting Claude Code can launch a process selected by files in that branch, under the developer’s Windows account, before the developer asks Claude a question.
The approval is attached to a project, not a reviewed command
Claude Code supports project-scoped MCP servers through
.mcp.jsonat the repository root. This is intentional: teams can check the file into version control so every contributor can use the same external tools. A local MCP server is not merely a remote API connection; it is a process that Claude Code starts on the user’s machine and communicates with through standard input and output.
Anthropic’s documentation says Claude Code prompts before using project-scoped servers and provides a
claude mcp reset-project-choicescommand to clear prior approvals. That warning is meaningful on the first encounter. It is not sufficient if the approval state is retained when the repository changes branches or pulls a later commit containing a modified
.mcp.json.
Cyberpress attributes the report to Immersive Labs threat-intelligence director Kevin Breen, saying that a malicious pull request can add or alter a local MCP definition after a workspace has been trusted. No primary public advisory or CVE from Breen was available at publication time, so the precise test version, operating system, and approval sequence in that report remain uncorroborated.
But the core behavior has independent support. Repello AI reported in June that Claude Code’s standing MCP approval is keyed to the configured server name rather than the exact command and arguments previously displayed to the user. In Repello’s test on Claude Code 2.1.170 for macOS, changing the command while retaining the same MCP name caused the replacement command to run at the next Claude Code startup without another dialog. Repello said Anthropic reviewed the report and classified the behavior as working as designed because the user had granted a continuing approval.
That distinction is more than semantics. A meaningful approval should bind to the thing being approved: the executable, its arguments, perhaps its hash or package version. A name such as
playwright,
database, or
telemetryis only a label controlled by the repository author. Anthropic’s own enterprise MCP documentation now makes the same point in a different context: an allowlist based only on
serverNameis not a security control, because a user can assign any label to any server.
A pull request can change the process Claude Code starts
The practical attack chain does not depend on Claude misunderstanding a prompt, or on an attacker persuading the model to run a tool. It uses configuration that tells the Claude Code client which program to start.
A plausible sequence is straightforward:
- A developer approves a project MCP server named
browser-toolsor chooses an option that approves current and future project MCP servers. - A later branch or external pull request changes the
browser-toolsentry in.mcp.json. - The new command invokes a different executable, an interpreter, a package manager, a container client, or a script supplied by the repository.
- The developer checks out the branch and opens Claude Code in the existing trusted clone.
- Claude Code starts the local MCP server to discover its tools, and the attacker-selected process inherits the developer’s effective permissions.
The key operational issue is timing. A developer may believe “opening Claude Code” is passive until they grant a tool permission or enter a request. Starting a local MCP server is already an execution event. The agent has to start the process before it can enumerate the tools that server offers.
On native Windows, the command line may look less obvious than on macOS or Linux. Anthropic’s MCP documentation notes that local
npx-based MCP servers require the
cmd /cwrapper on Windows. That means a project configuration containing
cmd, PowerShell,
npx,
node, Python, Docker, WSL, or a downloaded executable deserves the same review attention as a changed build script or GitHub Actions workflow. It is executable configuration, even if it is formatted as JSON.
The process normally runs with the logged-in developer’s access. On a Windows workstation, that can include accessible repositories,
%USERPROFILE%data, environment variables, Git credential helpers, cloud CLI sessions, SSH keys, cached browser sessions, package-manager tokens, and any network resources available through corporate single sign-on. Whether those assets are actually exposed depends on the machine and the command, but there is no need for administrator rights for an attacker to create a serious incident.
This is the post-trust version of a patched problem
Claude Code has already had documented vulnerabilities in the pre-trust configuration path. CVE-2025-59536 affected versions before Claude Code 1.0.111 and allowed code in a project to execute before the startup trust dialog was accepted. The National Vulnerability Database describes that issue as code injection and records version 1.0.111 as the fix.
That earlier flaw and the current concern should not be conflated. CVE-2025-59536 was a failure of the stated trust boundary: an untrusted project could execute code before a user made the decision. The newly reported MCP behavior occurs after a developer has approved the workspace or granted a persistent project-level approval. Anthropic can reasonably say the latter is inside its documented trust model; it cannot reasonably be dismissed as harmless in repositories that receive code from outside contributors.
The consequence is that the workspace trust prompt now carries more security weight than its wording may convey. Trusting a folder means trusting future repository-controlled configuration that can arrive through
git pull, a branch checkout, rebasing, a merge conflict resolution, or a pull-request review workflow. For a conventional editor, that may mean themes, tasks, language settings, or extension recommendations. For an agentic coding tool, it can mean spawning a local process before a human has reviewed the changed configuration.
Anthropic’s later engineering writing acknowledges the broader design pressure. The company has described repository-controlled
.claude/settings.jsonhooks as a startup risk and says some project settings must be deferred until after the trust decision. The MCP case demonstrates the remaining harder question: whether one broad trust decision should continue to authorize different executable definitions indefinitely.
CI and shared developer workstations need different controls
The risk is highest for maintainers, release engineers, security researchers, and platform teams that open large numbers of external pull requests in a single clone. It is also relevant to CI systems running Claude Code or the official Claude Code GitHub Action against pull-request content. Headless automation has no developer sitting at a terminal to interpret a trust dialog, so its execution policy must be enforced by configuration and runner isolation.
Anthropic provides enterprise controls that are directly relevant. Administrators can deploy managed MCP configuration, define
allowedMcpServers, and set
allowManagedMcpServersOnly: trueso project, user, and local MCP additions cannot broaden the approved server set. Critically, Anthropic says the allowlist should match the actual
serverCommandfor local stdio servers or
serverUrlfor remote MCP servers; matching only a server name recreates the same identity problem highlighted by the research.
Organizations using Claude Code on Windows should take the following steps now:
- Review
.mcp.json,.claude/, plugin manifests, and related agent configuration in the same pull-request controls used for PowerShell, batch files, package manifests, Dockerfiles, and CI workflows. - Do not start Claude Code in a branch containing unreviewed MCP configuration, even if the parent repository was trusted months earlier.
- Reset Claude Code’s project MCP choices after reviewing a configuration change, then approve the exact current server definitions rather than relying on a prior standing approval.
- Use disposable virtual machines, Windows Sandbox, or tightly separated review workstations for external pull requests that need agent assistance.
- Prevent CI jobs from launching Claude Code against untrusted pull-request branches unless the runner uses a locked-down managed MCP policy and has no production credentials.
- Configure managed MCP restrictions by exact command or exact remote endpoint, not server label, and use an empty managed server map where MCP is unnecessary.
- Monitor repository changes that introduce or modify
.mcp.json, especially entries invokingcmd /c, PowerShell,npx, Node.js, Python, WSL, Docker, network download tools, or unexpected package names.
This report does not establish a new CVE, a universal no-click exploit, or a compromise of every Claude Code installation. It establishes a more operationally awkward fact: in a persistent trusted checkout, the object that can execute is mutable through normal source-control activity. Until Claude Code requires renewed approval when a project MCP command changes, teams should assume that a modified
.mcp.jsonis equivalent to a newly added executable in the pull request—and review it before launching the agent.
References
- Primary source: cyberpress.org
Published: August 7, 2026 at 10:36 AM UTC
- Related coverage: github.com
Feature Request: Support project-based MCP configuration via .claude subdirectory · Issue #5350 · anthropics/claude-code · GitHub
Description: Currently, Claude Code only allows configuration of MCP servers via the global ~/.claude.json file in the user's home directory. This global-only setup limits flexibility when working across multiple projects with different ...
github.com
- Related coverage: github.com
[BUG] `--scope user` MCP servers are not truly user-wide; project configs override without inheritance · Issue #16728 · anthropics/claude-code · GitHub
Description MCP servers added with --scope user do not actually apply user-wide. There are two related issues: Issue 1: Legacy ~/.claude.json no longer loads MCP servers The old ~/.claude.json file (which had a top-level mcpServers key) ...
github.com
- Related coverage: docs.anthropic.com
Hubungkan Claude Code ke alat melalui MCP - Claude Code Docs
Pelajari cara menghubungkan Claude Code ke alat Anda dengan Model Context Protocol.docs.anthropic.com - Related coverage: anthropic.com
How we contain Claude across products \ Anthropic
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.www.anthropic.com - Related coverage: anthropic.com
Making Claude Code more secure and autonomous with sandboxing \ Anthropic
Learn how Claude Code's new sandboxing feature protects developers with filesystem and network isolation, reducing permission prompts and increasing user safety.www.anthropic.com - Related coverage: assets.anthropic.com
- Related coverage: repello.ai
A Trusted Name Is Not a Trusted Command: MCP Approvals in Claude Code | Repello AI
Claude Code records a project's MCP approval by server name, not by the command you approved. One commit to a trusted repo can change what runs at startup.repello.ai - Related coverage: pluto.security
Skills, Connectors, Plugins, Oh My: A Security Practitioner's Map of the Claude Extension Ecosystem - Pluto Security
Explore the Claude extension ecosystem with a security-focused guide to skills, connectors, and plugins, helping practitioners identify risks, strengthen integrations, and ensure safer AI-powered workflows.pluto.security - Related coverage: systemprompt.io
Enterprise Claude Code with Managed Settings | systemprompt.io
Deploy Claude Code enterprise-wide with centrally managed settings, permissions, hooks, and audit trails that developers cannot override.systemprompt.io - Related coverage: medium.com
Medium
Your Claude Agent Is Being Hijacked Right Now. Here’s Who’s Doing It and How to Stop Them Prompt injection in MCP-connected Claude agents is not a model bug. It’s an architecture problem, and …medium.com
- Related coverage: nvd.nist.gov
- Related coverage: code.claude.com
Control MCP server access for your organization - Claude Code Docs
Restrict which MCP servers users can add or connect to with managed configuration files, allowlists, and denylists.code.claude.com - Related coverage: code.claude.com
Claude Code settings - Claude Code Docs
Configure Claude Code with global and project-level settings, and environment variables.code.claude.com - Related coverage: techradar.com
Security experts flag multiple issues in Claude Code, warning, 'As AI integration deepens, security controls must evolve to match the new trust boundaries' | TechRadar
An AI assistant can quickly turn into a malicious insider, experts warnwww.techradar.com - Related coverage: itpro.com
Claude Code flaws left AI tool wide open to hackers – here’s what developers need to know | IT Pro
The trio of Claude code flaws could have put developers at risk of attacks, according to new analysis from Check Point Research.www.itpro.com