Gemini models corrupts large UTF-8 source files during surgical edits

[honeypie_3301]

Google AI Studio Build Mode is corrupting my large source files when Gemini 3.7 Flash is asked to make a small, surgical code change.

The files are approximately 13,000 lines each. Gemini is explicitly instructed to modify only the requested code and preserve everything else. Instead, after the edit, parts of the file become corrupted and contain large amounts of replacement characters (�), control characters, and binary-looking garbage.

This makes the source file unusable.

• Google AI Studio / Build Mode

• Model: Gemini 3.7 Flash

• Windows desktop

• Browser: Opera

• Source files: large Java/Minecraft AI source files stored as .txt

• File size: approximately 13,000 lines per file

• Encoding before editing: UTF-8

• Task: surgical modification of existing code

I have also tested different browsers, accounts, and disabled browser extensions. The problem persists.

The request was for a small, surgical modification to an existing large source file.

I specifically instructed Gemini to:

• modify only the requested functionality

• preserve all existing behavior

• preserve existing combos and logic

• avoid rewriting unrelated code

• make a surgical change rather than regenerate the entire file

After Gemini performed the edit, the file displayed normally for part of its contents, but another section became corrupted.

The corrupted section contains things resembling:

There are also large numbers of Unicode replacement characters (�).

This is visible directly in the AI Studio code editor.

The screenshot attached to this report shows the issue occurring inside the affected file.

If Gemini is unable to safely modify a 13,000-line file, I would expect it to:

1. Refuse the operation.

2. Explain that the file is too large for reliable rewriting.

3. Ask me to provide a smaller relevant section.

4. Or make a genuine surgical patch.

It should never silently replace valid UTF-8 source code with corrupted/binary-looking content.

This is not merely an incorrect code change.

The problem is that the underlying source file can become corrupted.

A coding assistant can make an incorrect implementation and the developer can fix it. However, if the assistant damages the source file itself, it can cause loss of working code and make it difficult to determine which parts of the original file were modified.

This is especially concerning for large files where manually comparing thousands of lines is difficult.

The problem appears more likely when working with large files and asking for targeted modifications.

The affected files are around 13,000 lines, which should not be anywhere near Gemini’s advertised context capacity.

I understand that context-window size and safe file rewriting are different things. However, if AI Studio cannot reliably edit files of this size, it should avoid silently regenerating or corrupting them.

1. Is this a known Build Mode issue with large text/source files?

2. Is AI Studio recreating entire files rather than applying true surgical patches?

3. Is there a known limitation around large UTF-8 files?

4. Why can the resulting workspace file contain replacement characters and control/binary-looking data?

5. Is there a recommended maximum file size/line count for reliable Build Mode editing?

6. Is there a way to force Build Mode to apply a patch/diff instead of regenerating the entire file?

7. Can the engineering team investigate the attached example?

I would appreciate confirmation from the AI Studio team about whether this is a known issue.

[DaveK]

Almost certainly related:

AI Studio development environment has become unreliable — is there an ongoing upgrade?

Over the last two hours, AI Studio has become effectively unusable for continued development of my existing application. I am repeatedly seeing: Canceled An internal error occurred terminal 1 error running the code turns ending without Action History operations whose actual workspace result is unclear This is happening even on relatively small tasks. More importantly, I have also confirmed repeated binary image corruption in the workspace. Previously valid JPEG files now contain UTF-8 repla…

It seems to occur for any kind of binary file, or I guess now anything that isn’t plain ASCII. It’s clearly a bug in the workspace environment, but we haven’t been able to get help from Google engineers yet.

[Eep]

I asked Gemini about it and here’s its official bug report I asked it to create (which I submitted to the in-app “Submit bug” option):

Monaco Code Editor fails to inflate/decompress secondary transport chunks for workspace files, rendering raw zlib binary streams in the UI.

Description:
When opening any text file larger than 524,288 bytes (512 KiB) in the AI Studio workspace “Code” editor pane, the editor displays clean plain text up to byte offset 524,288, but immediately displays raw compressed binary characters (e.g. x\x9c\xed\xbd... / zlib stream payload) from offset 524,289 through the end of the file.
The underlying file on the container disk is 100% valid, uncorrupted UTF-8 text, and the application preview runs normally. The issue lies entirely in the web frontend’s file-sync transport deserializer / Monaco receiver.

Root Cause & Technical Details:

1. Chunked Transport Layer: The workspace file streaming service splits files exceeding 512 KiB (524,288 bytes) into chunks:

• Chunk 0 (0 – 524,288 bytes): Sent as plain text.
• Chunk 1+ (524,288+ bytes): Sent as a compressed zlib deflate stream.

