Edit tool's auto-opened Browser-pane preview silently reverts the file being edited

Status Closed — not planned

Maintainer reply None cached

Activity 1 comment · opened Aug 26, 2026 · closed Aug 27, 2026

Bug: Edit tool's auto-opened Browser-pane preview reverts the file being edited (silent data loss)

Summary

Every Edit tool call on an .html file triggers a PostToolUse:Edit hook message ("<file> is now visible in the Browser pane"), which automatically opens a file:// preview tab of that file in the Browser pane. That automatic preview appears to push its own (stale/original) in-memory copy of the file back to disk, silently reverting the edit — the Edit tool still reports "successfully updated," but the file on disk reverts to its pre-edit content within moments.

Impact

Silent data loss. The tool call reports success; there is no error or warning that the write was undone.
Reproduced with edits as small as inserting a single HTML comment — not related to edit size.
The revert isn't just "undo the last edit" — it restores the file all the way back to an earlier snapshot, discarding all accumulated changes made in the session up to that point (including ones made via other means, e.g. direct filesystem writes from a Bash-invoked script), not just the most recent Edit call.

Reproduction steps

Have an .html file open for editing that lives outside the current project/git working directory (in my case: an installed Electron app's runtime folder under %LOCALAPPDATA%\Programs\<app>\resources\app\, not the git repo).
Call the Edit tool to make any change, e.g. insert <!DOCTYPE html> at the top of the file.
Observe the PostToolUse:Edit hook message: "<file> is now visible in the Browser pane."
Immediately re-read the file from disk via a means outside the Edit/Read tool tracking (e.g., a Bash grep/cat, or a Node script run via the Bash tool).
The inserted marker is absent — the file has reverted to its pre-edit content.
Closing the auto-opened Browser-pane tab (via preview_list → tabs_close) before the next Edit call does not prevent the issue — a fresh Edit call re-opens a new tab and the revert happens again.

What did not revert

Edits made via Bash-invoked Node scripts (fs.readFileSync / fs.writeFileSync) to the same file, verified immediately afterward via Bash, persisted correctly and permanently.
Edit tool calls on .js files in the same directory, in the same session, persisted correctly — I never observed the "now visible in the Browser pane" hook message for those. The issue appears specific to file types that trigger the auto-preview hook (HTML in my case).

Environment

Claude Code CLI, Windows 11, PowerShell/Git-Bash mixed shell tools available.
Target files were under an installed application's directory (not the session's git-tracked project directory) — flagging in case the auto-preview/hook behavior is scoped differently for in-project vs. out-of-project paths.
Model: Sonnet 5, in an active session with mcp__Claude_Browser__* tools available.

Suggested fix directions

The PostToolUse:Edit hook should not auto-open a live preview of a file that was just written, if doing so can result in that preview's cached/stale content being written back to disk.
At minimum, whatever writes back to disk from the Browser-pane preview should never fire automatically/silently — and the Edit tool's success message should not be reported until the write is confirmed durable (i.e., not going to be reverted by a subsequent automatic action).
Consider not auto-opening a preview at all for files outside the project's working directory, since there's no legitimate use for the app to "manage" or "checkpoint" files it doesn't own.

Workaround used

Avoided the Edit/Write tools entirely for affected files; used the Bash tool to run Node.js scripts that read, transform, and write the file directly, verifying the result immediately afterward with a separate Bash-invoked grep/wc -l check.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