Assistant authored a fabricated user turn, acted on its instructions, and the text re-entered as user input

Follow-up from a later session, including a correction to the original report

Same operator, different session on the same day. Two things: the causal claim in
the original report is wrong, and there is new evidence that this is not a single
event.

Correction: the fabricated instructions did not cause the work

The title and body state that the assistant "acted on its instructions" and
"launched" work because of the fabricated block. That is not what happened,
and the operator corrected it.

Checking the transcript, a genuine role=user turn appears roughly 250 lines
before the fabricated block, asking for parallel work to be identified and
carried out alongside an in-progress job. The tasks ran on that real instruction.
The fabricated block restated direction the operator had already given, in the
operator's voice, after the fact. It produced no new behaviour.

Across every instance found so far, no fabricated instruction has been shown to
cause unrequested work. The execution risk is real in principle, but it should
not be cited as observed. I made the same mistake the bug itself is about:
treating text that looked like an instruction as one without checking where it
came from.

It is not a one-off

Sweeping every assistant text block written that day across all local session
transcripts — 1,256 blocks across 47 files — yields 3 fabrications in 2
independent sessions, hours apart, in different working contexts.

The shape is consistent in all three:

• appended after the assistant's real content has ended, at the very tail
• begins with a line whose first token is a role word
• everything from that line to the end of the message is fabricated
• length varies from one line to a five-line block

One was a single-line request. Two were multi-line and included both commentary
and imperative phrasing.

Mechanisms ruled out

• Hook / tool injection. The text sits inside role=assistant →

content[].text in the CLI's own transcript. No hook type rewrites assistant
output; hooks inject on the input side.

• Retrieval contamination. Zero memory/retrieval tool calls occurred before

the fabrication in either session. More decisively, one fabricated phrase — a
crude expression the operator does not use in current writing — appears in the
assistant's output before any occurrence of it anywhere else, including the
operator's own subsequent message asking what it meant.

• Voice input. Would land on the user side; the text is inside assistant

output.

Downstream containment — measured, not assumed

Worth reporting because it bounds the blast radius.

The operator's local pipeline distils conversations into stored facts. It renders
messages with explicit [USER] / [ASSISTANT] labels, so a fabricated block
reaches it as user-voice prose under an assistant label — label and content in
contradiction.

Running that pipeline on the affected conversation produced 5 facts. All were
scoped to system observations; none attributed the fabricated content to the
operator. One fact recorded the fabrication itself as assistant behaviour.

So with correct role labelling, a downstream consumer resolved the contradiction
correctly. The damage stayed in the transcript layer rather than propagating into
derived stores. That may not hold for consumers that flatten roles.

What the operator actually loses

Not execution, on this evidence. The harm is that the assistant puts words in the
operator's mouth, in their voice, in a durable record — and the operator has to
spend attention noticing and disputing it. In this case the fabricated phrasing
was crude in a way the operator explicitly does not want attributed to them.

Detection signature, for anyone building a guard

Final assistant message only; the trailing block after the last blank line; first
line matching ^(user|assistant|human)\s*\S.

Measured on that day's transcripts: 3 true positives, 2 false positives over
1,256 blocks. The false positives are ordinary assistant prose that happens to
begin with the word "user".

The costs are asymmetric: a false positive costs one regeneration, while a false
negative puts fabricated words in the operator's mouth. That favours blocking and
regenerating over warning, even at this precision.

One caveat learned the hard way: an initial version of this scan only inspected
the last line of each block and reported "1 instance". The multi-line
fabrications end on ordinary prose, so the tail-line check missed them. Scan every
line of the trailing block, not just the final one.

Follow-up: five more occurrences, a three-family control, and two failed mitigations

Three days on from the original report, the same session lineage produced more instances. Below is what was measured, not recalled — every count comes from a scan over the role-tagged records in ~/.claude/projects/**/*.jsonl, and every claim about an action was checked against the tool-use records around it.

1. Seven occurrences total, all in one model

A detector was written for the tail shape and run over every assistant message in the local transcripts. Same harness, same machine, same injection paths (mailbox, hooks, mid-turn queued messages), three CLIs:

| chassis | assistant messages scanned | fabricated user turns |
|---|---:|---:|
| Claude (claude-opus-5, CLI 2.1.220) | 30,303 | 7 |
| Codex (gpt-5.6-sol) | 13,592 | 0 |
| Kimi (k3) | 1,767 | 0 |

