Preview AI File Edits with MCP Filesystem Dry Run

To review AI file edits before they reach disk, call edit_file with dryRun: true, inspect the proposed diff, then separately authorize the write. RedFox MCP Filesystem supports that preview workflow. For a release-note update, keep the file list small, anchor each replacement to the current release section, and read the files again after applying changes. A preview is not a backup, an approval lock or proof that the release information is correct.

This guide is for a developer or documentation maintainer who already has a working filesystem connection and needs to update an existing release-note set without rewriting unrelated content. The example below is fictional; the tool behavior is based on the linked RedFox documentation and source, not a recorded client session. If your first read fails, use our filesystem access troubleshooting guide first.

Choose a targeted edit, not a whole-file rewrite

Suppose a small app’s next release is approved as version 2.4.1, with one confirmed change: “Fix offline export filenames.” Your job is to update the pending release section, its README summary and a local release manifest. You are not changing product code, publishing a package or editing past release history.

RedFox MCP Filesystem exposes read_file, read_multiple_files, search_files and edit_file. Its documented edit preview lets you inspect a replacement without applying it. That is useful when the existing file contains history, links or wording you need to preserve.

This is a longstanding reader need, not a new trend claim: the original upstream filesystem feature request asked for smaller targeted changes instead of relying on whole-file writes. It concerns the reference server, not a RedFox customer result or a benchmark. Here, the concrete implementation is RedFox’s package, @redf0x1/mcp-server-filesystem; another package with “filesystem” in its name may expose a different schema.

1. Define the release boundary before asking the agent to edit

Start in a disposable project copy or a working tree whose existing changes you can identify and recover. Keep a separate backup or use your normal version-control recovery process. Do not make your only copy of unpublished work the first experiment.

For this fictional release, the allowed edit set is:

• CHANGELOG.md: replace only the complete pending-release block with the approved version and fix description.
• README.md: update only the current-release summary. Leave installation commands and archived examples alone.
• release.json: update only the release version and approved summary. This is an illustrative local manifest, not a standard package-manager file.

Configure the server for the needed project folder, not your whole home directory. Use server-visible absolute paths in the tool calls. For initial connection work, see our MCP setup guide and the package’s own instructions. The plan below needs file reads and targeted edits; it does not need shell commands, deletion, moving files or publishing tools. Use client-enforced tool permissions where available: an instruction in chat is not an access-control boundary.

A useful opening request is:

Inspect only CHANGELOG.md, README.md and release.json in this project. The approved release is 2.4.1 and its approved summary is “Fix offline export filenames.” First return the existing relevant sections and a per-file change plan. Do not write, delete, move, run commands or publish anything. Flag any inconsistent version or ambiguous replacement instead of guessing.

2. Read the relevant files and preserve a baseline

Use read_multiple_files for a small known set, or read_file for one file. Inspect each returned result; RedFox’s batch handler includes individual file errors in its returned text. One successful file does not establish that the entire set was read.

If you do not know the filenames, use search_files to locate candidates by filename or path pattern, then read the candidates. Do not treat a filename match as a search for every occurrence of a version inside file contents. The search implementation matches paths and names; the content review is a separate step.

Save the original contents or a diffable baseline outside the agent’s edit scope. Identify unrelated work already present before the operation. If 2.4.0 appears in an archived release, a migration example and the current release, “replace 2.4.0 everywhere” is the wrong instruction. Select a unique block with enough surrounding context to identify the intended section.

Short head/tail previews can help orient you, but read every section that will be changed. In the inspected RedFox implementation, those previews still read the file as UTF-8 before slicing its lines; they are not a way to make a huge or binary file safe to edit.

3. Request an explicit dry run for one file

RedFox’s edit schema takes path, an edits array containing oldText and newText, plus dryRun and skipValidation. dryRun defaults to false. Omitting it is not a preview request. Set dryRun: true explicitly and keep skipValidation: false.

This illustrative tool-name/argument pair previews one existing block. It is not captured output or a complete JSON-RPC message; your MCP client supplies the protocol envelope. Substitute a real server-visible path and text that you have just read:

{
  "name": "edit_file",
  "arguments": {
    "path": "/Users/alex/projects/release-demo/CHANGELOG.md",
    "edits": [
      {
        "oldText": "## Unreleased\n\n- Fix export filenames.",
        "newText": "## 2.4.1\n\n- Fix offline export filenames."
      }
    ],
    "dryRun": true,
    "skipValidation": false
  }
}

The edit implementation constructs modified content and a unified diff, but performs the file write only when dryRun is false. Inspect both the tool’s error status and its returned text. If the client reports an error or the preview is missing, you have not completed this review step.

