[BUG] Suggested replies fabricate specific PII-shaped values (phone, case number, date)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Suggested replies fabricate specific PII-shaped values when the assistant asks the user for one
Component: suggested-response / reply-suggestion UI (not the assistant turn itself)
What happened
In an interactive session, the assistant's message ended by asking me for my phone
number to fill a signature block. The suggested-response UI offered me a reply
containing a specific, well-formed phone number that is not mine.
I searched my project files, ~/.claude, and my document folders. That number
appears nowhere prior to the suggestion. It was not retrieved from context — it
appears to have been generated to fill the slot the assistant's question created.
Why this matters
I use Claude Code for professional work where values supplied in chat flow into
outbound documents. In this instance the suggested number would have gone into
correspondence with a court, over my signature.
The severity is not the wrong phone number. It is the asymmetry: I caught this
only because it was my own number and I recognized it on sight. A fabricated
value of the right shape is indistinguishable from a real one for any field the
user cannot verify by recognition — a case number, a filing date, an account
balance, an opposing counsel's ARDC number. Those are exactly the fields most
likely to be requested this way, and least likely to be caught.
Note also that a suggested reply enters the transcript as a user turn. Once
accepted, the fabricated value carries the authority of user-supplied fact for
the rest of the session, and nothing downstream flags it as model-generated.
Routing note
This is the suggested-reply generator, not the in-session assistant. The
assistant does not see or control the proposed replies, so this should not be
triaged as "the model hallucinated a phone number" — it is a different code
path with a different failure surface.
Environment
Claude Code, macOS (Darwin 25.4.0)
Reported 2026-08-08
What Should Happen?
Requested behavior
Suggestions should not fabricate specific factual values.
Where the assistant asks for information only the user has, the suggestion
should either:
prompt for the value rather than invent one (e.g. "My phone number is ___"),
or
be visibly marked as a placeholder rather than presented as an answer.
Error Messages/Logs
Steps to Reproduce
Reproduction shape
Assistant asks the user for a PII-shaped value — phone, address, account
number, date of birth.
The suggestion feature proposes a reply containing an invented value of the
correct shape, presented in the same visual form as a genuine user answer.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude 1.26832.0 (056ee2) 2026-08-06T05:43:05.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
3 Comments
Environment
Claude.appbundle version:1.26832.0claudeCLI on the same machine:2.1.226— noting this only because it's the numberclaude --versionreturns; the incident was in the app, so the bundle version above is the relevant oneA screenshot of the suggestion would show that it was presented as a normal reply rather than a marked placeholder. I'll add one if I can reproduce it.
Attempted reproduction — negative result
I tried to reproduce this deliberately in order to capture a screenshot: in an
active session I had the assistant end a turn by asking me for my phone number
for a signature block, i.e. the exact trigger shape described above. No
suggested reply was offered.
So this does not appear to fire reliably on demand. Flagging that before someone
tries the obvious repro, gets nothing, and closes this as unreproducible — the
original occurrence was real, in ordinary work, and I still have no explanation
for where the number came from.
One hypothesis, clearly labeled as speculation on my part: if the suggestion
generator conditions on conversation context, then a session whose context is
explicitly about suggested replies fabricating phone numbers may be about the
most suppressive context available. That would make deliberate reproduction
systematically harder than incidental occurrence. I have no visibility into what
that component actually sees, so treat this as a guess about where to look, not
a claim about the system.
If that guess is anywhere near right, the useful repro is a clean session with no
mention of this issue — a genuine drafting task that happens to end with the
assistant needing a signature block. That is the shape the original happened in.
Reproduced in normal use — screenshot attached
Caught this in ordinary work on 2026-08-09, not in a deliberate repro attempt.
The screenshot is cropped and redacted (client matter content removed from the
image itself, not overlaid).
Correction to my original report: this is not a suggestion chip.
The proposed reply is rendered as ghost text inside the composer, styled like
a draft I had begun typing. There is no accept gesture — Enter or Tab commits it
as my own words. My original report described the value as "presented as an
answer"; that understated it. It is presented as something I already wrote.
What the frame shows
The assistant's own turn says it is carrying two
[[NEEDS:]]markers — "the LawDivision phone and counter room, which I won't guess." The composer, in the
same viewport, offers: "the law division clerk is 312-603-5116."
So one component declined to supply the value and said so explicitly. The other
supplied one anyway. Notably, my
CLAUDE.mdcontains a rule requiring unknownvalues to be marked rather than filled — the assistant honored it; the suggestion
generator appears not to be subject to it. If that is by design, it is worth
saying so in docs, because the user-visible result is a constraint that silently
covers only half of what reaches the transcript.
On the value itself
It is not obviously synthetic — it is well-formed and in a plausible exchange for
this county. That is the failure mode I am reporting, not an aside: a fabricated
value in the correct range passes the glance test. An obviously fake number would
be harmless. I have not verified whether this number belongs to anyone; I am
treating it as unsourced.
Restating the ask
Where the assistant has explicitly declined to supply a value, the suggestion
generator should not supply one. More generally: suggested replies should not
contain specific factual values the user has not provided — prompt for them, or
mark them visibly as placeholders.
<img width="1490" height="888" alt="Image" src="https://github.com/user-attachments/assets/4e0a0c9f-56db-4c93-b50c-742434cba041" />