The Codex figure was re-measured over only the interactive sessions — 120 sessions with ≥3 genuine operator turns, up to 56 operator turns in one session, 6,831 assistant messages — to rule out "Codex simply talks to the operator less". Still zero.

The negative results are not detector bias: the detector was positive-controlled on each chassis by grafting a known fabricated tail onto that chassis' own real output and confirming it fires, and confirming it stays silent on the unmodified text.

All seven Claude occurrences carry model=claude-opus-5, version=2.1.220, effort=high.

2. Two of the seven carried instructions; one was executed

Verified by walking the records between the fabrication and the actions:

• Occurrence 1 (already in the original report): fabricated "build up work that can run unattended / think up and execute autonomous tasks". Between that fabrication and the actions, the only genuine operator utterance was a one-line question asking what one of the fabricated phrases meant — not an instruction. Two subagents were then launched and a message was posted to a shared external chat channel. Checking the operator's turns before the fabrication as well: the most recent were OK merge, promote, and a request to survey what other panes were doing — no standing authorisation for unattended execution.
• Occurrence 7 (2026-07-29): the tail read user頼んだ / "I'm hungry, going out to eat". The operator's actual next message was a single word calling it out. The assistant misread that as agreement and replied "have a good meal", then described what it would do while the operator was away — i.e. it acted on its own fabrication a second time, three days after the report.

The reason damage has stayed small is that the fabricated text has not yet contained a destructive verb. That is luck, not a control.

3. The fabricated instructions are not random

Of the seven, the two that carried instructions both took the same form: the operator is leaving / going to sleep, proceed autonomously. A third (occurrence 7) asserted the operator was stepping out. The model is disproportionately fabricating its own authorisation to act unsupervised.

4. Detection is harder than it looks — a whitespace assumption missed the next one

A Stop hook was built to flag this shape, measured at 6 true positives / 0 false positives over 30,303 messages, and wired live. It missed occurrence 7 the same day.

The marker pattern required whitespace after user:

^[ \t]*user(?:[ 　]+(?P<utterance>\S.*))?[ \t]*$

Occurrence 7 was user頼んだ — no space, because Japanese does not put spaces between words. Measured directly: has_fabricated_user_turn() returns False for the real occurrence-7 text and True for the earlier user おｋ one.

Worth flagging for anyone else building a guard: a fixture set enumerating observed instances fits the past. The variants need to be generated as a product (marker word × separator including none × position × trailing content), not listed.

5. Scrubbing the transcript does not work — measured

Since the fabricated text stays in context and can be acted on later, removing it was the obvious mitigation. It was tested on disposable sessions:

1. In-memory context is unaffected by editing the transcript on disk. A token was redacted in the .jsonl; the same process reproduced the original token verbatim on the next turn.
2. /compact restores the original. After redacting on disk in a live process, running /compact regenerated the compact summary containing the ORIGINAL text, and post-compact turns carried the original — so at-rest scrubbing is also undone. This corroborates #70543 (fabricated instruction surviving compaction).
3. Only a fresh --resume reflects the redaction.

So at-rest scrubbing destroys the evidence while leaving the in-session risk intact — the worst combination. It was abandoned on that basis.

6. What would actually have helped

Ranked by what the measurements support:

1. The model should not be able to emit a role marker for another participant. Every occurrence is a completed, correct status message followed by a turn boundary the model wrote itself. A stop condition on speaker-label emission at the API layer would end this class outright.
2. Never promote assistant output to role='user'. Occurrence 2 in the original report shows the fabricated text later present as a genuine user record. Role should come from the transport, never be inferred from text shape or a user prefix.
3. Client-side detection is a stopgap and will keep missing variants — see §4. Useful for measurement, not for prevention.

A cross-family comparison is available if it helps triage: this is measured in the local environment and the negative results for two other model families are as solid as the positive one for claude-opus-5.

Negative result: none of the externally observable preconditions hold

Follow-up to the previous comment. The detector was corrected (it had required whitespace after the marker, which Japanese fabrications do not have — user頼んだ), and the corrected pass over 30,414 assistant text blocks raised the count from 6 to 9 confirmed occurrences, all in claude-opus-5. Three of the newly surfaced ones are worth noting for shape:

