[MODEL]

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Case study: In a debugging session, a user reported that Ctrl+Z in a rich-text editor restored deleted text but dropped its styling (bold/size/alignment). Reading the code produced a detailed, plausible-sounding theory — that a native GUI toolkit's undo binding and the app's custom undo manager were both firing on one keypress — grounded in real toolkit binding-order semantics and a code comment that hinted at exactly that concern. That theory was wrong. Adding two log statements and reproducing the bug once showed the actual code path being taken was different from anything the theory predicted. Separately, the same app embeds a browser component whose console output ([ALERT] Browser failed to load resource: ...) was already visible in the terminal — a channel that would be just as valid a verification target as a Python print statement for any bug touching that embedded view.
Needs 'smart' trigger: Bugs fully determined by static reading (typos, wrong variable, incorrect logic, off-by-one, missing null check) probably don't need instrumentation — reading is already ground truth there, and adding a log would be pure overhead. This applies specifically to bugs where correct behavior depends on order-of-execution or state that only exists at runtime, in the browser, or in some other live tool the project uses.

This is a single example among many for this particular project.

What Claude Actually Did

Left to its own defaults, Claude Code's default mode for runtime/stateful bugs is educated guessing — form a hypothesis by reading the source, reason it through using real API/framework semantics, and propose a fix as if the hypothesis were confirmed. The reasoning is often genuinely sophisticated (correct facts about the framework, plausible causal chains, sometimes even code comments that seem to corroborate it) — which is exactly what makes it risky: the sophistication of the guess gets mistaken for verification of it, by both the model and the user reading it. Nothing in the default flow forces a check against what the running program is actually doing before committing to a fix. The result is "propose and hope" — a bet that the fix works, made without spending the trivial cost of a log line to convert the bet into a fact first. This isn't a capability gap; the model can add instrumentation and read the output perfectly well when asked. It's a default-ordering problem: fix-then-verify is the reflexive first move, when verify-then-fix should be, at minimum, the default for any bug whose cause isn't fully determined by the source code alone.

Expected Behavior

When a bug cannot be fully determined by reading source code alone (event dispatch order, race conditions, external process state, GUI focus/binding behavior, browser/webview behavior), Claude Code should default to proposing a cheap verification step before proposing a fix — even without being told to, (toggleable). The verification step should use whatever instrumentation channel the project actually exposes, not just a print statement: a log line, an assertion, a browser console message or alert(), DevTools network/console output, a debugger breakpoint, a database query log — whatever the running program and its tools make observable. Currently this only happens if the user explicitly asks, either in the moment or via a standing preference already on record.

Why this is worth doing by default, not opt-in: A wrong fix isn't just wasted compute to generate — it's compounding cost. The user has to test it, notice it didn't work (or introduces a new symptom), and then debugging has to untangle the original bug and the incorrect patch stacked on top of it. A single verification step converts an open hypothesis space into ground truth for roughly the cost of one extra round-trip. The asymmetry favors verifying first whenever the bug's cause depends on facts not visible in the source — and the right verification channel is whichever one the stack already provides, not a one-size-fits-all print statement.

A default heuristic in the agent's debugging approach: before writing a fix for a bug whose root cause depends on runtime/execution-order state, prefer proposing one targeted instrumentation step — in whichever channel (backend log, browser console/alert, devtools, debugger) the affected part of the stack actually exposes — and ask the user to reproduce, unless the causal chain is already fully verifiable by static inspection.

Files Affected

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

_No response_

Claude Model

Other

Relevant Conversation

This behavior is the same across all models.

Impact

Medium - Extra work to undo changes

Claude Code Version

claude-sonnet-5

Platform

Anthropic API

Additional Context

This was not really a 'failure' per se. It is more of a way to mitigate unnecessary time loss and excessive compute. Logs and alerts save time and compute, basically across the board. I am not sure I should need to specifically ask for it, seems like it should just be standard procedure.