Summary

No-op file mutations should be treated as terminal tool-loop failures in agent execution, rather than as successful mutations or recoverable tool errors.

Two recurring cases:

1. write is called with content identical to the existing file content.
2. Edit/patch tools are called with identical old/new text, or return a result like No changes made.

In agent loops, these can be interpreted as progress or a recoverable failure, causing repeated identical write/edit attempts.

Expected behavior

• If write can cheaply precheck that the target file already contains identical content, it should stop before overwriting and return/throw a terminal no-op result.
• If an edit request has identical old/new text, it should be blocked before execution as a no-op.
• If an edit tool returns a canonical no-op result such as No changes made, the wrapper should classify it as terminal rather than allowing the agent to retry the same edit indefinitely.
• Real content changes and new file creation should continue to work normally.

Suggested implementation direction

There are a few possible API shapes. The important semantic boundary is:

• no-op file mutation is not a successful mutation;
• no-op file mutation is also not a normal transient/retryable tool failure;
• it should be terminal for the current tool-loop, with a machine-readable reason such as no-op-write or no-op-edit.

If the current tool runtime already has a terminal tool-loop error type, this could use that. Otherwise, adding a structured denied reason would make this easier to test and easier for frontends to display.

Minimal tests

• write to an existing file with identical content does not rewrite the file and returns a terminal no-op reason.
• write with different content still succeeds.
• write creating a new file still succeeds.
• edit request with identical old/new text is blocked before execution.
• edit result containing canonical No changes made is classified as terminal.
• existing loop detection behavior for genuinely repeated non-noop tools remains unchanged.

Compatibility note

Some callers may currently rely on same-content write being idempotent success. If so, it may be useful to scope this behavior to agent tool-loop execution rather than lower-level file APIs, or to expose a compatibility flag. The key bug is allowing an LLM-controlled tool loop to repeatedly perform or retry no-op mutations as if progress is being made.