MCP plugin tools override explicit CLAUDE.md instructions

Resolved 💬 3 comments Opened Apr 12, 2026 by bnuckols13 Closed May 23, 2026

Summary

When an MCP plugin tool (e.g., Playwright) pattern-matches the user's intent, the model reaches for it instead of following explicit instructions in CLAUDE.md. The tool's presence in the tool list overrides written configuration.

Reproduction

  1. Add this instruction to CLAUDE.md:

> After writing files, open them in the browser using open via Bash (e.g., open ~/Desktop/{folder}/index.html).

  1. Have the Playwright MCP plugin enabled.
  2. Ask Claude to generate HTML files and preview them.

Expected: Claude uses open via Bash, as CLAUDE.md specifies.

Actual: Claude reaches for plugin:playwright:playwright - Navigate to a URL instead. This then fails because:

  • Playwright MCP blocks file:// URLs entirely
  • If another Claude Code session has Playwright open, the shared Chrome profile lock (SingletonLock in ~/Library/Caches/ms-playwright/mcp-chrome-408e739/) causes cascading "browser already in use" errors that can't even be resolved via "Close browser"

Root cause

The model appears to weight tool availability (seeing a browser-related MCP tool) over explicit user instructions in CLAUDE.md. CLAUDE.md instructions should take precedence over tool pattern-matching.

Secondary issue: Playwright cross-session conflicts

The Playwright MCP plugin uses a single shared Chrome profile directory. When multiple Claude Code sessions are running, only one can hold the SingletonLock. The others get an unrecoverable error — even "Close browser" fails because the lock belongs to a different process. There's no --isolated flag exposed through the MCP interface to work around this.

Environment

  • Claude Code v2.1.104
  • macOS (Darwin 25.2.0)
  • Playwright plugin: claude-plugins-official/playwright/unknown

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