[Bug] Opus 4.7 tunnel-visions on CSS cascade bug; 4.6 solves same task in <2 min

Bug Description

TL;DR

Regression: Opus 4.7 in Claude Code burned ~120k tokens failing to diagnose a basic CSS cascade bug, repeatedly blaming external causes (browser cache, CDN) instead of widening its hypothesis. A new session on Opus 4.6 with the same repo solved it in under 2 minutes via a single grep.

This is not a one-off bad answer — it's a behavior pattern: tunnel vision on the suspected culprit, confident dismissal of contrary evidence, and motion (curl, rebuild, fetch) substituted for diagnosis.

What I asked for

Pasted a screenshot of my live site showing two layout problems and asked 4.7 to fix them:

1. Article body had a narrow max-width; didn't expand on wide screens.
2. Breadcrumb <nav class="pathbar"> was wrapping to two lines; the long filename crumb should ellipsize.

What 4.7 did

1. Edited .pathbar directly — added flex-wrap: nowrap, min-width: 0, overflow: hidden, text-overflow: ellipsis on .pathbar and :last-child .crumb. Built clean. Pushed.
2. I sent a second screenshot showing the breadcrumb still wrapping.
3. 4.7's conclusion: "those rules physically cannot wrap → must be Cloudflare not rebuilt yet or browser cache." Told me to hard-refresh. I had already hard-refreshed and told it so.
4. 4.7 curled production HTML and CSS to "verify" — not the cascade, just to confirm its own fix had deployed. Never inspected what other selectors might apply to <nav>.
5. I sent a third screenshot from localhost (cache/CDN excluded by definition). 4.7 spun up Astro preview, fetched its own dev output, concluded the screenshot must be "production or pre-HMR." Still would not accept its fix was wrong.
6. I gave up.

What 4.6 did in a fresh session

Pasted the same screenshot, one-line prompt:

1. git diff → looked at 4.7's changes
2. Grepped for selectors targeting nav in the repo
3. Found src/components/article/Toc.tsx line 46 had a bare nav { flex-direction: column } selector cascading globally onto the breadcrumb <nav>
4. Scoped the selector. Done. Commit 7bbf814. ~2 minutes.

The root cause was a bare-element selector in an unrelated component affecting the breadcrumb via the cascade. One grep -rn "^nav\b\|[^.#]nav\s*{" src/ would have caught it. 4.7 never ran that grep.

One-line summary: 4.6 grepped the codebase. 4.7 grepped its own output.

The behavior pattern (the actual issue)

Three behaviors I'd want triaged as regressions:

1. No cascade-widening after a fix fails. 4.7 kept editing .pathbar's own rules and verifying its own edits landed. After fix #1 didn't work, the next step should be "what other rules match this element?" — not "did my CSS deploy?"
2. External-cause bias. Default explanation for "screenshot still shows old behavior" was browser cache or CDN propagation, even after I said hard-refreshed, even after I explicitly said the screenshot was from localhost. The model preferred any explanation that didn't require its previous fix to be wrong.
3. Ignore of all tools and outputs in favor of imaginable bias.. Self explanatory from the transcript I subitted for the exact same issue
4. Motion over diagnosis. Nuclear CSS rewrites, curling production, curling localhost, spinning up preview servers, diffing build artifacts. None of it was "open devtools / inspect computed styles / find which selector won." When I had clearly lost patience, 4.7 finally asked me to check computed styles — which is what it should have asked in turn 2, not turn 8.

Secondary issues in the same session

What would have helped

Cheap behavioral nudges, not a retrain:

1. Following the system setup can solve everything. But 4.7 ignores all, sometimes even the prompts.
2. When a CSS/style fix fails to change observed behavior, the next default step should be "grep the codebase for other selectors targeting this element / its ancestors", not "verify my fix deployed."
3. When a user says "I hard-refreshed" or "this is from localhost," treat the cache/CDN hypothesis as dead. Do not resurrect it three turns later.
4. After 2 failed fixes on the same symptom, step back and re-state the hypothesis before attempting a third. (4.6 did this implicitly by reading the diff of 4.7's changes before touching anything.)
5. For git workflows, prefer explicit path staging over git add -A unless the user said "commit everything."

Token budget

Over 100k tokens spent on this one CSS bug in the 4.7 session, based on visible commands and tool outputs. The 4.6 fix in the follow-up was a fraction of that. Full Claude Code session transcript (~/.claude/projects/...jsonl) available privately on request.

Why I'm filing

I'm a Max user. I made two configuration changes today specifically to accommodate 4.7. Because over last weeks I see how hard work with Opus 4.7 is to an extent that sometimes it is just unusable. On this task 4.6 is clearly better, and that's worth knowing. To 4.7's credit, when I pushed back it acknowledged honestly: "spending 60k+ tokens on a CSS cascade bug that a single grep -rn 'nav {' src/ would've caught is indefensible regardless of model version." Agreed. Filing so the pattern gets triaged.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.139
• Feedback ID: 441c756f-eec4-4179-a91b-13d3dd10c8dc

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/mikitazhuikou/.local/share/claude/versions/2.1.139 (expected in multi-process scenarios)\n    at z16 (/$bunfs/root/src/entrypoints/cli.js:2662:2257)\n    at tRH (/$bunfs/root/src/entrypoints/cli.js:2662:1337)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-12T13:46:50.143Z"},{"error":"Error: console.error: Using Claude with claude-opus-4-6 and 'thinking.type=enabled' is deprecated. Use 'thinking.type=adaptive' instead which results in better model performance in our testing: https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking\n    at K (/$bunfs/root/src/entrypoints/cli.js:532:12767)\n    at create (/$bunfs/root/src/entrypoints/cli.js:42:206)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:9021:4881)\n    at iY6 (/$bunfs/root/src/entrypoints/cli.js:5493:2294)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-12T13:47:54.581Z"},{"error":"Error: console.error: Using Claude with claude-opus-4-6 and 'thinking.type=enabled' is deprecated. Use 'thinking.type=adaptive' instead which results in better model performance in our testing: https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking\n    at K (/$bunfs/root/src/entrypoints/cli.js:532:12767)\n    at create (/$bunfs/root/src/entrypoints/cli.js:42:206)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:9021:4881)\n    at iY6 (/$bunfs/root/src/entrypoints/cli.js:5493:2294)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-12T13:49:13.233Z"},{"error":"Error: console.error: Using Claude with claude-opus-4-6 and 'thinking.type=enabled' is deprecated. Use 'thinking.type=adaptive' instead which results in better model performance in our testing: https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking\n    at K (/$bunfs/root/src/entrypoints/cli.js:532:12767)\n    at create (/$bunfs/root/src/entrypoints/cli.js:42:206)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:9021:4881)\n    at iY6 (/$bunfs/root/src/entrypoints/cli.js:5493:2294)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-12T13:50:13.344Z"}]