Claude Code users who approve project-scoped MCP servers should treat later changes to a repository’s .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.

A coding monitor shows a modified MCP configuration, trusted server workflow, and prominent security warnings.The approval is attached to a project, not a reviewed command​

Claude Code supports project-scoped MCP servers through

.mcp.json

at 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-choices

command 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

telemetry

is 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

serverName

is 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:

  1. A developer approves a project MCP server named browser-tools or chooses an option that approves current and future project MCP servers.
  2. A later branch or external pull request changes the browser-tools entry in .mcp.json.
  3. The new command invokes a different executable, an interpreter, a package manager, a container client, or a script supplied by the repository.
  4. The developer checks out the branch and opens Claude Code in the existing trusted clone.
  5. 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 /c

wrapper 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.json

hooks 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: true

so project, user, and local MCP additions cannot broaden the approved server set. Critically, Anthropic says the allowlist should match the actual

serverCommand

for local stdio servers or

serverUrl

for 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 invoking cmd /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.json

is equivalent to a newly added executable in the pull request—and review it before launching the agent.

References​

  1. Primary source: cyberpress.org
    Published: August 7, 2026 at 10:36 AM UTC

    Loading…

    cyberpress.org
  2. Related coverage: github.com

    Loading…

    github.com
  3. Related coverage: github.com

    Loading…

    github.com
  4. Related coverage: docs.anthropic.com
    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
  5. Related coverage: anthropic.com
    www.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
  6. Related coverage: anthropic.com
    www.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
  7. Related coverage: assets.anthropic.com

    Claude Sonnet 4.5 System Card

    PDF document
    assets.anthropic.com assets.anthropic.com
  8. Related coverage: repello.ai

    Loading…

    repello.ai
  9. Related coverage: pluto.security

    Loading…

    pluto.security
  10. Related coverage: systemprompt.io

    Loading…

    systemprompt.io
  11. Related coverage: medium.com

    Loading…

    medium.com
  12. Related coverage: nvd.nist.gov

    Loading…

    nvd.nist.gov
  13. Related coverage: code.claude.com

    Loading…

    code.claude.com
  14. Related coverage: code.claude.com

    Loading…

    code.claude.com
  15. Related coverage: techradar.com

    Loading…

    www.techradar.com
  16. Related coverage: itpro.com

    Loading…

    www.itpro.com
 

Click to expand...
You must log in or register to reply here.