# Two Claude Code sessions edited the same file. One of them was wrong. I built a hook to stop that > Source: > Published: 2026-09-30 08:35:34+00:00 I run multiple Claude Code sessions against the same repo — one refactoring, one fixing tests, sometimes one more exploring. Last week I watched session A carefully edit a function based on code that session B had already rewritten ten minutes earlier. The edit applied cleanly. It was also completely wrong: it reintroduced the old logic on top of the new. I only caught it in `git diff`. There's a name for this failure mode. Dat Do's measurements post on agent memory put it plainly: *"With several agent sessions on one repository, session A reads `createSession`, session B changes it, and A then edits on the old assumption."* The existing answers are heavyweight: file-reservation MCP servers, session buses with path claims. I wanted something I could install in ten seconds. So I built `edit-guard`: a single stdlib-only Python script that plugs into Claude Code's `PreToolUse` hook. ``` pip install edit-guard edit-guard install # merges into ~/.claude/settings.json, backs it up first ``` From then on, every `Read` records what your session saw (file hash + timestamp), and every `Edit`/` Write` checks the file's current hash against what *your session* last saw. If the bytes changed and another session touched the file in between, the write is blocked and the agent is told to re-read first: ``` Stale edit blocked: 'src/auth.py' changed since you last saw it (last modified by session 'a4c2e901'). Re-read the file before editing. ``` Same-session rewrites always pass. New files always pass. A corrupt state log, an unreadable file, anything unexpected — the hook fails open and allows the edit. A safety tool that can wedge your workflow is worse than no tool. The state is one append-only JSONL file at `~/.config/edit-guard/writes.jsonl`. No daemon, no server, no network. `edit-guard log` shows you what's being tracked. I went back and forth on whether a stale write should block or just warn. Warning is friendlier, but in practice the agent reads the warning, says "noted", and edits anyway — I've watched it happen. Blocking forces the re-read, which is the actual fix. The failure mode of blocking is annoyance (a reformat by session B blocks session A); the failure mode of warning is silent corruption. For a tool whose whole job is preventing silent corruption, blocking is the honest default. `pip install edit-guard` 7 smoke tests pass, including the exact A-reads/B-writes/A-blocked scenario and a fail-open test against a corrupted state log. If you multi-session a single repo: how do you keep your agents from stepping on each other? I'm curious what breaks first at your scale.