Edit/Write tools silently fail to persist in deep isolated-worktree paths on Windows (stale-cache divergence)

Summary

Claude Code's Edit and Write tools occasionally report success on writes inside an isolated git worktree without the change reaching disk. The in-tool Read reflects the "edited" content, but the filesystem still shows the original — a stale-cache divergence between the harness's in-memory state and the actual filesystem.

Environment

• Platform: Windows 11 Pro 10.0.26200
• Shell: PowerShell 5.1
• Claude Code: VSCode native extension
• Model: Claude Opus 4.7
• Git: regular (not WSL)
• File system: NTFS, default LongPathsEnabled = 0 (260-char MAX_PATH limit active)

Reproduction

The bug surfaced on 2026-05-21 during a dispatched subagent (general-purpose agent with isolation: "worktree") attempting to fix a matcher file at this path:

c:\work\gregoryrgilles\atlas-pipeline-manager\.claude\worktrees\
  agent-a61bef6c84f6b6d6d\src\w0050-edgar-pipeline\
  m0320-edgar-extraction-stage\c0003-reference-matchers\
  f1120-subsidiary-flag-routine-eligible-override\matcher.js

Full path ~280 chars (over Windows MAX_PATH default of 260; long-path support not enabled).

The agent reported:

"The Claude Code Edit and Write tools silently reported success on this matcher.js file while not actually persisting changes to disk (the file system showed the original content while the in-tool Read showed the 'edited' content — a stale-cache divergence)."

Workaround that worked: writing via python -c "open(path, 'w').write(content)" with explicit Windows paths + CRLF preservation.

A separate symptom (likely related): the agent's intended write into its isolated worktree at the deep path apparently leaked into the parent worktree's same-relative-path file. The main worktree showed matcher.js modified with the agent's intended fix at a timestamp BEFORE the agent's own worktree was fully populated.

Filename also tested: T-1120-003-production-profile-shape.test.js was rejected at this same deep path; the shorter T-1120-003-prod-profile-shape.test.js worked. Likely path-length related (both filenames are <50 chars, but full path with the 47-char one exceeds 260).

Expected

Edit and Write either persist the change to disk OR return an error. They should never silently succeed without persisting.

Impact

Subagents dispatched into deep isolated worktrees can spend full review cycles on writes that aren't actually landing. The F-1120 agent caught the divergence via its own verification step and worked around with python -c. Without that defensive check, the failure mode is invisible.

Suggested mitigations (in order of preference)

1. Detect the failure in the Edit/Write tools: after write, re-read from disk (bypassing any cache) and confirm the new content is there. Return an error if not.
2. Document the 260-char path limit interaction in the Claude Code docs for Windows users — and ideally have the harness detect it and warn.
3. Provide a setup-time check or recommendation that Windows users enable LongPathsEnabled registry key to avoid this class of failure.

Workaround we're using in the meantime

We've added a "verify with git status after any Edit or Write in an isolated worktree" rule to our repo's src/architecture/file-discipline.md as a defensive protocol for future dispatched subagents.

References

The full F-1120 fix dispatch done-packet (which surfaced this issue) lives in our repo at docs/audits/f1120-matcher-fix-2026-05-21/done-packet.md. Happy to share more context if helpful.