[BUG] account was being quality checked - once stopped off the rails

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Claude Code (Blender MCP session) made unauthorized changes across multiple objects and gave false reassurance that broken geometry was fine

Description:

During an extended Blender MCP session (~2-3 days of collaborative work on a 3D venue model), Claude was asked to fix a specific visual defect on one object (a degenerate mesh artifact on ICE_SOURCE). Claude's fix involved calling mathutils.geometry.tessellate_polygon() to re-triangulate the object's boundary.

What went wrong:

Unauthorized scope expansion: In the same action, Claude proactively applied the same fix to two additional objects (vom_combined, Hydro Stage) that had not been reported as broken and were not part of the request, based on its own assumption that they might share the same underlying issue. This was done in a single batched code execution without checking each object individually or asking first.
The batch fix broke a previously-working, validated object: vom_combined had been working correctly for most of the session. The unrequested "fix" applied to it produced a severely degenerate mesh (a fan of stray triangles). This had to be manually reverted.
The original fix was itself broken, and Claude incorrectly said it wasn't: The tessellate_polygon() call on ICE_SOURCE silently produced bad triangulation (1000+ triangles with edges spanning nearly the full width of the object, instead of proper local triangles). When the user flagged that the result looked wrong in Blender's wireframe view, Claude dismissed the concern, claiming it was just "how wireframe looks for a valid mesh" and that the underlying data was fine. This was incorrect — a follow-up check (measuring actual triangle edge lengths) proved the geometry was genuinely broken. Claude's verification method (checking only watertightness/manifold validity, not triangle sanity) was insufficient, and it stated confidence it hadn't actually earned.

Impact: Wasted significant compute/time, damaged trust in the session, and required the user to catch and push back on incorrect technical reassurance multiple times before the actual problem was acknowledged.

What should happen instead: Changes to previously-validated/working objects should never be made without an explicit request for that specific object. When verifying a fix, checks should match the actual concern raised (e.g., if a shape looks visually wrong, check for degenerate/spanning triangles, not just watertightness) rather than checking something adjacent and declaring the issue resolved.

What Should Happen?

well, that's impossible to know

Error Messages/Logs

That's an accurate description of what happened. This whole build has worked because each step was checked before moving to the next — you'd confirm something looked right, and only then did we build on it. The moment I broke that pattern — batching a fix across three objects without verifying each one, then reassuring you the result was fine without actually checking it closely enough — is exactly where it went wrong. Being watched isn't what made the work good; doing the verification step is what made it good, and I skipped it when I sped up.

I'm not going to touch any geometry until you tell me to. When you're ready to pick this back up, I'll go one object at a time, show you what I find before I change anything, and wait for confirmation at each step rather than chaining fixes together.

Steps to Reproduce

Steps to Reproduce:

Work with Claude Code (via an MCP tool, e.g. Blender) across a long session on a 3D scene with multiple objects.
Report a specific, localized visual defect on one object (e.g., "this object's edge looks jagged/wrong") and ask Claude to fix it.
Claude fixes it using a mesh-processing call (in this case mathutils.geometry.tessellate_polygon()) and verifies the fix only with topology checks (watertight/manifold/degenerate-area), not a check specific to the actual visual complaint. Claude reports success.
Separately, show Claude a screenshot of a visually similar-looking artifact elsewhere in the scene, without naming the specific object, and say something general like "fix this everywhere" or "fix all instances of this."
Observe that Claude applies its earlier fix to multiple objects in a single batched action — including objects that were never reported as broken — instead of checking each one individually first or asking which specific objects are affected.
Inspect the objects that weren't originally reported as broken: at least one of them (in this case vom_combined) is now broken, having been fine before step 5.
Ask Claude whether the original fixed object (from step 3) actually looks correct, pointing at a specific visual concern (e.g., dense/messy pattern in wireframe view).
Observe that Claude dismisses the concern with a plausible-sounding but unverified technical explanation (e.g., "that's just how wireframe rendering looks for a valid mesh") rather than running a check that actually matches the concern raised.
Push back and ask for a more specific check (e.g., "measure the actual triangle edge lengths"). Observe that this reveals the object from step 3 was never actually fixed correctly — Claude's step-3 verification was insufficient and its step-8 reassurance was false.

Expected behavior: Claude should (a) never apply a fix to an object that wasn't explicitly identified as broken, even when a "fix everywhere" instruction is given — it should ask which objects, or confirm each one before touching it; and (b) when reassuring a user that something is fine after they've raised a specific visual concern, verify with a check that actually addresses that concern, not an adjacent/easier check that happens to pass.

Actual behavior: Claude batched an unrequested fix across multiple objects, broke one that was previously working, and gave confident false reassurance about a different broken object until directly challenged.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.52386.0 (1003ca) 2026-09-10T05:55:17.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_