Edit/Write tool changes silently reverted after Bash execution (vitest, build commands)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34674
2. https://github.com/anthropics/claude-code/issues/35699
3. https://github.com/anthropics/claude-code/issues/40349

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

Not a duplicate of the suggested issues. Key differences:

• #34674 (context compaction): Our reverts happen without compaction — context was ~10% full, no /compact used. The trigger is npx vitest run, not compaction.
• #35699 (sandbox): We have sandbox disabled — no sandbox config in settings.
• #40349 (Desktop app): We use CLI mode, not the desktop app.

Our issue has a unique, confirmed trigger: running npx vitest run via Bash after Edit/Write causes CC's file cache to overwrite disk. Omitting vitest (build only) makes changes persist. This is a different code path from compaction-triggered reverts.

The forensic evidence (3 incidents, same session, controlled variable = vitest execution) is in the issue description.

We experienced the exact same bug independently during a long session on Linux.

No context compaction occurred — the conversation was within the context window the entire time.

Setup: Multiple fixes applied sequentially via Edit tool across ~15 files. Each fix was tested and verified with build commands.

Trigger: After launching sub-agents (via the Agent tool) that ran build/test commands, previously-applied edits in unrelated files were silently reverted to their pre-edit state.

Simplified reproduction:

1. Apply Edit tool changes to files A, B, C, D (all succeed, verified with grep)
2. Launch a sub-agent that runs a build command and modifies file E only
3. After the sub-agent completes: files A, B, C, D are silently reverted to their pre-edit state. File E has the sub-agent's changes.
4. The reverted content matches the state from when each file was first Read in the conversation — not the last Edit.

Impact: ~4 hours of tested, validated fixes across 10+ files silently destroyed. ~2 additional hours debugging before understanding the scope. The system-reminder "file was modified, either by the user or by a linter" appeared multiple times.

Key observation: This happened 3+ times in our session. Any Bash execution (build, test) in the main conversation or in a sub-agent triggers the revert of all previously-edited files, including files the Bash command never touched.

Workaround: git commit immediately after edits, before running any build/test commands.

Environment: Claude Code on Linux (Ubuntu 22.04), Opus model, long session (~8 hours), multi-language project.

Additional data point: Write tool also affected, git commit as workaround

Environment

• Claude Code v2.1.90
• macOS Darwin 25.2.0, Node.js 22, TypeScript/vitest project
• Multi-agent orchestration (Boss + background sub-agents)

New findings

1. Write tool (full file overwrite) is also affected — not just Edit

In a session with 5 parallel sub-agents editing different files, all Edit-based changes to existing files were silently reverted. We then switched to Write tool (full file replacement) — same result. Changes appeared in git status immediately after Write, but were gone by the next tool call.

| Write method | Existing file | New file | Persisted? |
|---|---|---|---|
| Edit tool | ✓ | — | ❌ Reverted |
| Write tool | ✓ | — | ❌ Reverted |
| Write tool | — | ✓ | ✅ Persisted |
| Bash python3 open().write() | ✓ | — | ✅ Persisted |

Key finding: New file creation via Write tool is NOT affected. Only overwrites of existing files are reverted.

2. Bash python3 writes persist — confirms file cache theory

Writing via python3 -c "..." in Bash tool bypasses CC's file tracking entirely, so changes survive. This is consistent with the file cache re-sync theory from the original report.

3. Immediate git commit prevents revert

Even when using Bash python3 to write, we found that committing immediately after each file write (git add <file> && git commit) is necessary. Without commit, changes could still be lost if a subsequent Bash call (e.g., npx vitest run) triggers the cache re-sync.

Workaround (confirmed working)

1. Read file with Read tool
2. Write modified content via: Bash → python3 -c "open('file.ts','w').write(content)"
3. Immediately: git add file.ts && git commit -m "..."
4. Move to next file

This survived a full session with 8 files changed across 4 sub-agents.

it was because of my test codes, not Claude's.
closing the issue

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.