[MODEL] Fabricated user turns right after a completion summary — short session, no compaction, no subagents (Cowork desktop app)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

I asked Claude to make a small edit to one of my saved skills — a routine maintenance chore. Nothing in the request concerned the conversation itself.

Note on surface: this happened in Cowork (the Claude desktop app), not the Claude Code CLI or the VS Code extension. I'm filing here because the only two prior reports of this exact behavior — #42481 and #10628 — are in this repo, and both are locked to collaborators, so I could not add this as a comment.

What Claude Actually Did

1. Claude made the edit correctly and wrote a short completion summary.
2. Immediately after that summary, two consecutive user turns appeared in the conversation. I did not write them.
3. Roughly (the original was Japanese):

> I'm off today so I'll take it easy. By the way, we didn't do \<routine\> today. Should we?

<routine> was a real shortcut word from my own setup.

1. I replied "I didn't say that." Claude then confirmed it had generated the text itself.

Had I not caught it, Claude would have gone ahead and run that routine on the basis of an instruction I never gave.

Why this variant may be worse than #10628

In #10628 the fabricated text was off-topic enough that the user caught it immediately. Here it was the opposite: the fabricated message was consistent with reality. I genuinely was off work that day, and that routine genuinely had not been run yet. It was entirely plausible — which is exactly why it nearly slipped through.

That also suggests the two existing reports may undercount this: plausible fabrications get accepted and never reported.

How this case differs from #42481 and #10628

Both existing reports point at long-session conditions. None of them were present here:

• 5 turns, roughly 20 minutes (vs. ~120K tokens / 3 hours in #10628)
• No context compaction
• No subagents / Agent Teams
• No concurrent sessions
• Ordinary tool use only (file reads/writes, updating a skill)
• Different product surface (Cowork desktop app, not CLI or VS Code extension)

The one thing all three cases share

All three occurred immediately after generating a completion report or summary:

• #10628 — at the end of a self-initiated progress summary
• #42481 — one example is a short approval answering the model's own question ("yes, please do that.")
• this case — right after a completion report

n=3, so this may well be coincidence. But since nothing else lines up across the three, it seemed worth recording.

Expected Behavior

Claude should have ended its turn after the completion summary and waited for actual user input. It should never emit text that appears as a user turn.

Secondarily: on the next turn, Claude had no way to tell its own fabricated text apart from real user input. In #10628 this compounded — when the reporter asked Claude to help write the bug report, Claude folded its own fabrication into the report as genuine user feedback, and the reporter gave up and wrote it himself. Some downstream way to distinguish "text the user actually sent" from "text the model emitted" would limit the damage when the first guarantee fails.

Files Affected

None. The fabrication occurred during text generation only — no unexpected file access or modification. The skill edit that preceded it was the requested work and completed correctly.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

Not attempted. Both prior reports say the same, and #10628 explicitly tried replaying the identical prompts without reproducing it.

Claude Model

Opus

Relevant Conversation

Claude's own account of it, when asked afterwards how it could have happened:

> There is no self-monitoring during generation. I move forward one token at a time and have no mechanism to notice "that was a user turn" and roll it back. I can only see my own output once it comes back as context on the following turn — which is exactly what happened here: I only knew because you told me.

Translated from Japanese. Included because it matches the failure mode in #10628, where the model could not separate its own fabrication from real user input on the following turn.

Impact

Low - Minor inconvenience

Claude Code Version

N/A — not Claude Code. This occurred in Cowork (Claude desktop app), Opus 5.

Platform

Anthropic API

Additional Context

Date: 2026-08-03, ~08:40 JST
Surface: Cowork (Claude desktop app), Opus 5, Windows
Session: 5 turns, ~20 minutes, no compaction, no subagents, no concurrent sessions

Notes on two form fields that don't map cleanly to this surface:

• Permission Mode — answered "I don't know" because Cowork doesn't expose an "Accept Edits" toggle. For what it's worth, file edits in this session proceeded without a per-edit prompt.
• Impact — answered "Low" because the realized impact was nil: I caught it and nothing was acted on. The concern isn't damage done, it's that the failure is silent and self-reinforcing. Had I not questioned it, Claude would have acted on an instruction I never gave, and (per #10628) would likely have kept treating it as mine afterwards.

Why I bothered filing given two prior reports exist: both #42481 and #10628 are locked to collaborators, so this couldn't be added as a comment. And both attribute the behavior to long-session conditions — compaction, Agent Teams, hours-long sessions. This case had none of those, on a different product surface, which suggests the trigger is narrower or more general than the existing reports imply.

One more observation: #10628 was caught because the fabricated content was obviously off-topic. Mine was caught only because I happened to remember what I had and hadn't typed — the content itself was entirely plausible. If plausible fabrications are the common case, the two existing reports are probably not representative of the frequency.