`edit` tool rewrites the whole file when `oldText` doesn't match exactly

[lucky-verma]

Describe the bug

The edit tool from @cloudflare/computer/tools saves a rewritten copy of the whole file whenever oldText doesn't match exactly.

When the exact match misses, matching falls back to a loosened copy of the file: trailing whitespace stripped from every line, smart quotes and dashes flattened to ASCII, Unicode normalization applied. The fallback itself is fine. The problem is that applyEditsToNormalizedContent then uses that same loosened copy as the base for the write, so the whole file gets saved in loosened form.

The diff the tool returns is computed between the loosened copy and the loosened copy plus the edit, so none of the extra changes show up in the result. The caller sees a clean one line change.

One stray trailing space in oldText is enough to trigger it.

Expected behavior

Only the text the edit targeted changes. The rest of the file stays byte for byte identical, and the returned diff and patch describe what actually landed.

Steps to reproduce

1. Save this as packages/computer/src/tools/fs/repro.test.ts. The quotes around must are U+201C/U+201D, the dash is U+2014, and the two trailing spaces after optional. are a Markdown line break, so all three matter.

import { SQLiteTestStorage } from "@cloudflare/dofs/testing";
import { expect, it } from "vitest";

import { Workspace } from "../../workspace.js";
import { createAITools } from "../index.js";

it("only changes the text the edit targeted", async () => {
  const workspace = new Workspace({ storage: new SQLiteTestStorage() });
  const tools = createAITools({ workspace });

  const original = 'The spec says “must” — not optional.  \nlet target = 1;\n';
  await workspace.fs.mkdir("/workspace", { recursive: true });
  await workspace.fs.writeFile("/workspace/notes.md", original);

  // One stray trailing space, so the exact match misses.
  const result = await tools.edit.execute(
    {
      path: "/workspace/notes.md",
      edits: [{ oldText: "let target = 1; ", newText: "let target = 2;" }],
    },
    { toolCallId: "1", messages: [] },
  );

  console.log("reported diff:\n%s", result.diff);
  await expect(workspace.fs.readFile("/workspace/notes.md", "utf8")).resolves.toBe(
    original.replace("let target = 1;", "let target = 2;"),
  );
});

2. Run npm test --workspace @cloudflare/computer -- src/tools/fs/repro.test.ts

3. The test fails. On disk the first line comes back as The spec says "must" - not optional., with ASCII quotes, a plain hyphen and no trailing spaces, so the Markdown line break is gone too. The logged diff only mentions the let target line.

Environment

@cloudflare/computer 0.1.0-alpha.1 at 76d9e75, Node 22.22.2 on Linux, run through the package's own vitest config. No Workers or Containers setup needed, since the tool runs against a Workspace backed by SQLiteTestStorage.

---

Happy to send a fix if you want one. What I have working locally keeps the loosened copy for matching, but records where each of its characters came from in the original, so the replacement can be spliced into the original file instead. Two cases have no honest source range and error out rather than guess: Unicode normalization merging a letter and an accent into a single character, and a match covering half of a character that expanded, like "af" against the ligature in "afib". edit-diff.ts has no tests today so it comes with them, plus one at the workspace level that reads the file back after an edit. Full suite passes.

Opening this as an issue rather than a pull request, since I see external ones get closed automatically without the allow-pr label.

[3x3xX3N0N]

Independent reproduction, in case a second data point helps this get triaged — your repro runs verbatim and fails the same way at 76d9e75, on Windows/Node 22 rather than Linux, so it is not platform-specific:

- The spec says “must” — not optional.··
+ The spec says "must" - not optional.
  let target = 2;

Three separate corruptions from one stray trailing space in oldText: smart quotes flattened to ASCII, the em dash to a hyphen, and the two trailing spaces stripped — so the Markdown hard line break is silently destroyed as well. The reported diff mentions only the let target line, exactly as you describe, which is what makes this nasty: an agent editing a file gets a clean-looking one-line diff back while the rest of the file is quietly rewritten.

Worth underlining that last part for anyone triaging: the caller has no signal. An agent loop that trusts the returned diff will keep editing, and the corruption compounds across turns.

I am deliberately not sending a patch — you said you have one working locally, and your approach (keep the loosened copy for matching but track each character's provenance back to the original) sounds right, including erroring out on the two cases with no honest source range rather than guessing. Duplicating that would just create a second thing to review.

Also confirming your read on process, since it cost me a while to work out independently: allow-pr does appear to be the gate — the repo defines it and currently uses no labels at all, and CONTRIBUTING.md says unsolicited PRs may be closed and redirected.

[lucky-verma]

Reproduces on Windows too, per the comment above.

Fix is written with tests and the full suite passes. Can you add allow-pr so I can open the PR?

[aron-cf]

Hey @agent-think can you reproduce, then open a PR to fix this one.

[frydiana11853]

🤝 测试覆盖到关键路径了吗

[serranonicholas8851]

萌新刚开始造轮子，有没有入门建议 👍🧠🙌