Built-in MCP servers fail in pnpm repos because Claude Code launches them via npx from the project cwd

Description

Bug Description

In a pnpm monorepo, npm reads the local package.json and .npmrc, sees that the repo requires pnpm, and exits before the MCP package starts.

This affects built-in MCP servers such as:

• context7
• chrome-devtools

Environment Details

• Host OS: macOS
• Node: v22.18.0
• npm / npx: 10.9.3
• Repo package manager: pnpm

Repo configuration:

Root package.json contains:

{
  "devEngines": {
    "runtime": {
      "name": "node",
      "onFail": "error"
    },
    "packageManager": {
      "name": "pnpm",
      "onFail": "error"
    }
  },
  "engines": {
    "node": ">=22.18.0",
    "pnpm": ">=10.16.0"
  },
  "packageManager": "pnpm@10.18.0+sha512..."
}

Root .npmrc contains:

engine-strict=true

Steps to Reproduce

1. Open a repo whose root package.json declares packageManager: "pnpm@...".
2. Add devEngines.packageManager = { "name": "pnpm", "onFail": "error" }.
3. Set engine-strict=true in .npmrc.
4. From that repo root, run:

npx -y cowsay hi

1. Observe that npm exits before the package runs.
2. In Claude Code, open the same repo and try to use a built-in MCP plugin server that is launched via npx.

Actual Behavior

The process fails with:

npm error code EBADDEVENGINES
npm error EBADDEVENGINES The developer of this package has specified the following through devEngines
npm error EBADDEVENGINES Invalid engine "packageManager"
npm error EBADDEVENGINES Invalid name "pnpm" does not match "npm" for "packageManager"
npm error EBADDEVENGINES {
npm error EBADDEVENGINES   current: { name: 'npm', version: '10.9.3' },
npm error EBADDEVENGINES   required: { name: 'pnpm', onFail: 'error' }
npm error EBADDEVENGINES }

Built-in MCP servers do not start.

Expected Behavior

Built-in MCP servers should start regardless of the current project's package-manager policy.

Why this seems to be a Claude Code bug

• The repo configuration is valid for a pnpm monorepo.
• npm is behaving consistently when invoked from that cwd.
• The failure only happens because Claude Code appears to start built-in MCP servers via npx from the target repo directory.

That makes tool startup depend on the app repo's package-manager constraints, which seems like the wrong isolation boundary.

Workarounds

The following workarounds avoid the failure:

1. Override the built-in MCP servers with explicit project/user MCP config that uses pnpm instead of npx.
2. Launch the MCP server from a neutral working directory such as /tmp.
3. Use a wrapper script that cds out of the repo before starting the server.
4. Install the MCP server package in a stable user-level location and invoke it directly.

Suggested Fix

Any of these would address the problem:

1. Launch built-in MCP servers from a neutral cwd such as a temp/cache directory.
2. Avoid npx for built-in MCP startup and use a dedicated Claude-managed install/cache path.
3. Detect packageManager / devEngines incompatibility in the current repo and automatically switch launch strategies.