"File has been unexpectedly modified" errors break Edit tool in VSCode extension

[kumaakh]

"File has been unexpectedly modified" errors break Edit tool in VSCode extension

Environment

• Claude Code Version: VSCode Extension
• OS: Windows 11
• Working Directory: Git repository with TypeScript/JavaScript files
• File Types Affected: .js, .ts files

Summary

The Edit tool consistently fails with "File has been unexpectedly modified. Read it again before attempting to write it." error, even when no manual edits are being made. The file appears to be modified by some VSCode background process between Claude's Read and Edit operations.

Steps to Reproduce

1. Open a JavaScript/TypeScript project in VSCode with Claude Code extension
2. Ask Claude to edit a file using the Edit tool
3. Observe that Edit tool fails with "File has been unexpectedly modified"
4. Note: This occurs even when user has not manually edited the file

Expected Behavior

The Edit tool should successfully apply changes to files that the user has not manually modified.

Actual Behavior

Edit tool fails repeatedly with "File has been unexpectedly modified" error, forcing fallback to complex workarounds using awk/sed commands which introduce their own issues (shell escaping problems, especially on Windows/Git Bash).

Example Workflow That Fails

1. Claude: Read file (lib/helpers.js) ✓
2. VSCode: Auto-format or linter runs in background
3. Claude: Edit file with changes ✗ "File has been unexpectedly modified"
4. Claude: Read file again ✓
5. VSCode: Auto-format runs again
6. Claude: Edit file ✗ "File has been unexpectedly modified"
... repeats indefinitely

Impact

This makes the Edit tool essentially unusable in the VSCode extension for active development workflows. Claude is forced to use:

• Complex awk/sed scripts (brittle, error-prone)
• Read entire file + Write back (loses granular editing benefits)
• Manual file operations via Bash (defeats purpose of Edit tool)

Suspected Root Cause

The Edit tool appears to:

1. Read file at time T1
2. Store file hash/timestamp
3. Perform edit operation at time T2
4. Verify file hasn't changed since T1

