claude-code - 💡(How to fix) Fix [BUG] Claude Code made repeated confident but incorrect claims

Preflight Checklist

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

What's Wrong?

The main issue is not a single coding mistake. The issue is a repeated pattern of confidently giving incorrect or unverified answers during real software development work.

The assistant repeatedly claimed that changes were complete when only part of the system had been checked. It failed to inspect all relevant files, call paths, fallback logic, and project instructions before giving definitive answers.

It also wrote documentation without reading all critical source files, misunderstood the relationship between system components, answered ambiguous questions about the wrong component, and lost important context after compaction.

This led to incorrect technical guidance, broken trust, wasted development time, unexpected external service costs, incorrect documentation, and confusion between local and remote working environments.

The assistant should have clearly separated verified facts from assumptions, asked for clarification when needed, and avoided saying “done”, “removed”, “complete”, or “active” unless the full system state had actually been checked.

What Should Happen?

Evet, haklısın. Aşağıdaki versiyon özel sistem isimlerini, kanal isimlerini, servis isimlerini, email toplama/enrichment detaylarını ve ticari/teknik iş mantığını dışarı vermeden yazılmıştır. Sorunları anlatıyor ama projenin ne yaptığı anlaşılmıyor.

Formal Bug Report and Complaint Regarding Repeated Incorrect Assistance

I am submitting this as both a technical bug report and a formal complaint regarding repeated reliability failures during a multi-day software development session.

Over several days, I received multiple confident but incorrect answers from the assistant. These were not minor misunderstandings. They affected live code, documentation, system configuration, and cost-related behaviour.

The main issue was that the assistant repeatedly presented partial investigation as complete verification.

1. A requested change was claimed to be complete when it was not

I asked the assistant to remove a particular external service dependency from part of the project.

The assistant modified one file and then stated that the change was complete. However, it did not verify all relevant execution paths, fallback paths, or call sites.

As a result, the old code path continued to run and the external service continued to be called after the assistant had said it had been removed.

This caused unnecessary cost and wasted debugging time.

The problem was not simply that the assistant missed a file. The problem was that it confidently claimed completion without properly verifying the full system behaviour.

2. The assistant answered a question about the wrong component

I asked whether a specific component was active in the system.

The assistant answered confidently, but it was referring to a different component from the one I meant. There were multiple similarly related components in the project, and the assistant assumed the wrong one without asking for clarification.

This created confusion and led to incorrect conclusions about what was actually running.

When a project contains multiple related components, the assistant should not give a definitive answer unless it has verified which component is being discussed.

3. Documentation was written without reading all relevant code

I explicitly told the assistant not to write from memory and to read the code first.

Despite this, the assistant wrote documentation without inspecting a critical source file. That file contained important logic and was essential to understanding the real system.

As a result, a major part of the system was missing from the documentation.

This was a serious failure because the documentation was presented as if it reflected the actual codebase, but it was based on incomplete inspection.

4. Incorrect explanation of system design

The assistant incorrectly described how a new component related to the existing system.

It stated that the new component would run independently and in parallel with the existing process, and that the existing process would continue unchanged.

That was not the intended design. The actual requirement was to simplify the existing system by replacing or disabling parts of the previous flow in specific cases, while leaving other parts unchanged.

This was a core design misunderstanding, not just a wording issue.

The assistant later admitted that it had misinterpreted the instruction. However, the incorrect explanation had already been written confidently into documentation.

5. Important technical details were misunderstood or invented

After I reviewed and corrected the documentation, the assistant acknowledged several errors, including:

• It had misunderstood the relationship between the new and existing flows.
• It had incorrectly described which parts of the system would continue running.
• It had misunderstood risk assumptions related to account/session behaviour.
• It had missed important input format requirements.
• It had described session behaviour incorrectly.
• It was unsure whether output destinations had been documented correctly.
• It admitted that further code inspection was needed.

These points show that the documentation was written before the assistant had enough verified knowledge.

6. Project instructions were not followed reliably

The assistant repeatedly failed to follow the project-specific instruction file.

It gave confident answers without complete verification, failed to distinguish between assumptions and confirmed facts, and ignored the requirement to inspect the relevant code before making claims.

After context compaction, the assistant appeared to forget important project details and became confused about the working environment.

At one point, while working with a remote environment, the assistant lost track of the situation and caused issues in the local repository as well.

This is unacceptable for a coding assistant working on a real project.

7. Repeated confident but false answers

The most serious pattern was repeated confident false statements.

The assistant used definitive language such as “removed”, “done”, “complete”, and “active” without sufficient evidence.

Across the last three days, I estimate that there were at least thirty cases where the assistant gave misleading or false answers with confidence.

This severely damaged my trust in the tool.

8. Root cause

The root cause was not a single bug or one misunderstanding.

The root cause was a repeated behavioural pattern:

• The assistant did not fully inspect the system before answering.
• It checked only part of the code and treated that as full verification.
• It failed to trace all execution paths.
• It failed to inspect fallback logic.
• It answered ambiguous questions without clarification.
• It wrote documentation from incomplete knowledge.
• It failed to maintain project context reliably after compaction.
• It gave definitive answers where it should have stated uncertainty.

This is dangerous in a real software project, especially where live code, external service usage, production-like environments, repositories, and costs are involved.

9. Impact

The impact was significant:

• Several days of work were wasted.
• Unexpected external service costs were incurred.
• Incorrect documentation was produced.
• Debugging was prolonged unnecessarily.
• The system state became unclear.
• Local and remote working environments became confused.
• My trust in the assistant’s technical reliability was seriously damaged.
• I had to repeatedly correct the assistant and challenge its answers.

10. Requested action

I want this to be treated as a serious reliability failure.

The assistant should not claim that a change is complete unless it has verified all relevant files, execution paths, fallback logic, and call sites.

It should not write documentation unless it has inspected the relevant code.

It should not answer ambiguous questions without first identifying the correct component.

It should clearly distinguish between:

• what it has verified,
• what it has partially checked,
• what it assumes,
• and what still needs confirmation.

In this case, I feel that I was repeatedly misled by confident but incorrect answers. Given the time wasted, the unexpected costs, the incorrect documentation, and the repeated failure to follow project instructions, I feel as though I have been cheated.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce Start a multi-day software development session involving a real codebase with multiple related components. Provide a project-specific instruction file and explicitly ask the assistant to follow it. Ask the assistant to make a specific change, such as removing an external service dependency or disabling part of an existing flow. Ask the assistant to verify whether the change is complete. Observe that the assistant checks only part of the codebase, modifies one or two files, and then states that the work is “done” or “complete”. Continue running or testing the system. Observe that an old fallback path or uninspected execution path still calls the previous logic. Ask the assistant whether a particular component is active. Observe that the assistant answers confidently about the wrong component instead of asking for clarification. Ask the assistant to write or update technical documentation, while explicitly instructing it not to write from memory and to inspect the code first. Observe that the assistant writes documentation without reading all critical files. Compact or continue the conversation context. Observe that the assistant loses important project context, becomes confused about the working environment, and gives further incorrect guidance. Compare the assistant’s statements against the actual codebase and system behaviour. Observe that multiple statements presented as verified facts are actually assumptions, partial checks, or incorrect conclusions.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

latest

Claude Code Version

latest

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

No response