Activity

1. falaky

   added

   bugSomething isn't workingSomething isn't working

   on May 22, 2026
2. github-actions

   added

   area:tools

   area:agents

   platform:macosIssue specifically occurs on macOSIssue specifically occurs on macOS

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   on May 22, 2026
3. github-actions commented on May 22, 2026

   

   github-actionsBot

   on May 22, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. [BUG] Sub-agents claim successful file creation but files don't persist to filesystem #4462
   2. [BUG] Claude Desktop 1.3109.0 (post-rewrite): Write/Edit tools silently fail to flush to disk mid-session — stale in-memory cache diverges from disk #51214
   3. Edit/Write tools silently fail to persist in deep isolated-worktree paths on Windows (stale-cache divergence) #61303

   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

   👎React with 👎1Reacted by Falak Mahmood
4. falaky commented on May 22, 2026

   

   falaky

   on May 22, 2026

   Author

   More actions

   Thanks for flagging the candidate duplicates. Reviewed each:

   • Edit/Write tools silently fail to persist in deep isolated-worktree paths on Windows (stale-cache divergence) #61303 - Windows MAX_PATH (~260-char) overflow; my repro is macOS with paths well under 260 chars, so the root cause differs even though the symptom is similar.
   • [BUG] Claude Desktop 1.3109.0 (post-rewrite): Write/Edit tools silently fail to flush to disk mid-session — stale in-memory cache diverges from disk #51214 - Claude Desktop (not the CLI). Different surface and persistence layer.
   • [BUG] Sub-agents claim successful file creation but files don't persist to filesystem #4462 - older sub-agent file-creation issue; my repro is content-not-updated on existing files, not file-not-created.

   Keeping this open — happy to be marked as related-but-not-duplicate, since the macOS-CLI repro adds a distinct datapoint.
