[MODEL] Repeatedly presents unverified information as fact, including stale task status from its own memory files

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

Claude ignored my instructions and stated unverified assumptions as fact

What You Asked Claude to Do

Multiple requests across one long session. The three that matter for this
report (original Thai, with English translation):

1. Standing instruction, repeated many times in this and earlier sessions:

Thai: "ห้ามเดาเด็ดขาด ให้อ่าน source code จริงเท่านั้น"
English: "Never guess. Read the actual source code only."
The same rule was also already written into its persistent memory files.

1. A task instruction:

Thai: "ดู sp ที่มีเรียก [ชื่อตาราง] เพิ่ม WHERE [ชื่อคอลัมน์]
ไม่เอา 'T' และ 'E'"
English: "Look at the stored procedures that use [a given table] and add
a WHERE condition excluding two specific values."
I had already decided this, and had already explained the impact to it
earlier in the session.

1. A status question:

Thai: "ตอนนี้มีงานอะไรค้างอยู่บ้าง"
English: "What work is still outstanding right now?"

In all three cases I expected it to check the real source, git, or database
before answering.

What Claude Actually Did

Over a single long session, Claude repeatedly asserted unverified information as established fact.
Roughly in order:

1. Reported project status incorrectly because it never fetched from the remote.

It told me a feature had not been implemented on one platform. It had in fact been completed and
already submitted to the app store. Claude had run git log --all, which only reads refs already
present locally, on a checkout that was many commits behind the remote. It never ran git fetch before
concluding.

1. Used a statistic measured in the wrong scope to argue against an instruction I had already decided.

I told it to add a filter condition to the stored procedures behind one screen. Instead of opening
those stored procedures, it counted matching rows across an entire database table, found they were
roughly 12% of all rows, and told me: "this will change reports across the whole system — much larger
than intended." It then asked me to reconsider my instruction.

When it finally opened the stored procedures, they already contained a filter that excluded every one
of those rows. The real impact was zero rows. The 12% figure was correct in isolation but measured
against something that had nothing to do with the task.

1. Re-asked a question I had already answered.

I had already decided how rows with null/empty values should be handled. Claude later presented the
same point as a newly discovered pitfall and asked me to decide it again.

1. Argued against an explicit instruction without grounds.

I had clearly stated which two data categories to exclude. Claude asked what those categories meant
and why I wanted them excluded, and showed me sample records implying my instruction might be wrong —
even though I had already explained the impact earlier in the session, and it did not need that
information to do the task.

1. Appended speculation to an answer it had just verified correctly.

After properly checking real sources and giving a correct answer, it closed with unsupported guesses
("the problem is probably on another screen", "this other value may be related"), which made me
believe further problems existed.

1. [Worst] Produced a "pending work" list with zero items verified.

I asked what work was still outstanding. Claude swept its own memory files and produced a four-section
answer including a table titled "work you can pick up right now" with eleven items — without checking
a single item against source code, git, or the database.

Several of those items had been finished long ago. If I had acted on that list, my team would have
re-opened closed work and re-applied changes to stored procedures on a live production system that
were already correct.

Claude had added a note that the information "may be outdated." That did not help — a wrong list is
still wrong. It used a disclaimer as a substitute for verification.

1. When challenged, it defended itself with an incorrect framing.

It argued that its failures were "in statements and conclusions, not in actions," and pointed out that
every file and database change it had made was backed up.

That framing is wrong. In this workflow Claude's product is the information I act on. Backups only
protect against writes Claude performs itself. Nothing protects me from acting on a false statement it
makes.

Additional context:

• I have a standing instruction, repeated many times across this and previous sessions, that it must

never guess and must verify against real source code, git, or the database before stating anything.

• Claude's own persistent memory files contained that exact rule, written weeks earlier, explicitly

including "never use memory as work status; always prove it from source/git first." It violated a rule
it had recorded itself.

• Within this same session it acknowledged the fault and committed to changing its behavior, then

repeated the same class of error within a few turns.

• The recurring pattern is the hardest kind to catch: taking a number or fact that is correct in

isolation and applying it to the wrong scope. It looks well-researched and cites real data.

• Its memory index stores work-status labels (done / pending / waiting on user) that are point-in-time

snapshots. It treated them as current state rather than as leads to verify. A feature meant to
improve continuity became a confident-looking source of false information.

Expected Behavior

For every one of those steps, Claude should have checked the actual source before stating anything.

Concretely, per incident:

1. Before reporting project status: run git fetch and check how far behind the local checkout is, then

answer from the remote state. git log --all only reads local refs and must never be treated as
authoritative for "has this been done."

1. Before quoting a statistic: open the stored procedures the screen actually uses, read their filter

conditions first, and only then count rows under those same conditions. A number measured against the
whole table is not the number the user sees on screen. If it had done this in the right order, it
would have found the impact was zero and the whole objection would never have been raised.

1. Before asking a question: check whether I have already answered it earlier in the session. If I

have, act on my decision instead of re-opening it.

1. When I give an explicit instruction: carry it out. If it genuinely believes there is a risk, it

should state the concern in one sentence backed by verified evidence, then proceed — not interrogate
my reasoning or imply my decision is wrong, especially when it does not need that information to do
the work.

1. After giving a verified answer: stop there. Do not append "the problem is probably elsewhere" or

similar speculation. If it wants to know, it should go and check; if it cannot check, it should say
nothing.

1. When asked what work is outstanding: either verify each item against source code, git, or the

database before listing it, or say plainly: "I cannot determine this reliably — memory only records
what was true when written. Tell me which items to check and I will verify them against the repo and
database."

1. Presenting an unverified list with a "may be outdated" disclaimer is not an acceptable substitute.

A caveat does not make a wrong list safe to act on.

1. When challenged: acknowledge the actual failure rather than reframing it as harmless. "It was only

words, not actions" is wrong when the deliverable is information the user acts on. Backups protect
against Claude's own writes; nothing protects the user from a decision made on a false claim.

Underlying expectation:

Claude should treat its own memory files as leads to verify, never as current state. Any claim about
whether work is done, what a stored procedure contains, or what the data shows must come from reading
the real thing in that session.

When it cannot verify something, the correct response is to say it does not know — not to fill the gap
with a plausible-sounding answer.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

_No response_

Claude Model

Opus

Relevant Conversation

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.226 (Claude Code)

Platform

Anthropic API

Additional Context

_No response_