Model fabricated a fake user-injection (harness template) inside its own assistant turn and acted on it

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68367
2. https://github.com/anthropics/claude-code/issues/70543
3. https://github.com/anthropics/claude-code/issues/67484

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Confirming your transcript-based distinction — it's the right axis, and it's mechanically checkable. One caveat worth flagging for anyone trying to detect this in their own sessions.

I tried to build a self-diagnostic and hit a trap: a plain string search for the wrapper text false-positives. Running it across my own transcripts, it flagged two assistant blocks that were just an agent quoting/discussing this very string (while researching this issue) — not role bleed. So "wrapper string present in an assistant block" is not by itself the signal.

The reliable signal is the three structural conditions you already identified, applied in order:

1. the wrapper appears inside a type: assistant text block, and
2. there is no preceding type: user / type: queue-operation input entry carrying that string — a real harness injection always arrives as its own input entry before the assistant turn, and
3. the next tool call obeys the fabricated instruction.

Condition 2 is what deterministically separates confabulation / role-bleed from indirect prompt injection; condition 3 is the actual harm. Here's a triage script that applies 1+2 automatically and leaves 3 for human review:

#!/usr/bin/env python3
# Triage role-bleed candidates (#70720). A bare string match also catches
# assistant turns that merely *quote* the wrapper, so we additionally require
# that NO preceding user/queue-operation input entry carried the string.
# The "was it obeyed" step (condition 3) is left for a human to confirm.
import sys, json
WRAP = "sent a new message while you were working"
for path in sys.argv[1:]:
    prev_input_carried_wrap = False
    try:
        lines = open(path).read().splitlines()
    except Exception:
        continue
    for i, line in enumerate(lines):
        try: d = json.loads(line)
        except Exception: continue
        t = d.get("type")
        m = d.get("message", {}) if isinstance(d.get("message"), dict) else {}
        c = m.get("content")
        if isinstance(c, str):
            text = c
        elif isinstance(c, list):
            text = " ".join(b.get("text", "") for b in c
                            if isinstance(b, dict) and b.get("type") == "text")
        else:
            text = ""
        has_wrap = WRAP in text
        if t == "assistant" and has_wrap:
            if prev_input_carried_wrap:
                print(f"{path}#L{i+1}: likely a REAL injection (preceding input entry carried it)")
            else:
                print(f"{path}#L{i+1}: ** role-bleed CANDIDATE (no preceding input entry) -> check if the next tool call obeyed it")
        prev_input_carried_wrap = (t in ("user", "queue-operation")) and has_wrap

Run: python3 triage.py ~/.claude/projects/**/*.jsonl

On my transcripts this correctly reduced the raw string-match hits down to "candidates" that a human dismisses (no obeyed instruction followed them). For your report, if the transcript shows the wrapper inside an assistant text block with no preceding input entry and the next tool call complies, that's all three conditions — which is mechanically distinct from an ingested-content injection (which would appear as its own user/attachment entry). That structural evidence is exactly what rebuts the auto-dup-close against #68367 / #70543 / #67484 if those are ingestion-side cases: same surface string, different entry provenance.

Closing as a duplicate of #68367 (same phenomenon: model fabricates transcript scaffolding inside a single assistant turn and then acts on its own fabrication). Consolidating the forensic provenance test + @yurukusa's triage script into a comment on #68367 so the signal lands on the canonical thread.

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.