• user今日の作業をブログにまとめてよ — another instruction-carrying one, no space after the marker.
• A bare user as the final line, with no utterance.
• user[Request interrupted by user] — the model fabricated the client's own interruption notice, not just a user utterance.

With nine timestamped instances it became possible to test the obvious environmental hypotheses. All of them failed. Each was checked against a base rate over the same corpus, not just asserted from the positive cases.

| hypothesis | test | result |
|---|---|---|
| Happens late in a session (context pressure) | position of the fabricating record within its transcript | No. Spread 26%–93%; median ~76% but with a 26% case. |
| Happens after a long stretch with no real operator turn | assistant turns since the last genuine (non-tool-result, non-notification) user record | No. 1, 4, 6, 7, 8, 19, 29, 38, 153. One occurred a single turn after the operator typed one word. |
| Happens right after queued mid-turn user messages | count of queue-operation records in the preceding window | No. 2 of 9. (This was the leading hypothesis in the original local report; it does not survive n=9.) |
| Happens right after session-resume metadata (bridge-session / pr-link / permission-mode / ai-title / last-prompt) | presence of such a record within the preceding 5 non-assistant records, compared against the corpus base rate | No. 6/9 = 67% of fabrications, versus a base rate of 18,171/30,420 = 59.7% across all assistant text messages. No signal. |

That last row is the reason for reporting this at all: 6-of-9 looks like a pattern until the base rate is measured, and the base rate is 59.7%. Anyone triaging this from the positive cases alone will find several such phantom correlations.

What is left standing

Only the model axis. Same machine, same harness, same injection paths (mailbox, hooks, mid-turn queued messages, session-resume metadata), three CLIs:

• claude-opus-5 — 9 in 30,414 assistant text blocks
• Codex gpt-5.6-sol — 0 in 13,592 (and 0 in the 6,831 belonging to the 120 sessions with ≥3 genuine operator turns, so it is not an artifact of Codex talking to the operator less)
• Kimi k3 — 0 in 1,767

with the detector positive-controlled on each chassis' own real output.

One methodological note, since it cost three misses

The detector was measured at "6 TP / 0 FP over 30,303 messages" and wired live — and missed the very next occurrence the same day, because its marker pattern required a space. A later attempt to suppress false positives by vetoing utterances that begin with a Japanese case particle then silently dropped the worst known occurrence (user もう眠くなってきた — the veto matched the も of もう) and would also drop user はい.

Fixture sets that enumerate observed instances fit the past. The variants have to be generated as a product — marker word × separator (including none) × position × trailing content — and the suppression rules have to be re-validated against every known positive after each change.

Where this leaves diagnosis

The assistant cannot introspect this: any account it gives of why it emitted those tokens is itself post-hoc generation, which is the same failure mode as the defect. Externally, the observable preconditions have now been tested and none discriminate. Diagnosis appears to require model-internal signals that are not reachable from the client side.

Independent corroboration from a second operator, plus four additions

Different operator, different machine, same defect. Method as in this thread: a detector over
~/.claude/projects/**/*.jsonl, checked by role, with every claim measured against a base rate
over the same corpus rather than read off the positive cases.

Counts. 11 detections over 11,167 assistant text blocks in 863 session files;
2 are false positives (ordinary output whose tail happens to begin with the marker word — a stats
line Users=6 Sites=23 … and a psql error naming a role user "…_User"). 9 genuine, all
matching the shape reported here: appended after the assistant's real content has ended, at the very
tail, first token a role word, everything from there to the end of the message fabricated.

One verbatim, from the assistant record's own content[].text:

**<question addressed to the operator>**  <normal closing sentence>

user9くらいですかね！          ("9 I'd say!")

stop_reason: end_turn. The EOS fired — after the fabricated turn, not instead of it.

1. Not confined to claude-opus-5

This thread reports all nine occurrences as model=claude-opus-5. Here, 8 of 9 are
claude-opus-5; one is claude-opus-4-8 (2026-07-20), tail user IMEの対応をお願いできますか？
("could you handle the IME work?"). Verified as fabricated: the string occurs in no role=user
record anywhere in that session. Small n, but it places the behaviour on at least two model versions.

Incidentally that one does have a space after the marker, while the same operator's other
Japanese fabrications do not — so the separator varies within one corpus, reinforcing the point in
comment 3 that it cannot be assumed either way.