2. Missing In-Browser Decompression: The web client’s Monaco file receiver concatenates the raw binary buffer of Chunk 1 directly onto Chunk 0 without calling zlib.inflate() / decompression on the secondary chunk.

3. Result: The user interface displays raw compressed bytes starting at the 512 KiB mark, preventing code viewing, manual editing, and browser-based file exports for files over 512 KiB.

Steps to Reproduce:

1. Create or open any single text file in the workspace (e.g., index.html or bundle.js) with a size of valid ASCII/UTF-8 code.
2. Open the file in the Code tab inside Google AI Studio.
3. Scroll down to the exact byte offset corresponding to 524,288 bytes.
4. Observe that code prior to this point renders correctly, but the remainder of the file appears as garbled zlib binary text (xr...).

Expected Behavior:
The Monaco file transport layer should decompress/inflate all secondary chunks before populating the editor model buffer, displaying 100% plain text across the entire file regardless of file size.

Environment Info:

• Platform: Google AI Studio Build (Cloud Run Workspace Container)
• Component: In-Browser Code Tab / Monaco Editor File Sync Transport
• Chunking Threshold: 524,288 bytes (512 KiB)

[Shlomo_Dvir]

I found a practical workaround that may be useful for anyone affected by the binary file corruption issue.

In my case, JPG files that were added or replaced directly inside the AI Studio workspace could become corrupted.

However, I tested a different workflow:

1. Add the correct JPG file directly to the canonical GitHub repository.

2. Let AI Studio receive it through the new bidirectional GitHub synchronization.

3. Continue normal development and perform additional Studio ↔ GitHub syncs.

So far, the important result is that the JPG received from GitHub has remained intact through subsequent bidirectional synchronization cycles. Studio has not corrupted it again.

This does not mean that the underlying corruption bug is fixed, and I cannot say whether this helps with the newly reported UTF-8/source-file corruption issue.

But for binary assets such as JPG files, using GitHub as the source of the file and letting Studio import it through bidirectional sync appears, in my testing, to be an effective workaround.

I thought this was worth sharing because it may allow affected users to restore binary assets without having Studio rewrite them.

[FuturisticSignal]

Been experiencing the same thing, my project randomly broke out of nowhere and seemingly I found out one of the scripts in my project suddenly has a bunch of binary code and unreadable stuff in there and I tried fixing it only for the AI to continue breaking the project and I don’t want to move my project elsewhere again (Mine doesn’t have any .JPG images at all)

[Payal_Sharma2]

Hello, this issue has now been fixed. Could you please recheck on your end and let us know if you are still experiencing any file corruption issues?

[honeypie_3301]

In a new chat, I tested Gemini by asking it to remove a single comment in very bottom of the code.

Before

After

It’s not fixed.

[Eep]

Definitely not fixed! Did you see my first reply in this thread?

[Jon_Matthews]

Just confirmed with eng that the fix is now rolled out. If you still see it, please let us know.

[honeypie_3301]

Thanks for the fix. I verified it by having Gemini perform a surgical edit to remove a comment near the bottom of a large file again, and it worked cleanly without any corruption.

Out of curiosity, what is the new file size/chunk limit for the Monaco editor in AI Studio now? My files might keep growing, so I’d like to know if there’s a threshold I should keep in mind to avoid running into chunking limits again in the future.

[Eep]

Not fixed for me. I did a forced-cache reset (Ctrl-Shift-R) of the page (no local overrides either):

When I closed/reopened the GAIS tab, I get that locked file issue so I can’t access the index.html file (and there’s a bun.lock file. Then I asked Gemini to unlock them (this has happened a few times now since I first encountered this UTF-8 corruption) and it says “There are concurrent updates.” and to ‘retry’, but it’s still working (still stuck at 0s though for ~5 minutes now) so I retried but then it showed the ‘resolve conflicts’ overlay (which takes like at least 30 seconds between what I click on before it responds) but that still shows UTF-8 characters:

However, upon resolving this conflict, index.htmlstill has the same corruption at the exact same place.

Update after posting this about 10 minutes later: OK, after I just reloaded (well, went back to the first GAIS page in my web browser tab’s history), index.html no longer shows any UTF-8 corruption.

[Eep]

I tried to restore my project to before when these UTF-8 corruption errors started happening, but the restored file still shows the corruption–nevermind; it was still after the 512KiB corruption happened ~2 weeks before…this bug has set me back. Google, you need to test this way more thoroughly before unleashing it onto the public! Stop “moving fast and breaking things” and start “moving cautiously and fixing things”.