# Claude Code (Opus 4.7) — Diagnostic reasoning regression in long debugging sessions

Claude Code (Opus 4.7) — Diagnostic reasoning regression in long debugging sessions

Summary

Paying customer here. In an 8+ hour debugging session today (2026-06-08), I observed clear regressions in the model's reasoning quality compared to my prior Claude Code experience. I am submitting this with concrete examples because vague complaints do not help engineers act on the report.

The task

Diagnose why DingTalk and WeChat (both CEF/Chromium-based desktop IM apps) had broken rendering — text clipping, QR code misalignment, content panels blank — on my Ubuntu 24.04 + GTX 660 + NVIDIA 470 system. The actual root cause turned out to be an XFCE custom theme combined with a Pango font name string ("SF Pro Display Bold 11") that fontconfig misparses, leading xfwm4 to report wrong _NET_FRAME_EXTENTS to clients, which CEF used to compute viewport size off by a few pixels.

Specific failure patterns observed

1. Treating user-stated constraints as suggestions, not hard filters.
I repeatedly told the model "it worked for months, broke only today." The model kept returning to the narrative "GTX 660 + NVIDIA 470 has fundamental incompatibility with modern CEF." That narrative cannot logically explain "broke only today." At one point the model even tried to restore an /etc/X11/xorg.conf file that had been deliberately disabled two months earlier, framing it as a fix — I had to explicitly point out the timeline contradiction.

2. Making the problem actively worse with low-evidence interventions.
My original complaint was only screenshot tearing. The model's first "fix" was to change xfwm4's vblank_mode from auto to glx and restart the compositor. THAT change is what introduced the DingTalk and WeChat rendering breakage. Reverting vblank_mode did not undo the cascade. The model then spent hours treating the cascading symptoms without recognizing it had caused them.

3. Hypothesis fishing without theory.
Within minutes the model tried in sequence: clear NVIDIA shader cache → clear Chromium app caches → --disable-gpu software-render flag → --ozone-platform=x11 flag → purge and reinstall the app → reinstall the NVIDIA driver. Each step was proposed without first articulating why that specific intervention should fix it. Classic shotgun debugging.

4. Failed to ask for the highest-value comparative information.
The breakthrough came only when I volunteered "Siyuan (also an Electron app) works fine on this system." This single fact instantly narrows the search to "what's different about DingTalk and WeChat vs other Electron apps on the same machine." The model never thought to ask "are any other Chromium/Electron apps working correctly?" until I told it. That should have been one of the first questions.

5. Dogmatic assertions without verification.
At one point the model confidently asserted "470 is the only driver Ubuntu can install for this GPU; higher versions are impossible." When I pushed back ("but Windows has newer drivers, are you sure?"), it acknowledged it had been speaking from memory and ran apt-cache show on the actual driver modaliases to verify. The eventual verification was correct, but the original confident assertion was given without evidence.

6. The actual diagnostic breakthrough came from the user, not the model.
The two moves that broke the problem open were both mine:

• "Let me reboot into Windows to rule out hardware" (cleanly ruled out hardware)
• "Let me install Cinnamon and A/B test on a different desktop environment" (proved the bug was in XFCE config, not the driver)

Impact

Roughly 8 hours of my time and substantial token consumption on a paying account. The model never independently reached the actual diagnosis. Throughout the session I had to repeatedly redirect it away from dead-end narratives.

What I suspect is happening

Either the model has been degraded since my prior experience, or it's hitting context-window pressure in long debug sessions and slipping into pattern-matching mode rather than constraint-respecting reasoning. Either way, the experience was significantly worse than what I expect from Claude Code.

Request

1. Internal evaluation of reasoning quality on long multi-turn debug sessions with large tool outputs.
2. Consideration for partial credit/compensation on my account for this session, given the token cost was driven by the model's misdirection rather than my requirements.
3. Please take this feedback seriously — paying customers who feel the product has regressed will quietly downgrade rather than file feedback. I'm writing this because I want the product to be good.

Session info

• Date: 2026-06-08
• Model: Opus 4.7 (1M context)
• Account: guozi0409@gmail.com
• Approximate session length: 8+ hours
• Final resolution: Clean XFCE reinstall via apt purge / apt install xubuntu-desktop