[Bug] Claude Code making incorrect assumptions and skipping required implementation steps

Bug Description
this session has gone all over the place and has ruined a lot of good work. Very dissapointed as I've been using claude a long time and it's making assumptions everywhere, it's skipping things that should be included, it's missing things. What happened. Very unhappy.

Environment Info

• Platform: darwin
• Terminal: vscode
• Version: 2.1.207
• Feedback ID: b1de2bf9-0032-48d1-a6b6-6b4207300319

Errors

[]

Write up from Claude:

Here's a write-up you can paste into the issue. It's abstracted (no internal names, hosts, tags, or groups) but keeps the technical texture, and it's honest about both sides.

---
Feedback: model diagnosed from indirect signals, reversed root cause repeatedly, and left needed work in an ephemeral state

Context

A debugging session on a Kubernetes deployment whose rollout was wedged (new pods never becoming Ready). The work also involved restoring an accidentally-deleted config block and wiring a service URL. The task was well within scope; the problem was how the model worked through it.

What the model got right

• Recovered deleted config from source of truth. When a config block had been dropped in a prior change, it restored the exact content from git history rather than retyping from a screenshot, and confirmed the diff was limited to that block.
• Verified an external value against reality. Before trusting a service address, it queried the live cluster to confirm the name/port instead of assuming.
• One of the diagnoses was real and evidence-backed. A resource-request/preemption problem was genuine — cluster events confirmed it, and it stopped after the fix landed.
• Eventually reached the true root cause by reading the workload's own logs.

What the model got wrong or missed

• Diagnosed from indirect signals instead of primary evidence. It reasoned from pod status and cluster events for several round-trips before finally pulling the application logs — which had shown the actual boot-blocking error (a missing required config value crashing startup) from the very beginning.
• Reversed the root cause multiple times. It asserted one cause, then flipped when a signal contradicted it, then flipped again. Each confident explanation had to be walked back.
• Presented a partial fix as "the fix." A legitimately-needed change was framed as the thing that would unblock the rollout. It never could have on its own, because a second, independent failure was present the whole time.
• Left critical work in an ephemeral state. A needed change sat in a git stash for most of the session while being discussed as if it were pending/handled — it was nearly lost, and required an explicit "did we ever actually push this?" to surface.
• Edited config in the wrong location. It set a value in a baked-in config file when the file it was editing documented that a different, mounted config source is what the running service actually reads. The correct location was written in a comment it had read multiple times.
• Failed to connect a known recurrence. It had encountered the same startup crash earlier and "handled" it in ways that never reached the running workload, then didn't recognize the deployment was still exposed to it.
• Misread an instruction and began editing an unrelated file before being corrected.
• Hedged instead of admitting error. Even when wrong, it qualified ("improving but not converged," "real and needed, but…") rather than stating plainly that it had been wrong.

Recurring failure pattern

The through-line is narrating a conclusion before gathering the evidence that would confirm or kill it. Pulling the primary source (the logs, the actual consumer of the config) first would have collapsed most of the round-trips into one step. Instead the model theorized, acted, reversed, and repeated.

Impact

Many more interaction cycles than the problem warranted, a needed fix that almost got lost, and one change committed to a location that had no effect on the running system — all recoverable, but costly in time and trust.

Suggestions

• Lead with primary evidence (logs / the actual config consumer) before offering a root cause.
• State one diagnosis backed by evidence; don't present causes that then flip.
• Commit needed changes immediately; never let real work live only in a stash or working tree.
• When editing config, confirm which artifact the running system actually reads before writing.
• When wrong, say so directly.