[BUG] Write tool preview shows duplicated lines while on-disk bytes are correct (SHA256-verified)

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?

Claude Code's Write tool preview rendered specific lines twice, with repeating line numbers (observed pattern: "28, 29, 28, 29, 30"), on multi-line content with comment headers. On-disk content was consistently correct, verified via grep -c, wc -l, and SHA256 hashing against spec-literal reference content.

This appears distinct from #50689, which describes payload-level corruption that persists on disk. In my case on-disk content never contained the duplication the preview showed.

Also observed in heredoc-style commit message bodies during git commit -m "$(cat <<'EOF' ... EOF)" — three consecutive attempts showed preview duplication; workaround was writing the message to a scratch file and using git commit -F file, which committed cleanly on first attempt.

Session ID for Anthropic triage: 5d9d4609-9e5a-42bb-9fe4-51f59d771f5b

What Should Happen?

Write tool preview should match on-disk content byte-for-byte. If preview shows lines 28, 29, 28, 29, 30, the written file should also contain those lines in that order — it should not show deduplicated content while preview shows duplicates.

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session on Windows 11 with Git Bash shell.
2. Ask Claude Code to create a multi-line YAML file (~30+ lines) with comment-header blocks and structured content.
3. Observe the Write-tool preview as it renders — specific lines will appear twice with non-sequential line numbers (e.g. "28, 29, 28, 29, 30").
4. Accept the write.
5. Verify on-disk content:

• grep -c "<suspected-duplicated-line>" <file> — returns 1, not 2
• wc -l <file> — matches expected line count, not preview's inflated count
• Get-FileHash -Algorithm SHA256 <file> — matches spec-literal reference content hash

1. Conclusion: preview lies; disk is correct.

For heredoc/commit-message variant:

1. Attempt git commit -m "$(cat <<'EOF' <long multi-section message> EOF)"
2. Preview shows duplicated title line and/or duplicated section headers.
3. Workaround: write message to scratch file, run grep/wc to verify, then git commit -F <file> — commits correctly on first attempt.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.114 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Cryptographic verification

Four YAML files were written via Write tool with preview showing duplication. Each was:

1. Verified with grep -c "<pattern>" — single occurrence (count = 1, not 2)
2. Verified with wc -l — expected line count
3. SHA256-hashed and compared to spec-literal reference content
4. Committed with SHA256 registry in the commit body

Five days later I re-ran Get-FileHash -Algorithm SHA256 on all four files. All four hashes match the registry recorded in the commit. Byte-identical. No corruption.

This rules out payload-level corruption, slow-drift, and delayed-write corruption. The preview was wrong; the disk was always right.

Relationship to #50689

#50689 describes Write-tool content corrupted before reaching disk — sed/grep/cat on the resulting file confirm persistent duplication matching preview.

In my case the opposite held: on-disk content was always clean (SHA-verified); preview was unreliable. These may be distinct bugs, or symptoms of a shared root cause surfacing at different layers (generation output vs. display rendering).

Project context (for repro environment)

The bug was observed while setting up a scaffolding commit on a greenfield private Python project using uv for environment management, pytest/mypy/ruff in [dependency-groups], and hatchling build backend. Nothing in the project stack should be unusual for Claude Code.