Between T1 and T2, some VSCode background process (possibly file watchers, formatters like Prettier, linters like ESLint, TypeScript compiler, or VSCode's own file sync) modifies the file, causing the verification to fail. This is speculation based on observed behavior - the actual cause has not been confirmed.

Suggested Fixes

Option 1: Add retry logic with brief delay

If "File has been unexpectedly modified" error occurs:

• Wait 100-500ms for file watchers to settle
• Re-read file automatically
• Retry edit operation
• Fail after 2-3 retries

Option 2: Detect common file watcher changes

• If file modification is only whitespace/formatting (same AST)
• Automatically re-read and apply edit to new version
• Only fail on substantive changes

Option 3: Lock file during edit

• Request file lock before Edit operation
• Prevent other processes from modifying during edit
• Release lock after edit completes

Additional Context

This issue significantly degrades the user experience in the VSCode extension compared to the CLI version. It's particularly frustrating because:

1. The file modifications are automatic (user didn't cause them)
2. The error message suggests user action ("Read it again") but doesn't help
3. The issues occurs both in CLI and VSCode extension.
4. Workarounds are significantly worse than the Edit tool

Related Issues

• Potentially related to file watching/auto-save behaviors in VSCode
• May affect all file types that have formatters/linters configured
• It started occuring after I upgraded from 2.0.27 to 2.0.31

---

Reported by: Akhil Kumar ([email protected])

[github-actions[bot]]

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/10633
2. https://github.com/anthropics/claude-code/issues/7918
3. https://github.com/anthropics/claude-code/issues/10788

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

[Korenwolf9642]

I have had the same issue for the last two days. Its not just the VS Code extension. Regular terminal Claude Code also has broken Edit and Write tools. Claude has been working overtime using Bash commands and writing temporary files. It doesn't go very well compared to the Edit tool.

[kumaakh]

IMPORTANT UPDATE: Issue Affects ALL File Types (Not Just TypeScript/JavaScript)

After further investigation, I can confirm this issue affects all file types, including:

• ✅ .md (Markdown files - no formatters/linters)
• ✅ .ts (TypeScript files)
• ✅ .js (JavaScript files)
• ✅ .sh (Shell scripts)

This is critical because it rules out the formatter/linter hypothesis.

Markdown files don't have Prettier, ESLint, TypeScript compiler, or other typical background processes that modify code files. The fact that .md files also fail with "File has been unexpectedly modified" strongly suggests this is NOT caused by VSCode formatters/linters, but rather a fundamental file handling bug on Windows.

Cross-Reference with Related Issues

After analyzing the duplicate issues (#10633, #7918, #10788), I found:

Issue #7918 - Critical Evidence

• Bug introduced: v1.0.111
• Last confirmed working: v1.0.110
• Root cause: Changelog mentions "Fixed Bash tool crashes caused by malformed shell syntax parsing" - this fix appears to have broken Windows file path handling
• Workaround suggested: Use backslashes in Windows paths (D:\path\file.tsx instead of D:/path/file.tsx)

Issue #10633

• Affected version: v2.0.29
• Marked as regression (worked before)
• Workaround: Direct Node.js file operations instead of Edit tool

Issue #10788

• Affected version: v2.0.31 (same as this issue)
• Only workaround: System restart (impractical)

Version Regression Timeline

CRITICAL DETAIL: I specifically noticed this issue appeared after upgrading from v2.0.27 → v2.0.31.

• 🟢 v2.0.27: Edit tool worked reliably
• ❓ v2.0.28-2.0.30: Unknown (not tested)
• 🔴 v2.0.31: Edit tool consistently fails on Windows

This suggests a regression was introduced somewhere between v2.0.27 and v2.0.31.

Updated Root Cause Analysis

Given that:

1. Issue affects ALL file types (including .md without formatters)
2. Issue is Windows-specific (win32 platform)
3. Related to v1.0.111+ path handling changes
4. Regression occurred between v2.0.27 and v2.0.31

Primary suspect: Windows file path normalization bug (forward slash vs backslash handling), similar to the v1.0.111 regression but reintroduced or never fully fixed.

Recommended Investigation

For Anthropic team:

1. Compare file path handling code between v2.0.27 (working) and v2.0.31 (broken)
2. Test with backslash-only paths on Windows to verify if path format is the issue
3. Check if v1.0.111 fix was properly ported to v2.x codebase
4. Add file type to error telemetry to confirm scope (all types vs specific types)

Current Workarounds Being Used

Since Edit tool is unusable:

1. ✅ Bash + sed/awk commands - Works but brittle on Windows
2. ✅ Node.js file operations - Reliable but verbose
3. ✅ Write tool (read entire file, modify, write back) - Works but loses granular editing benefits
4. ⚠️ Backslash path format - Not yet tested in our environment

Request for Anthropic

Given the severity and the clear regression between v2.0.27 → v2.0.31:

• Can you identify what changed in file handling between these versions?
• Would downgrading to v2.0.27 be recommended as a temporary workaround?
• Is there a beta/test version with a fix we could try?

This issue makes Claude Code significantly less productive on Windows, as we must constantly work around the broken Edit tool.

[kumaakh]

reverting to 2.0.27 definitely fixes these issues for me

[h5kk]

Having the same issue using Powershell w/ native installation.

[DaveRune]

The same issue occurring to me. I'm getting countless "Error editing file" messages which then end up with "File has been unexpectedly modified". Using C# and Rider. This isn't new but seems worse lately.

Claude explained why all of these failed, the answer is whitespace.

`The Read tool gives me the actual whitespace characters from your file, but in the text format I receive, tabs and spaces both render as blank whitespace - I can't tell them apart just by looking.

1. ✅ I DO receive the whitespace
2. ❌ I CANNOT see whether each whitespace character is a tab or a space
3. 🤷 I have to GUESS the combination and try different patterns until Edit succeeds `

When Claude correctly guesses the exact whitespacing, the edit succeeds

[DaveRune]

The fix for me is instant and 100% successful.

Tell Claude the following: Before editing files, always use cat -A (or equivalent) to verify exact whitespace characters (tabs vs spaces)

You can put this line in your preferences. Then hope Claude reads them and abides by them.

[kingcarol1]

Fix here: https://github.com/anthropics/claude-code/issues/7918#issuecomment-3338306241

[cizole]

This happens to me constantly and it's maddening as NO OTHER PROCESS IS TOUCHING THE FILE. Claude is the only thing making edits and there is nothing else running on my PC that would modify any of these files.

[WayneKoorts]

This happens to me constantly and it's maddening as NO OTHER PROCESS IS TOUCHING THE FILE. Claude is the only thing making edits and there is nothing else running on my PC that would modify any of these files.

I was having this problem all the time until I told Claude to find a solution online. It found that if it uses relative paths instead of absolute paths it doesn't have the issue. Since I added to its memory that it should always use relative paths when editing files I haven't had the issue again.

[hermannakruse]

Additional Finding: Path Format Root Cause (v2.0.60)

Version: 2.0.60 (Claude Code) OS: Windows 10/11 Shell: Git Bash

Reproduction

1. Create a test file via Bash
2. Read file with forward slashes: C:/Users/.../file.txt ✅ Works
3. Edit/Write with forward slashes → ❌ "File has been unexpectedly modified"
4. Read same file with backslashes: C:\Users\...\file.txt ✅ Works
5. Edit/Write with backslashes → ✅ Works

Root Cause

The file state tracking uses path as a key, but forward slashes and backslashes are not normalized to the same key:

• Read: C:/Users/foo/file.txt → stored in cache
• Write: C:/Users/foo/file.txt → lookup fails (different internal representation?)
• Write: C:\Users\foo\file.txt → lookup succeeds

Workaround

Always use backslashes (\) in file paths on Windows.

Path Style	Read	Edit/Write
C:/path/file.txt	✅	❌ Fails
C:\path\file.txt	✅	✅ Works

This suggests the fix should normalize paths (e.g., convert all / to \ on Windows) before using them as cache keys.