[Bug] Claude Opus 4.7: Duplicated lines in file generation with non-sequential line numbers

Bug Description

# Bug report — Line duplication in file generation (Claude Code, Opus 4.7) Pour soumission à : https://github.com/anthropics/claude-code/issues Titre suggéré : Opus 4.7: duplicated lines in generated files with non-sequential line numbers in diff output --- ## Summary Since approximately April 16-17, 2026, I am consistently observing duplicated lines in files generated by Claude Code when using Claude Opus 4.7. The duplication is mechanical (identical lines appear twice in sequence) and is visible in the diff output with non-sequential line numbers (e.g., 128, 129, 128, 129, 130 in the displayed output). The agent itself appears unaware of the duplication: when challenged, it consistently denies having produced duplicate lines, even when shown screenshots. This suggests the duplication occurs in the rendering/write pipeline rather than in the agent's internal representation. ## Environment - Product: Claude Code - Model: Claude Opus 4.7 - OS: (fill in your OS, e.g., Windows 11 / WSL Ubuntu 22.04) - Claude Code version: (fill in — run claude --version if available) - Terminal: (fill in — e.g., Windows Terminal, iTerm2, VS Code integrated terminal) - First observed: April 16-17, 2026 - Frequency: Multiple occurrences per day on medium-size file generation tasks ## Reproduction pattern 1. Ask Claude Code to generate a non-trivial TypeScript/JavaScript file (typically 100+ lines, e.g., a test file with multiple it() blocks using shared fixture helpers) 2. In some fraction of generations, the output file contains duplicated consecutive lines 3. When displayed with line numbers, the duplicated block shows non-sequential numbering — same line number appearing twice ## Concrete example Generating a Vitest test file, I observed the following output block (numbers on the left are line numbers as displayed by Claude Code's viewer): `` 125 it('does not mutate the input clusters array', () => { 126 const nodes = [ 127 makeNode('a', 'high', 30), 128 makeNode('b', 'medium', 20), 129 makeNode('c', 'medium', 10), 128 makeNode('b', 'medium', 20), 129 makeNode('c', 'medium', 10), 130 makeNode('d', 'medium', 5), 131 ]; ` Line numbers 128 and 129 appear twice each. This is mechanically impossible in a normal file; it is the signature of a block pasted or emitted twice, in a display/generation tool that does not renumber after insertion. When I pointed this out, the agent responded: > "Dans ma memoire de travail le bloc etait propre (4 makeNode distincts pour a/b/c/d). Je n'ai pas d'acces au rendu que tu as vu, donc je ne peux pas trancher sur la cause." Translation: *"In my working memory the block was clean (4 distinct makeNode for a/b/c/d). I don't have access to the rendering you saw, so I can't determine the cause."* This confirms the asymmetry: the agent's internal state was clean, but the output delivered to the user was duplicated. ## Secondary symptom: file loss on edit cancellation A related issue I observed during the same period: when I cancel a Write operation before the file is committed to disk (to review the content), the file content appears to be lost. When the agent retries, it reconstructs the file from an incomplete memory representation, introducing small divergences (different line counts, slightly different helper factoring, reordered fields). This is consistent with ephemeral sub-agent state being dropped between turns, though I have not been able to confirm whether the agent delegates to sub-agents on my tasks. ## Impact - Broken generated code requiring manual correction before typecheck/tests pass - Significant erosion of trust in agent output (every generated file now requires line-by-line review before Write) - Substantial additional review time: a task that should take 2-3 hours can take 2 days due to the need for repeated correction cycles and the agent's tendency to deny the duplication until shown proof ## What I tried - Asking the agent to re-read its own output: agent denies duplication - Providing screenshots: agent accepts the evidence but cannot diagnose the cause - Enforcing a "Write first, review after" discipline instead of "show diff, then Write": helps reduce reconstruction errors but does not prevent the initial duplication during Write - Refactoring generation to reduce shared fixture patterns (moving fixtures into helpers): appears to reduce frequency but does not eliminate it ## Suggested investigation areas - Tooling layer that renders/writes files from model output, particularly for outputs that contain repeated structural patterns (multiple similar it()` blocks, multiple similar array entries) - Sub-agent state handoff if delegation is occurring (information loss between sub-agent and main agent when the main agent retries a cancelled operation) - Opus 4.7 sp…
Note: Content was truncated.