Invalid UTF-8 from ReplaceFileContent permanently bricks the conversation (proto marshal fails on every subsequent request)

[yingxiangge]

Summary

A single tool-generated file edit that splits a multi-byte UTF-8 character produces
invalid bytes that enter the conversation history. From that point on every
request fails during protobuf marshaling, and the conversation is permanently
unusable — including --continue. Fixing the file on disk does not help, because
the invalid bytes are already persisted in the conversation store.

Version: agy 1.1.19 (Antigravity CLI)
OS: Linux x86_64
Model: Gemini 3.1 Pro (High)

Impact

• The conversation is bricked with no user-facing recovery path. The only option is
  to abandon it and start a new one.
• The failure message (Agent execution terminated due to error + an Error ID)
  contains nothing pointing at UTF-8, so users misdiagnose it. I initially spent a
  round investigating my network proxy.
• Worst part: the CLI corrupts a source file and then makes itself unable to fix
  it. The only tool that could repair the damage is the one disabled by the damage.

What happened

The agent used ReplaceFileContent to apply a ~240-line block replacement to a
630-line Python source file containing CJK comments. The replacement boundaries
landed in the middle of multi-byte UTF-8 sequences at two offsets:

byte 4926:   "# ⇒ 探测本地代理端口，通了才" <truncated sequence> "_ENV_FILES = ("
byte 19553:  "    return False" <truncated sequence> "安全重发，零重复风险）。"

Result: the file is no longer valid UTF-8 (UnicodeDecodeError: invalid continuation byte), several function definitions were silently swallowed, and
14 modules importing it now fail at import time. No error was raised at write time.

Those same bytes then flowed back into the conversation context, and every
subsequent request failed:

E0823 12:57:46 errorreport.go:223] agent executor error: pre-invocation hook:
  context summarization: proto: field google.protobuf.Value.string_value contains invalid UTF-8
E0823 15:20:13 errorreport.go:223] agent executor error: calling model:
  proto: field google.protobuf.Value.string_value contains invalid UTF-8

15 occurrences in one session. Note the failure point moves from
context summarization to calling model — i.e. it is not confined to one hook.

Notably, the first invalid UTF-8 error appeared ~2 hours before the file on disk
was corrupted, during an earlier run of consecutive ReplaceFileContent calls. So
the context was already poisoned and the on-disk corruption was a symptom — the
agent wrote poisoned bytes back out to a file.

Steps to reproduce

1. Open a file containing multi-byte UTF-8 (CJK comments work well) in a workspace.
2. Have the agent perform a large block replacement whose boundary falls inside a
   multi-byte character. (This is not directly controllable by the user, but is
   reproducible by asking for a large refactor of a file with dense CJK comments.)
3. Observe the file is written without error and is no longer valid UTF-8.
4. Send any further message. Every request now fails with the proto marshal error.
5. agy -c / resuming the conversation reproduces the failure indefinitely.

Expected behavior

Any one of the following would have prevented this:

1. ReplaceFileContent should operate on character boundaries, not byte offsets.
   At minimum, verify the result decodes as UTF-8 before committing the write, and
   fail the tool call instead of writing corruption.
2. Sanitize tool output before it enters the context. A lossy decode
   (errors="replace", yielding U+FFFD) at the tool-result boundary would keep the
   session alive with no meaningful loss of information.
3. Degrade gracefully on marshal failure. Instead of failing the whole request,
   locate the offending message, replace or drop it, and continue. Retrying the same
   unserializable payload can never succeed.

(1) alone stops the corruption; (2) alone stops the bricking; (3) alone provides
recovery. Currently none of the three is present.

Suggested severity

Data-loss adjacent: the CLI silently corrupts user source files. Combined with the
unrecoverable session, I would rate this high.

Workaround for other users

• Do not --continue the affected conversation; start a new one.
• Check any file the agent recently edited with
  iconv -f UTF-8 -t UTF-8 <file> >/dev/null — corruption is silent otherwise.
• Files under version control can be restored with git checkout.