Title:
Markdown Preview fails to sync/update after file is modified by agent tool calls
Environment Info:
Description:
When a markdown file (e.g., allissues.md) is modified externally by an agent (e.g., via file modification tool calls like multi_replace_file_content), the editor tab correctly updates to reflect the new text. However, the Markdown Preview panel does not update and remains stuck rendering the old cached version of the file.
Closing and reopening the preview tab or trying to save the file does not force the preview to update. The only way to clear the cache and force the preview to display the correct contents is by executing Developer: Reload Window.
Steps to Reproduce:
-
Open a markdown file in the editor and open its Markdown Preview side-by-side.
-
Have an agent modify the file using file-editing tools (writing directly to disk).
-
The editor pane updates with the changes, but the Markdown Preview panel still displays the old version.
-
Close the preview tab, right-click the markdown file, and select Open Preview. The new preview still renders the old version.
Expected Behavior:
The Markdown Preview should detect when the file on disk has been updated (or at least when the preview is closed and reopened) and re-render the latest content.
Actual Behavior:
The preview caches the older state of the file and ignores subsequent updates until a full window reload is performed.
Yes, this is super annoying. Now I’m used to close opened Artifacts after reviewing them. Please fix. Thanks.
just ask agent something like “hey, implementation plan is not updated”
i´ve constantly having those “bugs”
Also, many times, he write the entire md plan on the chat instead of showing me the artifact.
Again, “hey, show me the artifact”
Do not close things, just ask agent to fix the issue.
Hi @Jerry_Haygood,
Welcome to the forum!
I tested this on my end using Antigravity 2.0.10 based on your description, but it currently appears to be working as expected, and I am unable to replicate the Markdown Preview getting stuck after an agent modifies the file.
This might be related to your specific environment, or it could be a corrupted UI state caching the older file view. Could you please confirm if you are still experiencing this issue?
If you are, to help us investigate further and reproduce the exact conditions, could you please share:
- A screen recording or screenshot of the editor updating while the preview remains stuck
- Your operating system (Windows, macOS, or Linux)
Hi Siddharth,
Yes, I am still experiencing this issue.
To answer your questions:
-
Operating System: Windows 11, Antigravity 2.0.11
-
Reproduction: The bug occurs whenever a Markdown (.md) file is modified by an agent via a file modification tool call. The preview panel simply does not display the recent changes. It doesn’t matter if the preview pane is already open side-by-side or if you open it after the fact—the Markdown Preview remains completely stuck rendering the old cached version of the file until a full Developer: Reload Window is executed.
Since multiple users on this thread are reporting this exact same behavior with .md files and agent tools, it points directly to a core application bug where the markdown preview component fails to read the updated file from disk after an automated tool write.
Yes, and this bug was there from the start. Antigravity 2.0 shipped with it from day one. very annoying!
No no no that not the issue, the agent did indeed updated the file, is just Antigravity that isn’t aware of the change, is a silly bug. If you navigate to the folder where the implementation plan is stored you will see it updated.
The behavior you observe about it printing it into the chat again when you notify the implementation plan is “outdated” is because the agent has nothing to update, so it gives it to you again via chat to prevent friction (it actually causes more friction).
Hi Siddharth,
To follow up on my previous message, please see the comments from Luiz and DrQwertySilence below.
DrQwertySilence highlighted the exact nuance of this bug: the agent is successfully writing the changes to the disk, and the core text editor panel updates immediately to reflect it. The breakdown is strictly isolated to the Markdown Preview component, which fails to recognize that an external file-system change occurred via the agent’s tool call. It acts completely blind to the update and relies on stale cache until a reload is forced.
This is likely why it didn’t look broken on an initial glance if you were only watching the agent’s output or the primary editor tab.
I am working on capturing that side-by-side screen recording now to show you the exact sequence of the editor updating while the preview panel remains frozen.