The replace_file_content tool corrupts the conversation

Google Antigravity
1

The `replace_file_content` tool may corrupt files containing Japanese (CJK) text by truncating multi-byte UTF-8 characters at byte boundaries, potentially generating invalid UTF-8 sequences. There have been multiple instances where this file corruption has caused sessions to crash completely.

## Steps to Reproduce

Create a Markdown file containing a large amount of Japanese text (500 lines or more, approximately 35 KB).

Within the same session, use `replace_file_content` to make multiple edits to that file.

In subsequent calls to `replace_file_content`, the tool edits at unintended positions (outside the StartLine/EndLine range), causing Japanese characters to be truncated mid-byte during the replacement process.

## In my case

Bug 1:

I specified StartLine: 264, EndLine: 275 (a table at the bottom of the file)

The resulting diff shows changes at @@ -98,24 +98,18 @@ — line 98, far outside the specified range

A completely different section of the file (character metadata headers) was deleted and replaced with the intended table content

Bug 2:

When the replacement is applied at the wrong location, the byte-level operation can split a multi-byte UTF-8 character.

Original text at line 101: …彼の性格的に

After replacement: …彼の�| 時期 | ゴール |

The character 性 (U+6027, UTF-8: E6 80 A7) was split, producing an invalid byte sequence rendered as U+FFFD (�)

This explains why the bug is essentially invisible in English-only workflows but frequently fatal in other language workflows.

Bug 3:

When an error occurs, the session terminates without being able to display or propagate the error details.

## Workaround

For now, when editing Japanese text files, I use python script as a fallback.

It’s inconvenient, but the session won’t die.

Antigravity Version: 2.1.4

OS: Windows 11 (Build 26200)

At the very least, this issue has been occurring since major version 1.

2

Hi @manteins,

We haven’t been able to reproduce this unexpected behavior based on your description. To help us better assist you and investigate this further, could you please provide a few additional details?

  • Is this behavior observed with all models or only a specific one?
  • A sample markdown file and the modification prompt you are using

Additionally, we recommend submitting a report using the in-product menu: navigate to Settings > Antigravity Settings > Provide feedback. Please ensure the “Include diagnostics” box is checked to capture a Trace ID, as this will greatly help us investigate the issue further.

3

Hi @Siddharth_Naik,
Thank you for looking into this.

Model Information

This issue has been observed across multiple models — it is not model-specific:

  • Gemini 3.5 Flash (Medium) : Most frequent; produced the majority of errors in my logs
  • Gemini 3.5 Flash (High) : Confirmed across multiple sessions
  • Gemini 3.1 Pro (High) : Confirmed in at least 1 session
  • Claude Opus 4.6 (Thinking) : 1 confirmed case of silent corruption (no error returned, but file was damaged)

The corruption occurs with both replace_file_content and multi_replace_file_content. I have never observed this with write_to_file.
From analyzing my conversation transcripts (transcript.jsonl), I identified 12 unique crash-causing errors across 4 sessions, plus 1 case of silent corruption (the tool returned success, but the file contained U+FFFD replacement characters).

### Regarding Sample Files and Prompts

Unfortunately, I’m unable to share the specific markdown files or prompts used in these sessions, as they contain confidential content. However, the files are:

  • Format: Standard Markdown (`.md`) or Text format (.txt)
  • Content: Primarily Japanese (CJK) text, 10,000–30,000+ characters per file
  • Encoding: UTF-8 without BOM
  • Line endings: Were CRLF at the time of the errors (have since been normalized to LF via .gitattributes)

Next Steps

Since you weren’t able to reproduce it, I will submit a feedback report via Settings > Antigravity Settings > Provide feedback (with “Include diagnostics” checked) the next time this occurs.

Thank you again for your support!