4. Review meaning, matching and validation separately

A plausible-looking diff can still be the wrong edit. Check these three things before authorizing an apply:

• Meaning: the new version and fix description match approved release facts. No invented dates, compatibility promises or extra fixes have appeared.
• Location and scope: the diff changes the intended pending block, preserves archived entries and leaves unrelated lines alone. Review context, not just the added green line.
• File validity: the proposed result remains valid for its format. That is separate from whether the release facts are true.

The inspected implementation reads and writes UTF-8 and normalizes CRLF line endings to LF across the file. Its preview compares normalized content, so it does not show that line-ending conversion. Check the project’s encoding and line-ending requirements before applying; if CRLF must be preserved, use an editing method that preserves it.

After line-ending normalization, the inspected matching code replaces the first exact occurrence. If that fails, it tries a line-by-line match with trimmed whitespace and uses the first matching block. It is not a uniqueness check or a global replace-all operation. If the same block appears twice, make oldText more specific and preview again; do not assume the tool chose the section you meant.

Validation is also format-dependent. The validation dispatcher handles recognized code and structured-data formats, including JSON. Types without a dedicated validator, including Markdown, fall through as valid. A “validation passed” message for Markdown is therefore not a Markdown lint, link check or editorial review. Even valid JSON can contain the wrong release version.

Preview the README and manifest changes independently, with the same release facts. For the manifest, preserve its other keys and review the JSON result. Do not turn off validation simply to make a failed edit appear successful; inspect the proposed text and use the project’s normal validator when the built-in check is insufficient.

5. Apply the reviewed edit, then read back the actual file

Keep one writer on these files while reviewing and applying. Immediately before the write, confirm that the current contents still match the baseline you reviewed. If a teammate, editor or agent changed a file, stop and generate a fresh preview from that content.

A dry run does not reserve the file or bind a later write to the reviewed bytes. The apply call reads the file again and recomputes the replacement. Atomic replacement of one file is not a multi-file transaction, an automatic rollback or protection against another writer changing the content between your check and the write.

After approving one file’s exact path and replacement, send that same edit with dryRun: false explicitly. Keep skipValidation: false. Then read that file again and compare the actual content with the approved result before proceeding to the next file.

If this is a Git working tree, git diff -- CHANGELOG.md README.md release.json shows unstaged changes relative to the index, as explained in the Git diff documentation. It does not isolate this agent’s changes if the files were already dirty, and it does not include staged changes or new untracked files in that view. Compare against your saved baseline as well. Run the project’s normal documentation, JSON and link checks; do not interpret a tool success message as those checks having run.

If a write times out or the client disconnects, inspect the exact file before retrying. It may already contain the new text. If one file was updated and the next failed, preserve that partial state, review the differences and decide whether to finish or restore only your changes. Do not reset the entire working tree or rerun a broad replacement over someone else’s edits.

A release-edit acceptance checklist

Call the local update complete only when you can answer yes to all of these:

1. The file list and release facts were fixed before editing.
2. Every intended file was read successfully and had a recoverable baseline.
3. Every edit had an explicit dry-run preview with the intended context.
4. The preview changed only the approved release information.
5. The files were unchanged by other writers before each apply.
6. The applied files were read back and compared with the approved results.
7. The project’s applicable checks actually ran, with results recorded.

That outcome is an updated local release-note set. It does not mean the release was tagged, committed, pushed, packaged or published. Keep those actions separately authorized.

MCP Filesystem dry-run FAQ

Does a dry run create a backup?

No. In the inspected implementation it returns a proposed diff without applying that edit. Preserve your own baseline and recovery copy before allowing writes.

Will edit_file update every matching version string?

No. The inspected RedFox code selects the first exact match or first supported whitespace-flexible block for each edit. Use a unique contextual block and inspect the diff; do not use it as an assumed replace-all.

Is a chat instruction enough to enforce preview-only access?

No. A request to “preview only” tells the assistant your intent, but does not remove its write capabilities. Use the client’s permission controls where supported, work on a disposable copy and inspect the actual arguments, especially dryRun.

Try one reviewed release edit

Start with one small, non-sensitive release-note file. Use RedFox MCP Filesystem to read it, request an explicit preview and compare the proposed diff with your approved release facts. Expand to the rest of the set only after the applied file has been read back successfully.

Auto-Bot.io is the editorial publisher, separate from RedFox. This source-based guide describes the linked implementation inspected on October 14, 2026; check the schema exposed by your installed version. The featured image is a conceptual illustration of reviewing edits, not a product screenshot or evidence of an executed test.