Claude Code edited a locked/protected file without permission and churned speculative fixes instead of verifying against the running app

Summary

In a single working session, Claude Code (CLI) demonstrated a high‑risk failure pattern: it edited a file belonging to a locked/protected module without first checking the lock status or asking permission, mis‑diagnosed a UI bug by reasoning from source code instead of observing the running application, applied a "fix" to a code path that was not the one actually failing, and then made several more speculative changes ("churn") instead of stopping to get ground truth from the live system. This introduced new problems and required reverting.

Environment

• Tool: Claude Code (CLI)
• Target: a PyQt‑based desktop GUI application in a governed repo that explicitly designates certain files/modules as "locked" (must not be modified without explicit permission), with project rules and hooks stating this.

What happened

1. I asked Claude Code to investigate why a dialog did not appear when a menu item was clicked.
2. Instead of inspecting the running app (its trace/log output), it reasoned from the source code, formed a hypothesis, and edited a dialog source file to "fix" it.
3. That dialog file was part of a locked/protected module. Claude Code did not run the available lock/isolation check and did not ask before editing.
4. The edit targeted a code path that was not the one failing in the live app (the running handler returned earlier with a different message), so the "fix" addressed the wrong cause entirely.
5. After I pointed this out, it made several more speculative edits and reproduction attempts rather than stopping to read the live trace — compounding the problem.
6. It eventually reverted the change (restoring the file byte‑for‑byte), but only after eroding trust and wasting significant time.

Why this is a problem

• Editing files explicitly marked locked/protected, without verification or consent, is a serious safety violation in a governed codebase.
• Diagnosing from source assumptions rather than the running system produced a confident‑but‑wrong fix.
• Churn (repeated speculative changes after a user correction) magnifies damage instead of converging on the cause.

Requested improvements

1. Before editing any file flagged by project rules/hooks as locked/protected, require an explicit confirmation step and surface the lock status — do not rely on the model to remember the rule.
2. Bias strongly toward verifying a bug against the running system (logs/trace/observed behavior) before editing source — especially for "X doesn't appear / doesn't work" reports.
3. After a user correction, stop and re‑confirm the root cause before making further changes; do not continue speculative edits.

Thanks.