MCP plugin tools override explicit CLAUDE.md instructions
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
- 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).
- Have the Playwright MCP plugin enabled.
- 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 (
SingletonLockin~/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
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