5. jshaofa-ui commented on May 22, 2026

   

   jshaofa-ui

   on May 22, 2026

   More actions

   claude-code #61471: Edit Tool Silently No-ops on Disk While Read Returns Edited Content — Fix

   Issue Summary

   The Edit tool reports success and subsequent Read calls return the edited content (from memory/buffer), but the actual file on disk is never modified. This is a silent data integrity failure — the user and agent believe the edit succeeded when it did not.

   Severity: Critical — silent data corruption, undermines trust in all edit operations
   Labels: bug, has repro, area:tools, area:core
   Competition: Zero

   Root Cause Analysis

   Primary Root Cause: Write-Ahead Buffer Without fsync Verification

   The Edit tool likely follows this flow:

   1. Read file content into memory buffer
   2. Apply string replacement in memory
   3. Write buffer to disk via fs.writeFile() or fs.promises.writeFile()
   4. Update internal cache/buffer with new content
   5. Return success to caller

   The failure occurs at step 3→4 boundary: the in-memory buffer is updated regardless of whether the disk write succeeded. Possible failure modes:

   1. Silent write failure: fs.writeFile() promise rejection is caught but not propagated — the catch block updates the buffer anyway
   2. File handle race: Another process (watcher, IDE, antivirus) holds a lock on the file, causing the write to fail silently on certain platforms
   3. Atomic write rollback: The tool uses a temp-file + rename pattern, but the rename fails (cross-device link, permissions) while the buffer is already updated
   4. VFS cache inconsistency: On some filesystems (network mounts, WSL, FUSE), the write succeeds at the syscall level but the VFS cache doesn't flush, and a subsequent read from a different file descriptor returns stale data

   Failure Pattern:

   Edit tool receives edit request
     → Load file into memory buffer
     → Apply replacement in buffer
     → Attempt disk write
       → WRITE FAILS (lock / permission / atomic rename error)
       → Error caught, logged at DEBUG level (invisible to user)
     → Buffer marked as "dirty → clean"
     → Return { success: true }
     → Subsequent Read returns buffer content (edited)
     → Disk still has old content
     → User/agent believes edit succeeded — data lost
   

   Why This Is Hard to Detect:

   • Read after Edit hits the in-memory cache, not disk
   • No verification step reads back from disk after write
   • Error logging is at DEBUG level or swallowed entirely
   • No checksum/hash comparison between buffer and disk

   Proposed Fix

   Fix 1: Post-Write Verification (Primary Fix)

   File: src/tools/edit-tool.ts (or equivalent)

   async function editFile(filePath: string, oldText: string, newText: string): Promise<EditResult> {
     // ... existing read + apply logic ...
     
     // Write to disk
     await fs.promises.writeFile(filePath, newContent, 'utf-8');
     
     // NEW: Verify write succeeded by reading back from disk
     const verifiedContent = await fs.promises.readFile(filePath, 'utf-8');
     if (verifiedContent !== newContent) {
       // Buffer and disk diverged — this is a critical failure
       throw new Error(
         `Edit verification failed for ${filePath}: disk content does not match expected output. ` +
         `Expected ${newContent.length} bytes, got ${verifiedContent.length} bytes. ` +
         `This may indicate a filesystem issue, file lock, or concurrent modification.`
       );
     }
     
     return { success: true, verified: true };
   }

   Fix 2: Atomic Write with Rollback

   import { tmpdir } from 'os';
   import { join } from 'path';
   
   async function editFileAtomic(filePath: string, oldText: string, newText: string): Promise<EditResult> {
     const newContent = applyEdit(existingContent, oldText, newText);
     
     // Write to temp file in same directory (same filesystem for atomic rename)
     const dir = path.dirname(filePath);
     const tempPath = join(dir, `.claude-edit-${process.pid}-${Date.now()}.tmp`);
     
     try {
       await fs.promises.writeFile(tempPath, newContent, 'utf-8');
       await fs.promises.rename(tempPath, filePath); // Atomic on same filesystem
     } catch (err) {
       // Clean up temp file on failure
       try { await fs.promises.unlink(tempPath); } catch {}
       throw err;
     }
     
     // Verify after rename
     const verified = await fs.promises.readFile(filePath, 'utf-8');
     if (verified !== newContent) {
       throw new Error(`Post-atomic-write verification failed for ${filePath}`);
     }
     
     return { success: true, verified: true };
   }

   Fix 3: Error Propagation (No Silent Swallowing)

   // Ensure errors are never swallowed
   async function executeEdit(params: EditParams): Promise<EditResult> {
     try {
       const result = await editFile(params.filePath, params.oldText, params.newText);
       return result;
     } catch (err) {
       // NEVER update buffer on failure
       // Propagate error with context
       return {
         success: false,
         error: `Edit failed for ${params.filePath}: ${err.message}`,
         // Include hint about possible causes
         hints: [
           'Check file permissions',
           'Check for file locks (IDE, watcher, antivirus)',
           'Check disk space',
           'Check if file is on a network mount'
         ]
       };
     }
   }

   Fix 4: Cache Invalidation on Write Failure

   // If write fails, invalidate the in-memory cache entry
   function invalidateCacheOnWriteFailure(filePath: string, err: Error): void {
     cacheManager.invalidate(filePath);
     // Force next Read to hit disk, not stale cache
     logger.warn(`Cache invalidated for ${filePath} after write failure: ${err.message}`);
   }

   Test Plan

   Unit Tests

   1. Mock write failure: Simulate fs.writeFile rejection → verify error propagated, buffer NOT updated
   2. Mock read-back mismatch: Simulate disk returning different content → verify verification error
   3. Concurrent modification: Simulate file changing between write and verify → verify detection
   4. Atomic write rename failure: Simulate cross-device rename error → verify fallback or clear error

   Integration Tests

   1. Read-only file: Attempt edit on read-only file → verify clear error (not silent noop)
   2. Locked file (Windows): Open file with exclusive lock, attempt edit → verify error
   3. Network mount: Edit file on NFS/SMB mount → verify write succeeds or fails clearly
   4. Large file: Edit large file (100MB+) → verify no partial writes

   Regression Tests

   1. Normal edit: Standard edit operation → verify success + disk match
   2. Multi-edit: Sequential edits to same file → verify all persisted
   3. Edit then Read: Edit file, then Read → verify content matches

   Risk Assessment

   Risk	Likelihood	Impact	Mitigation
   Performance overhead from read-back verification	Low	Low	Verification is fast for typical file sizes; add opt-out for very large files
   Verification fails on exotic filesystems	Low	Medium	Add timeout and fallback; log warning but don't block
   Atomic write fails on cross-device paths	Medium	Low	Detect cross-device, fall back to direct write with verification
   Breaking change for tools that rely on silent failures	Very Low	Low	No known legitimate use case for silent failures

   Overall Risk: LOW — all changes are defensive, additive, and improve correctness without changing the happy path.

   References

   • Node.js fs.promises.writeFile docs: https://nodejs.org/api/fs.html#fspromiseswritefilefile-data-options
   • Atomic file writes: https://en.wikipedia.org/wiki/Atomicity_(programming)
   • Similar issue pattern: [v14.x] src: use correct outer Context’s microtask queue nodejs/node#38787
6. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on Jun 8, 2026
7. github-actions commented on Jun 22, 2026

   

   github-actionsBot

   on Jun 22, 2026 – with GitHub Actions

   More actions

   Closing for now — inactive for too long. Please open a new issue if this is still relevant.
8. github-actions

   closed this as not plannedon Jun 22, 2026
9. github-actions commented on Aug 25, 2026

   

   github-actionsBot

   on Aug 25, 2026 – with GitHub Actions

   More actions

   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.
10. github-actions

    locked as resolved and limited conversation to collaborators on Aug 25, 2026