gemini-cli - 💡(How to fix) Fix Race condition in EditTool leading to clobbered file content

What happened?

The EditTool in packages/core/src/tools/edit.ts is vulnerable to race conditions when multiple edits are performed in parallel on the same file. This happens because the tool follows a "read-modify-write" pattern without any form of file locking or atomic operations.

In the current architecture, the Scheduler allows parallel tool execution. If the agent emits two parallel edit calls for the same file, the following sequence can occur:

1. Operation A reads file content "X".
2. Operation B reads file content "X".
3. Operation A calculates replacement and writes "X+A".
4. Operation B calculates replacement and writes "X+B".

The final state of the file is "X+B", and the changes from Operation A are completely lost.

What did you expect to happen?

Concurrent edits should be handled safely, either by queuing them for the same file or by using file-level locking to ensure that one edit completes before the next one reads the content.

Reproduction Script (Logical)

import fs from 'node:fs';
import path from 'node:path';

const testFile = path.resolve('race_test.txt');
fs.writeFileSync(testFile, 'initial content\n');

// The 'edit' tool in packages/core/src/tools/edit.ts follows:
// 1. Read: currentContent = await fsPromises.readFile(this.resolvedPath, 'utf8');
// 2. Calculate replacement.
// 3. Write: await fsPromises.writeFile(this.resolvedPath, finalContent);

// Parallel execution by Scheduler causes:
// Op 1 Reads 'initial content'
// Op 2 Reads 'initial content'
// Op 1 Writes 'content 1'
// Op 2 Writes 'content 2'
// Final content is 'content 2', Op 1 is lost.

Affected Files

• packages/core/src/tools/edit.ts
• packages/core/src/scheduler/ (potential fix location)

Client information

Platform: All (macOS, Windows, Linux) Version: Latest

Login information

N/A (Core logic issue)

Anything else we need to know?

This is particularly critical when the agent is trying to refactor multiple parts of a file simultaneously or when background processes are modifying files.

Proposed Fix:

• Implement a per-file lock in the FileSystemService or within EditTool.
• Alternatively, have the Scheduler detect overlapping file paths and serialize those specific calls.