claude-code - 💡(How to fix) Fix [BUG] Write tool preview shows duplicated lines while on-disk bytes are correct (SHA256-verified)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Error Messages/Logs

Root Cause

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).

Fix Action

Fix / Workaround

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.

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.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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
  6. 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.

extent analysis

TL;DR

The issue can be worked around by writing the content to a scratch file and then using git commit -F file instead of git commit -m to avoid the Write tool preview duplication.

Guidance

  • The problem seems to be related to the Write tool preview rendering, which shows duplicated lines with non-sequential line numbers, but the on-disk content is correct.
  • To verify the issue, use grep -c, wc -l, and SHA256 hashing to confirm that the on-disk content is correct and does not contain the duplication shown in the preview.
  • As a workaround, write the content to a scratch file and use git commit -F file instead of git commit -m to commit the changes.
  • The issue may be related to the rendering of multi-line content with comment headers, and it's possible that it's a distinct bug from #50689, which describes payload-level corruption.

Example

No code snippet is provided as the issue is related to the Write tool preview rendering and not a specific code snippet.

Notes

The issue is specific to the Claude Code Write tool preview and does not affect the on-disk content. The workaround provided should help mitigate the issue, but the root cause of the problem is still unknown.

Recommendation

Apply the workaround by writing the content to a scratch file and using git commit -F file instead of git commit -m to commit the changes. This should help avoid the Write tool preview duplication issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Write tool preview shows duplicated lines while on-disk bytes are correct (SHA256-verified)