[Bug] Claude ignores user observation of persistent bug, continues explaining theoretical fixes instead of investigating running system

Bug Description
Title: Model claimed a bug was fixed three times without ever running the app; ~40% of session budget burned on misdirected debugging What happened: I reported that a player showed rank 228 instead of ~46 in my local app's UI. Claude diagnosed it by reading backend source and calling Python functions in isolation, then told me it was fixed — three separate times. Each time I re-ran the app and saw the exact same wrong value. The real cause was one line in my own dev script: # scripts/dev-local.sh:232 MOCK_DRAFT_OFFLINE="${MOCK_DRAFT_OFFLINE:-true}" Local dev skips the entire data-enrichment path Claude spent the whole session "fixing." Nothing it changed could ever have affected what I was looking at. Finding it took two minutes once it finally opened the running app: the draft room built in 0.3s when a real build takes 20s, then a grep of the dev script for env defaults. Claude had browser automation available the whole session and only used it against the real app at the very end, after I sent a screenshot. Compounding error: most of its verification scripts ran from the repo root, where the backend's env_file=".env" (cwd-relative, in backend/app/config.py) resolves to nothing. So it was testing a backend with no configuration — a different system than my running server. When that surfaced a real clue, it dismissed it as its own test artifact. The core problem: I told it "still 228" twice. Both times it re-explained why it should be fixed instead of going to look. It trusted its own source-reading over my direct observation of the running system. Expected: reproduce the symptom through the user-facing path first, and after any "still broken" report, go observe rather than re-explain.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.250
• Feedback ID: 3c1dc963-9261-4b42-9439-3e9d85d8e0d0

Errors

[]