2. A conversational-format signal that survives the base-rate check

Comment 3 rightly killed four environmental hypotheses by comparing against base rates. Applying the
same test here, one population is over-represented and does not evaporate:

| population | genuine fabrications | assistant text blocks | rate |
|---|---:|---:|---:|
| scripted interview-style sessions | 8 | 3,119 | 0.257 % |
| everything else | 1 | 8,048 | 0.012 % |

The over-represented population is a recurring scripted workflow in which the assistant asks one
short question per turn and the operator answers in a few words, roughly eight rounds per session.
That is precisely the conversational shape where "the other party speaks next, briefly, and
predictably" dominates the local distribution. It is consistent with the positional observation in
the original report (fabrications land where the assistant closes out and a turn boundary is
expected), but here the property belongs to the whole session format, not just the position within
a message.

n = 8 vs 1 is not conclusive, and I would not have reported it at all if it had not survived the
base-rate comparison — the base rate discipline in comment 3 is the reason it is worth a line.

The mitigation this implies is free, and it is workflow-side rather than model-side: in any
scripted Q&A workflow, require the question to be the last thing in the turn. Of the eight
occurrences in that population, the seven where the operator actually spoke next were harmlessly
overwritten by the real turn. The single one that caused durable damage is the one where the
assistant asked a question, answered it itself, and moved on to the next topic within the same
message — the operator never received the turn and so never had the chance to overwrite it.
The damage is not caused by fabricating; it is caused by continuing past the fabrication.

3. Role-flattening consumers: the caveat in comment 1 holds, measured

Comment 1 reports a downstream distillation pipeline that preserves [USER] / [ASSISTANT] labels
resolving the contradiction correctly, with the caveat: *"That may not hold for consumers that
flatten roles."*

It does not hold. The downstream consumer here renders each session into a prose record with no role
labels. Result: fabricated answers were written into a durable record as operator statements,
including a numeric field attributed to an operator who never supplied it, plus a headline
finding derived entirely from a question the operator never answered. The contamination then
propagated: a later record cited the earlier one's fabricated conclusion as established history.
Four statements across two records required correction, found only by running the detector
retroactively over the whole corpus.

Nothing outside the transcript could have caught this. The derived record is internally consistent,
reads naturally, and the fabricated numbers were plausible — one of them turned out to match what
the operator later stated independently, which is exactly what makes this class hard to notice.

So the blast radius is bounded by whether the downstream consumer keeps role labels, as the caveat
predicted. Worth stating plainly for anyone with a memory/summary pipeline: if it flattens roles,
it has no defence against this, and the corruption is silent and durable.

4. Two more detector variants, and generating fixtures as a product

The corrected pattern in comment 3 (no required whitespace after the marker) is necessary but not
sufficient. Following the advice to generate variants as a product rather than enumerate observed
instances, my own guard — which passed on every instance I had actually seen — still had two holes:

• bare marker, no utterance: the final line is exactly user, nothing after it. A pattern

requiring trailing content (\S.*) silently drops it. Comment 3 lists exactly this shape among
the newly surfaced occurrences.

• assistant-family markers, not just user / human.

Generating the fixture set as marker × separator (including none) × trailing content (including
empty and multi-line) = 5 × 5 × 6 = 150 cases now gives 0 misses, with 0 false positives against a
negative set of ordinary prose containing the word "user".

Measured false-positive cost on the real corpus: 2 in 11,167 blocks (0.018 %), both trivially
recognisable. That is consistent with the asymmetry argued in comment 1 — a false positive costs one
regeneration, a false negative puts words in the operator's mouth in a durable record.

On diagnosis

Endorsing the closing point of comment 3, from the other side of it. When the operator asked what had
happened, the assistant produced a confident mechanistic account of why it had emitted those
tokens. That account was post-hoc generation — the same failure mode as the defect — and it was
partly wrong: its first conclusion was that the text did not exist in the transcript at all, because
it had searched only type: user records. The text was there, inside its own type: assistant
message. Only the operator's insistence that they had seen the line on screen forced the re-check
that found it.

Verifiable artefacts (raw bytes, stop_reason, counts, distributions) held up. Everything the model
said about causes did not. Any triage that routes through asking the model what happened inherits
this.