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.