[BUG] Claude's PowerShell workaround for Edit tool failures caused file corruption and data loss

Preflight Checklist

• [ ] 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?

The Edit tool repeatedly failed with "File has been unexpectedly modified" error on Windows while files were open in Visual Studio.

Claude then attempted a workaround using PowerShell commands via the Bash tool. When running PowerShell through Bash, the $content variable was stripped/misinterpreted, causing the command:

Set-Content "DTO.cs" $content -NoNewline

to become:

Set-Content "DTO.cs" -NoNewline

This overwrote my 3,500-line C# source file with the literal text "-NoNewline", completely destroying the file. Ctrl+Z could not recover it. I had to restore from a 10-day-old backup and manually re-add all missing code.

Two files were affected:

• Advance.cs (recovered via Ctrl+Z)
• DTO.cs (unrecoverable - required backup restoration)

What Should Happen?

1. The Edit tool should work reliably on Windows without false "file unexpectedly modified" errors when the file hasn't actually been changed by the user.

1. If the Edit tool fails repeatedly, Claude should:

• Stop and inform the user about the issue
• Ask for guidance before attempting any workaround
• NOT automatically attempt risky alternatives (like PowerShell via Bash) that could corrupt files

1. If Claude must suggest a workaround, it should:

• Warn the user about potential risks
• Get explicit user permission first
• Never execute file-modifying commands where special characters ($, backticks) could be misinterpreted

1. Files should never be corrupted or destroyed due to Claude's automated workaround attempts.

Error Messages/Logs

File has been unexpectedly modified. Read it again before attempting to write it.

This error appeared repeatedly when I tried to use the Edit tool on your files (Advance.cs and DTO.cs) while Visual Studio had them open. After multiple failures with this error, I made the bad decision to try the PowerShell workaround, which caused the file corruption.

Steps to Reproduce

1. Open a project in Visual Studio on Windows
2. Have Claude attempt to edit a file that VS has open
3. Edit tool fails repeatedly with "File has been unexpectedly modified"
4. Claude attempts PowerShell workaround via Bash tool
5. Special characters get stripped, file is corrupted

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

---
Expected Behavior:

1. Claude should NOT attempt risky workarounds that could cause data loss
2. If Edit tool fails repeatedly, Claude should inform the user and ask for guidance instead of trying alternative approaches
3. At minimum, Claude should warn the user before attempting any workaround that modifies files outside the Edit/Write tools
4. If workarounds are attempted, Claude should test on a dummy file first or create a backup

---
Environment:

• OS: Windows 11
• Claude Code Version: 2.0.76
• IDE: Visual Studio 2022 Enterprise (files were open)
• Shell: Git Bash / PowerShell
• Project: .NET Framework 4.8 WinForms (C#)

---
Impact:

• Complete data loss of a critical source file (~3,500 lines)
• Required manual restoration from 10-day-old backup
• Lost ~2 hours recovering and re-adding missing code
• Two files were corrupted (Advance.cs recovered via Ctrl+Z, DTO.cs was not recoverable)

---
Related Issues:

• #12891 - Edit tool fails on Windows (Access Time Update)
• #11684 - Edit tool fails on Windows/Git Bash
• #7443 - Edit tool "file unexpectedly modified" (critical)

---
Suggested Fix:

1. Fix the underlying Edit tool issue on Windows (check mtime only, not atime)
2. Add a safeguard: Claude should never attempt file modifications via Bash/PowerShell as a workaround for Edit tool failures
3. If Claude must use workarounds, require explicit user permission first