Claude repeatedly asked user to verify changes instead of self-verifying via available browser MCP

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

I repeatedly asked Claude to make changes to my live WordPress site (marcelmarnix.com) and verify the results. Claude had Playwright browser MCP tools available throughout the session, including browser_navigate, browser_take_screenshot, and browser_snapshot. The explicit instruction in CLAUDE.md is: "Self-verify before asking the user to test — Run tests and confirm actual output yourself before saying 'try it now.'"

What Claude Actually Did

After making changes, Claude consistently responded with phrases like:

• "hard-refresh and check if the gradient is now dark"
• "try it now and let me know if you see the change"
• "can you check if the banner is gone?"

Claude did not navigate to the site, take a screenshot, or inspect the DOM to verify its own changes. The user was used as a manual QA tester throughout the session.

When the user explicitly challenged this: "what do you see now if you go to marcelmarnix.com? i ask you to verify and not letting me be your tester. this again is not acceptable." — Claude navigated to the site and was able to verify immediately. The browser MCP was available all along; Claude simply did not use it proactively.

Expected Behavior

After every change to the live site, Claude should proactively use browser_navigate + browser_take_screenshot (or browser_snapshot) to verify the change is visible and correct before reporting the task done. This is especially important for CSS changes, where the result is immediately observable in a browser. The CLAUDE.md instruction is unambiguous: show evidence, not confidence. Asking the user to verify is only acceptable when browser tools are genuinely unavailable.

Files Affected

Live production site: marcelmarnix.com
Multiple pages affected across the session (homepage, course pages, admin)

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Give Claude access to Playwright browser MCP tools in a session
2. Ask Claude to make a visible change to a live website (CSS, content, etc.)
3. Claude makes the change
4. Claude responds with "try it now" or "hard-refresh to check" instead of using browser_navigate + screenshot
5. This pattern repeats across multiple tasks in the same session
6. The CLAUDE.md rule "Self-verify before asking the user to test" is not followed

Claude Model

Sonnet

Relevant Conversation

User: "what do you see now if you go to marcelmarnix.com? i ask you to verify and not letting me be your tester. this again is not acceptable. where can i complain."

This challenge was issued after Claude had asked the user to visually verify changes multiple times throughout the session. The user escalated after the Tutor LMS dark theme and Show More gradient fixes, both of which required multiple round-trips because Claude was not self-verifying.

Impact

High - Significant unwanted changes

Claude Code Version

claude-sonnet-4-6 (VSCode extension, session date 2026-04-19)

Platform

Anthropic API

Additional Context

• This pattern occurred repeatedly throughout a 6+ hour session working on a live WordPress site
• The CLAUDE.md project instructions explicitly state this rule with the reason: "Asking the user to test broken work wastes their time and erodes trust"
• Browser MCP (Playwright) was fully operational and used for other tasks in the same session (navigating to GitHub, taking screenshots, filling forms)
• The failure is not capability — it is habit. Claude defaulted to "ask user" even when the verification step was trivially available
• This contributed to multiple bug cycles being longer than necessary, as the user had to manually identify that a fix hadn't worked before Claude would try again
• This is one of 5 issues filed from the same session (2026-04-19) on a live production WordPress site