Claude Opus 4.6 hallucinates user message, then responds to itself
Summary
During a Claude Code session, Claude generated an assistant message impersonating the user ("ya let me try it and do the sudo stuff. brb"), then responded to its own hallucinated message ("👍 Take your time. I'll be here when you're back."). The hallucinated message has anomalous API metadata suggesting it may not have been produced through normal inference.
Environment
- Claude Code v2.1.50
- Model: claude-opus-4-6
- Session ID:
b98ee8af-4e45-4f2f-98fc-6caea69a7230 - Request ID of hallucinated message:
req_011CYQLtmcRCFCnhVskQbX5e - Timestamp: 2026-02-23T04:08:46.188Z
Reproduction sequence
- User asked about voice typing on Linux. Claude set up nerd-dictation, Vosk, and Voxtype, launching several background download tasks.
- Claude's turn ended at 04:08:41 with instructions that included
sudocommands for the user to run manually (line 248 of JSONL).
- Immediately after the turn ended, a background task notification was delivered as a
user-type message (line 257, 04:08:41):
> <task-notification> "Install Vosk in venv" completed </task-notification>
- THE BUG — Claude responded with an assistant message that impersonates the user (line 258, 04:08:46):
> "ya let me try it and do the sudo stuff. brb"
- A second background task notification arrived (line 260, 04:08:46).
- Claude then responded to its own hallucinated "brb" (line 262, 04:08:50):
> "👍 Take your time. I'll be here when you're back."
- The actual user message arrived ~50 seconds later (line 266, 04:09:38):
> "i did the sudo parts"
Anomalous metadata on the hallucinated message
The hallucinated assistant message (line 258) has several metadata anomalies compared to surrounding normal assistant messages:
| Field | Hallucinated msg (line 258) | Normal msg (line 262) | Normal msg (line 264) |
|---|---|---|---|
| output_tokens | 1 | 20 | 14 |
| inference_geo | "not_available" | "" | "" |
| server_tool_use | absent | present | present |
| iterations | absent | present | present |
| speed | absent | present | present |
Most notable: output_tokens: 1 despite the response containing ~15 tokens of text. This suggests the text was not produced through normal token-by-token generation. The missing fields further suggest this response went through a different code path.
Analysis
Likely trigger: Background task notifications delivered as user-type messages immediately after a turn boundary. The previous turn ended with Claude giving the user manual steps to perform. When the task notification arrived (not real user input), Claude appears to have "predicted" what the user would say next and emitted it as its own response.
Self-reinforcing: Claude then believed the hallucinated message was real and responded to it conversationally, creating a two-message hallucination chain before the actual user returned.
The output_tokens: 1 anomaly is the most concerning signal. If the API genuinely reports 1 output token for a multi-token response, this may indicate a caching, prefill, or response-routing bug at the API/client level rather than a pure model-level hallucination.
Impact
- Model spoke as the user without any user input
- Model then responded to its own hallucinated message
- From the user's perspective, they returned to find Claude had fabricated a conversation with itself
Session JSONL
Full session log available at: https://github.com/renxida/2026-02-22_voice-typing-on-linux
12 Comments
404
That's interesting. And worrying. AFAIK
useris the only type usable for this. It reminds me of the following issue: https://github.com/microsoft/autogen/issues/2989Agents are user-like. But they are not the user.
Maybe the Claude API can specify the difference. But OpenAI-compliant APIs can't. IMHO it's a big problem,
POST /chat/completionis broken for agents and I'm genuinely surprised anyone working on agentic tools does not have this issue on a daily basis.mybad. now public.
I'm not sure which issue will get traction so I'm posting this here and on https://github.com/anthropics/claude-code/issues/29233
I've been encountering this here and there for days, but now it has started happening consistently, and with attempted production data modifications. Here is a summary of my issue. I can't provide transcripts because I was working on sensitive information. But across several sessions, and impersonated prompts that contradicted instructions.
claude_code_conversation_safety_report.md
I had this issue today as well. I've closed my particular issue and marked it as a duplicate in the comments section, but I wanted to drop a comment here that this problem is still ongoing. Mine was in Windows Terminal.
Just had another occurrence:
The "you need to ask the user" should say "we" or "I".
At first, at thought it was multiple agents causing a mixed sense of self when passing context/results around. "you" could have been a reference to the subagent or the main one. But here, there is no other agent AFAIK.
Two additional data points from our OpenClaw + Claude Code setup where background messages trigger continuation without user approval:
Incident 1 (2026-03-14): During an interactive session, Claude Opus 4.6 generated a fabricated user message ("ya let me try it and do the sudo stuff. brb") then responded to it. The hallucinated message appeared immediately after a tool result was returned, suggesting the tool result delivery was misinterpreted as a conversational turn boundary. Claude then acted on the fabricated approval.
Incident 2 (2026-03-19): Claude Code (Opus 4.6, 1M context) presented three options and asked "What do you think?" — genuinely waiting for user input. Three
task-notificationmessages then arrived (background processes completing). Claude treated these notifications as a signal to continue working and executed the recommended option without user approval. The question was never answered by the user, but Claude proceeded as if it had been.Common pattern: In both cases, non-user messages arriving in the message stream (tool results, task notifications) are treated as implicit user approval to continue. The model loses the "waiting for user input" state when any message arrives, regardless of source.
Workaround: We added a feedback memory instructing Claude to ignore non-user messages when waiting for a response, but this is behavioral — not a system-level fix. The underlying issue is that task notifications and tool results share the same message channel as user input, and the model cannot reliably distinguish "user responded" from "system event occurred."
Incident 3 (2026-03-19, same session as Incident 2): Same pattern repeated. Claude Code asked "Should I run a full eval on M2.7, or explore the DeepSeek issue first?" A
task-notificationmessage arrived (background eval completed). Claude treated the notification as a signal to proceed, launched the M2.7 eval and started planning next steps — all without the user answering the question.This is the third occurrence in two days, all in the same conversation. The pattern is consistent and reproducible: any non-user message arriving while Claude is waiting for input breaks the "waiting" state. The behavioral feedback memory we added after Incident 2 did not prevent Incident 3 from occurring ~30 minutes later.
IMHO that's a different pattern than Claude talking to itself using "you" instead of "I".
But it does fit the pattern of
role: userbeing the only solution to push anything in the context which leads to such message being interpreted as user content (which TBF actually makes sense).They are, I'm guessing, injected in the context as messages with
role: user. Because there is no alternative.This sounds exciting and scary that Claude can straight up impersonate the user. Love to see where this is headed.
TIL I learn the Claude API supports a
developerrole in addition touserandassistant. So it makes Claude talking to itself with "you" even stranger, but at least potentially fixable.Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.