"File has been unexpectedly modified" errors break Edit tool in VSCode extension
"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,.tsfiles
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
- Open a JavaScript/TypeScript project in VSCode with Claude Code extension
- Ask Claude to edit a file using the Edit tool
- Observe that Edit tool fails with "File has been unexpectedly modified"
- 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 indefinitelyImpact
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:
- Read file at time T1
- Store file hash/timestamp
- Perform edit operation at time T2
- 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:
- The file modifications are automatic (user didn't cause them)
- The error message suggests user action ("Read it again") but doesn't help
- The issues occurs both in CLI and VSCode extension.
- 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 (akhil@apralabs.com)
15 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
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.
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
.mdfiles 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
D:\path\file.tsxinstead ofD:/path/file.tsx)Issue #10633
Issue #10788
Version Regression Timeline
CRITICAL DETAIL: I specifically noticed this issue appeared after upgrading from v2.0.27 → v2.0.31.
This suggests a regression was introduced somewhere between v2.0.27 and v2.0.31.
Updated Root Cause Analysis
Given that:
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:
Current Workarounds Being Used
Since Edit tool is unusable:
Request for Anthropic
Given the severity and the clear regression between v2.0.27 → v2.0.31:
This issue makes Claude Code significantly less productive on Windows, as we must constantly work around the broken Edit tool.
reverting to 2.0.27 definitely fixes these issues for me
Having the same issue using Powershell w/ native installation.
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.
`
When Claude correctly guesses the exact whitespacing, the edit succeeds
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.
Fix here: https://github.com/anthropics/claude-code/issues/7918#issuecomment-3338306241
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.
Additional Finding: Path Format Root Cause (v2.0.60)
Version: 2.0.60 (Claude Code)
OS: Windows 10/11
Shell: Git Bash
Reproduction
C:/Users/.../file.txt✅ WorksC:\Users\...\file.txt✅ WorksRoot Cause
The file state tracking uses path as a key, but forward slashes and backslashes are not normalized to the same key:
C:/Users/foo/file.txt→ stored in cacheC:/Users/foo/file.txt→ lookup fails (different internal representation?)C:\Users\foo\file.txt→ lookup succeedsWorkaround
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.I'm getting the same error, Error: File has been unexpectedly modified. Read it again before attempting to write it.
Actually, the issue started when the conversation has compacted automatically or manually. Once it is compacted, the issue has started.
Same root cause as #7918 - path tracking breaks with absolute paths.
Simple fix: Use relative paths for Read/Edit. Full workaround and CLAUDE.md prompt: #7918
Works even with VSCode formatters/auto-save enabled.
Improvements should be in the next release.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.