[FEATURE] Inject project context into plugin MCP server environments for data isolation

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a plugin is installed with --scope local, only the plugin's activation is project-scoped — it controls whether the plugin loads in a given project. However, the plugin's MCP server process receives no project-specific context from Claude Code.

This means plugins that store data (e.g. memory tools, session logs, caches) have no standard way to know which project they are running in. As a result, they default to a single global data store shared across all projects.

For example, claude-mem stores all memory in ~/.claude-mem/ regardless of which project Claude Code is open in. A user working on 3 different projects gets a single combined memory pool, even if each plugin instance was installed with --scope local.

There is currently no mechanism — short of manually creating a project-level .mcp.json to override env vars — to achieve data isolation per project.

Proposed Solution

When Claude Code launches a plugin's MCP server, automatically inject environment variables that describe the current project context:

CLAUDE_PROJECT_DIR=/Users/user/projects/my-app
CLAUDE_PROJECT_NAME=my-app   # basename of the project dir, as a convenience

This would allow plugin authors to opt into per-project data isolation by default:

const dataDir = process.env.CLAUDE_PROJECT_DIR
  ? path.join(homeDir, '.my-plugin', slugify(process.env.CLAUDE_PROJECT_DIR))
  : path.join(homeDir, '.my-plugin');

Users would get automatic isolation without needing to know about .mcp.json overrides at all.

Alternative Solutions

Currently the only workaround is to create a project-level .mcp.json that re-declares the plugin's MCP server with an explicit env override:

{
  "mcpServers": {
    "mcp-search": {
      "type": "stdio",
      "command": "bun",
      "args": ["/Users/user/.claude/plugins/cache/thedotmack/claude-mem/12.6.5/scripts/mcp-server.cjs"],
      "env": {
        "CLAUDE_MEM_DATA_DIR": "/Users/user/.claude-mem/my-app"
      }
    }
  }
}

Downsides of this approach:

• Requires knowing the full absolute path to the plugin's versioned cache directory
• Breaks silently when the plugin is updated (version in path changes)
• Machine-specific paths make it unsuitable for committing to version control
• Requires understanding of MCP internals — not discoverable for typical users

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

1. A developer installs claude-mem (a memory/context plugin) to persist knowledge across sessions
2. They work on two separate projects: a React frontend and a Python backend service
3. Without this feature, both projects share the same memory store — React-specific context bleeds into Python sessions and vice versa
4. With CLAUDE_PROJECT_DIR injected automatically, the plugin can store ~/.claude-mem/react-app/ and ~/.claude-mem/python-service/ separately, with zero configuration from the user

Additional Context

The MCP server process already inherits cwd from Claude Code, but relying on process.cwd() is fragile — it can be affected by how the server is started. A first-class env var is more reliable and communicates explicit intent from the host.

This is analogous to how many editors inject $WORKSPACE_FOLDER or $PROJECT_ROOT into extension processes — a well-established pattern for host-aware plugin behavior.