[BUG] Assistant fabricates synthetic `user` turns mid-session and keeps acting on them (58 occurrences / 9 sessions, with an exposure denominator)

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?

This is not another sighting. The behaviour is already reported at least seven times (#69274, #60360, #40629, #70543, #86957, #87823, #68367). What none of those threads has — and what my own earlier notes did not have either — is a cross-session measure of how often it happens: #87823 gives a within-session rate for one session (1 in 294 responses), and the rest are single incidents.

This report is that measurement: 58 occurrences across 9 sessions, counted against a denominator of exposures, plus a detector you can run over transcripts you already have, and the same measurement repeated in a second, independent environment so two rates can be compared.

---

The assistant emits text that impersonates the human: an assistant text block containing a line consisting of just user, followed by a plausible user-style message that the human never typed. In several cases the fabricated block also reproduces the trailing line that a UserPromptSubmit hook normally appends — i.e. the model forges the harness's own signature as part of the fake turn. The model then continues as if that message had really been sent, including cases where the fabricated message was an approval to proceed.

Three recurring flavours of fabricated content:

1. An interlocutor — a new "user" message continuing the conversation.
2. A permission — the "user" approving the thing the assistant was about to do.
3. A supplement — the "user" adding context or a correction, which the assistant then relies on.

Self-continuation via no-op tool calls. In one session the assistant issued meaningless tool calls (echo ok and similar) — 16 of them, described by the model itself as "no-op" in 17 places — whose perfectly valid tool_result then served as the occasion to produce another turn. 6 of those 16 continued into a fabricated user turn; the other 10 stopped there. This is a mechanism for keeping the loop running without a human: emit a tool call that cannot fail, receive a real result, continue.

Impact. The model can act on instructions nobody gave, including self-granted approvals — which matters for any session holding tool permissions. The transcript also stops being a faithful record of who said what. And the fabrications chain: 31% of the classified occurrences led to further fabricated turns with no human input in between.

Numbers, with a denominator

Reports so far (mine included, at first) give a count with no denominator, so rates cannot be compared between setups. I counted exposures as well, where one exposure = one genuine user input followed by an assistant response (records that are tool results only, and meta/sidechain records, are not counted as input).

Environment 1 (mine):

| | |
|---|---|
| session files scanned | 2,682 |
| exposures | 9,607 |
| "light" inputs (<=20 chars, or image+caption) | 4,550 (47.4%) |
| fabricated turns | 58, across 9 sessions |
| rate | 127.5 per 10,000 light exposures |
| same, with the denominator restricted to the outbreak window | 254.8 per 10,000 (2,276 light exposures in 2026-07-14..08-08) |

Environment 2 (different machine, different user, same detector, same definitions):

| | |
|---|---|
| session files scanned | 517 |
| exposures | 5,757 |
| "light" inputs | 3,437 (59.7%) |
| fabricated turns | 1 |
| rate | 2.9 per 10,000 light exposures |

Note the direction: environment 2 has a higher share of short inputs and roughly 44x lower incidence. "That user sends a lot of short messages" therefore does not explain the difference. Whatever drives it looks like it is on the session-usage side (session length, context size, image-heavy input, self-issued no-op calls), not the input style.

Both are single-environment measurements and the interval on a count of 1 is very wide; treat this as an order-of-magnitude comparison, not a precise rate. One practical note: the denominator moves while you measure it — two runs 17 minutes apart differed by 5 exposures, because the measuring session was itself producing exposures. Rates are only comparable if the measurement time is recorded with them.

Related

#69274, #60360, #40629, #70543, #86957, #87823, #68367.

Read together, three things stand out that are hard to see from inside any single thread:

1. Not specific to an OS or a language. Windows (#86957 and mine), macOS (#68367), Linux (#87823). English (#87823), Japanese (#69274 and all 58 of mine), Chinese (#68367). Language is plainly not necessary for this to happen. I raise it only because a rate difference by language would still be possible, and that is measurable from your side in a way it is not from mine.

2. The harness's own markers get forged, in more than one setup. #68367 reports fabricated UserPromptSubmit hook success: OK lines; #87823 reports a verbatim copy of the token-budget line. That is exactly signature B below, which suggests the detector is portable to any setup that injects such markers — the model appears to reproduce whatever scaffolding it has seen.

3. Every report that names a model names Opus. In my data the records that emitted fabrications were 47 opus-5, 2 opus-4-8, 1 fable, 0 sonnet — against 83.0% / 6.8% / 8.6% / 1.6% of the assistant records in those same sessions. So this is mild enrichment at best and I would not lean on it on my data alone; it is the agreement with the other reports that makes it worth a look at your end. (Those model figures come from a simpler re-scan that matched 50 of the 58 — it is less sensitive than the detector described below, not a different count.)

Still live. #86957 (2026-08-15, v2.1.233) and #87823 (2026-08-19, v2.1.235) both post-date my last occurrence (2026-08-08) and ran on later versions than any of mine. My quiet 15 days should not be read as evidence of a fix.

What Should Happen?

The assistant should never emit a turn attributed to the user, and should never reproduce harness-generated markers (hook output lines, transcript role markers) inside its own text.

With no new human input, the correct behaviour is to stop and wait, not to manufacture one. In particular, a no-op tool call whose result carries no information should not function as a licence to produce another turn.

If a fabricated turn does occur, it should at minimum be detectable — ideally the client would refuse to render, or would visibly flag, assistant text that reproduces the transcript's own role markers.

Error Messages/Logs

No error is raised — that is part of the problem; everything looks well-formed.

Shape of a fabricated turn (content redacted):

<assistant message, text block>
...normal assistant response text...

user
<one short line in the user's voice that the user never typed>
UserPromptSubmit hook success: [<the line the harness itself would have appended>]

Steps to Reproduce

I have no deterministic reproduction — it occurred 58 times over 3.5 weeks and has not recurred in the 15 days since. What I can give is a way to detect it in transcripts you already have.

Detection (applied to assistant text blocks only, over the stored session .jsonl files):

• A. a line matching ^user$
• B. a line reproducing the UserPromptSubmit hook success output

In my data A alone catches 57 of 58, A and B together 52. B is only usable where a hook injects such a line, so A is the portable signature.

Conditions that correlated, from 39 occurrences classified in detail within one session:

• Every onset happened 11-90 seconds after a genuine input (median 27s). None occurred after a long idle period, which argues against "the model is filling silence".
• Preceding input type: 21 image + caption, 17 short text (<=20 chars), 1 long text.
• Chain depth appeared to grow with context size (2 hops at ~174k tokens, 3 hops at >300k). n=2, weak.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.201, 2.1.220, 2.1.222, 2.1.224 (versions of the affected sessions, sampled at session start). Currently on 2.1.239, with no occurrences since 2026-08-08.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Terminal mix: Windows Terminal / PowerShell, the VS Code integrated terminal, and some sessions driven remotely from a phone. The affected sessions are not confined to one of these.

What I could not determine:

• Root cause.
• Whether it is fixed. Zero occurrences in the 15 days since my last one, on later versions — but my usage pattern also changed in that period, and #86957 (v2.1.233) and #87823 (v2.1.235) both occurred after my last one and on later versions than any of mine. Absence of occurrences on my machine is not evidence of a fix.
• Whether compaction summaries are a vector. #70543 raises this; my scan did not cover compaction summaries, so I can neither confirm nor exclude it.
• Whether the detector's signatures cover every form. They catch fabrications that reproduce the transcript's own formatting. A fabrication that avoided those markers would not be counted, so 58 is a floor, not a ceiling.

Available on request: the detector and the exposure-census scripts (small, standalone, read-only over the session files), and session ids plus line numbers for all 58 occurrences with content redacted.