write_file overwrites changes made after the agent read the file
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start by reading src/main/tools/files.ts:204-213 and types.ts:392 to understand how requireRead records reads, then inspect session.ts:409 for saved-session migration. Trace how write_file checks the read state and compare the current file with the recorded value. Done means stale reads are rejected with the specified message and existing saved readFiles: string[] sessions are migrated safely.
Written by the indexing model from the issue text.
Description
Found in the 2026-10-07 code review and confirmed with a probe (the file ended as agent, not user edit).
Problem
The read-before-write rule (src/main/tools/files.ts:204-213, requireRead) records only that a path was read (readFiles: Set<string>, types.ts:392), not what was read. edit_file and apply_patch are safer, because their context or old_string must still match. write_file replaces the file outright.
Scenario
The agent reads config.ts. The user edits it in their editor while the agent keeps working. The agent then calls write_file with content built from the old read, and in Auto mode the user's edit is silently lost.
Fix
Make readFiles a Map<string, string> (path → sha256 of the bytes read). In write_file, refuse when the current hash differs: "${path} changed since you read it. Read it again first.". This needs a migration for saved readFiles: string[] (session.ts:409).
- Dominant language
- TypeScript
- Stars
- 2
- Forks
- 2
- Avg merge
- 5h 28m
- Merged PRs (30d)
- 24
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PierrunoYT/patch
-
enhancement platform: windows priority: low severity: low
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
PierrunoYT/patch#198 ·
Maintainers usually reply within 1 day
-
priority: medium security severity: low
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
PierrunoYT/patch#66 ·
Maintainers usually reply within 1 day
-
bug platform: macos priority: low severity: low tests
Difficulty 3/5 1-2 days Newbie friendliness 56/100
PierrunoYT/patch#218 · 1 comment ·
Maintainers usually reply within 1 day
-
enhancement priority: low security severity: low
Difficulty 4/5 3-5 days Newbie friendliness 55/100
PierrunoYT/patch#211 · 2 comments ·
Maintainers usually reply within 1 day
-
enhancement platform: windows priority: low security severity: low
Difficulty 4/5 3-5 days Newbie friendliness 55/100
PierrunoYT/patch#207 ·
Maintainers usually reply within 1 day
All issues in PierrunoYT/patch
Similar issues
-
Flaky: mongodb-memory-server 'Port already in use' when another process starts a mongod concurrentlyOpenarea:testing bug effort:S priority:P2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
lens:agent lens:process process
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
thebristolsound/birdbrain#1772 ·
Maintainers usually reply within 1 day
-
bug priority:low ready-for-dev
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Automattic/data-liberation-agent#685 ·
Maintainers usually reply within 1 day
-
Business
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 1 day