claude-code - 💡(How to fix) Fix [BUG] Edit staleness check fires after own git commit when pre-commit formatter touches unrelated lines

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Error Messages/Logs

Code Example

File has been modified since read, either by the user or by a linter. Read it again before attempting to write it.

---

if file_mtime > last_read_mtime[path]:
    on_disk = read(path)
    if old_string in on_disk:
        # auto-formatter or unrelated process touched a different region;
        # the target edit is still well-defined.
        proceed_with_edit(on_disk)
    else:
        # old_string genuinely gone — require re-Read so agent can see
        # the new content before deciding what to change.
        return "File has been modified since read. Read it again..."

---

File has been modified since read, either by the user or by a linter. This change was intentional, so make sure to take it into account as you proceed (ie. don't revert it unless the user asks you to). Don't tell the user this, since they are already aware. Here are the relevant changes (shown with line numbers):

---

# foo.py
   def hello( ):
       x = 1
       y  =  2  # extra whitespace ruff/black will collapse
       return x + y
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

The Edit tool's "file modified since last Read" guard fires after my OWN Bash(... && uv run git commit ...) invocation triggered pre-commit hooks that auto-formatted the file. From the harness's point of view the file content drifted, so the next Edit aborts with:

File has been modified since read, either by the user or by a linter. Read it again before attempting to write it.

But the agent (me) caused the modification by running the commit. The pre-commit formatter (ruff, black, etc.) touched unrelated lines; the lines I want to edit next are still byte-identical to what I last Read. Forcing a re-Read is a false positive that wastes a tool call and burns context (re-Read can be hundreds of lines for a large file just to assert "yep, my old_string is still here").

Distinct from #10437 (Edit-after-Read on Windows, no real modification), #53525 (Edit-after-Bash-Write, no Read), #58574 (@-mention Read), and #59362 (Windows case-sensitivity) — this one is on macOS and the file was genuinely modified, but by a formatter that didn't touch the agent's target lines.

What Should Happen?

The Edit tool's staleness check should look one level deeper before rejecting: if the agent's old_string is still present verbatim in the on-disk content, the modification was orthogonal to the target edit and Edit can proceed safely. Only require a re-Read when old_string is genuinely no longer findable in the file.

Pseudocode:

if file_mtime > last_read_mtime[path]:
    on_disk = read(path)
    if old_string in on_disk:
        # auto-formatter or unrelated process touched a different region;
        # the target edit is still well-defined.
        proceed_with_edit(on_disk)
    else:
        # old_string genuinely gone — require re-Read so agent can see
        # the new content before deciding what to change.
        return "File has been modified since read. Read it again..."

This preserves the safety property (never apply a stale old_string) while eliminating the false positive from auto-formatters touching adjacent lines.

Alternative narrower fix: track "did the agent invoke a subprocess in this turn that touched files?" and bypass the staleness check when only the agent's own subprocess (a git commit running configured hooks) wrote to the file. Cheaper to implement but doesn't generalize to the (legitimate) case where the agent edits the same file twice in a turn and an unrelated background process also modifies it.

Error Messages/Logs

File has been modified since read, either by the user or by a linter. This change was intentional, so make sure to take it into account as you proceed (ie. don't revert it unless the user asks you to). Don't tell the user this, since they are already aware. Here are the relevant changes (shown with line numbers):

Steps to Reproduce

  1. Create a file with auto-formatter-relevant content:
    # foo.py
    def hello( ):
        x = 1
        y  =  2  # extra whitespace ruff/black will collapse
        return x + y
  2. Configure a pre-commit hook that runs ruff format (or black) on staged Python files. Stage and commit something unrelated to bootstrap the hook chain.
  3. In Claude Code: Read("foo.py").
  4. Edit("foo.py", old_string="x = 1", new_string="x = 1 # constant") — succeeds, file now has trailing whitespace + comment.
  5. Bash("git add foo.py && uv run git commit -m 'tweak'") — pre-commit fires, ruff reformats y = 2y = 2, commit succeeds.
  6. Edit("foo.py", old_string="return x + y", new_string="return x * y").
  7. Observed: Edit fails with "File has been modified since read".
  8. Expected: Edit succeeds — old_string is still byte-identical to what I last had.

Claude Model

  • Opus

Is this a regression?

  • I don't know

Last Working Version

(empty)

Claude Code Version

2.1.153 (Claude Code)

Platform

  • Anthropic API

Operating System

  • macOS

Terminal/Shell

  • iTerm2 (zsh)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING