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

Google AI Studio
,
1

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 replacement bytes (EF BF BD) instead of valid JPEG headers and can no longer be decoded.

At this point my main concern is no longer a specific prompt or application bug. I can no longer reliably trust the persistence and integrity of the AI Studio development environment itself.

I previously received a forum response saying that Studio is undergoing an upgrade and should return to normal after the engineering team completes it. However, I have not been able to verify this through any official Google status page or announcement, and I have not received an answer about where this upgrade status is published.

Could someone from the AI Studio team please confirm officially:

  1. Is AI Studio currently undergoing an infrastructure/workspace upgrade?
  2. Are these failures part of a known temporary issue?
  3. When is it expected to be safe to resume normal development?

I would very much prefer to continue developing this application in AI Studio rather than move the project to another service, but right now I need to know whether the environment can be trusted again and when.

2

I’ve seen the issue with UTF-8 replacement bytes in images (PNG in my case), but I think it’s an artifact of the infrastructure and the actual workspace files are ok. I asked Gemini to configure nginx to serve the files to me, and it gave me URLs for both directly viewing and downloading the image files, which delivered them without any UTF-8 corruption.

3

Thanks Dave. That is very interesting. In my case I checked the files
directly in the workspace: the on-disk JPEG itself begins with EF BF
BD, the JPEG decoder fails, and the Preview HTTP response has exactly
the same SHA-256 as that corrupted workspace file. So it appears my
case may be different from yours and the corruption has actually
reached the workspace file. Did you also inspect the raw on-disk bytes
/ SHA-256 before serving through nginx?

4

Hi Shlomo,

How exactly did you check the file in the workspace? In my case, I saw the corruption regardless whether I a) downloaded the file using the context menu in the workspace file explorer, b) downloaded the entire project as a zip, or c) downloaded the version that has been synced to GitHub. Yet somehow, it was correct when served by nginx. Beats me how that works; we’d need input from a Google engineer to understand it.

5

Update: we now have a concrete failure from Cloud Run.

The application itself builds successfully in the AI Studio workspace, and the currently deployed revision remains healthy.

However, every new AI Studio Publish attempt fails while creating the next Cloud Run revision.

Cloud Run reports explicitly:

“The provided source archive is corrupted.”

Latest failing revision:
weddingflow-ai-0076-z4t
Region: europe-west2

AI Studio subsequently inspected the available environment and reported that the deployment source archive is created/handled by the AI Studio managed Publish infrastructure and is not accessible from the Applet workspace for direct validation.

So at this point I have stopped changing application code. The blocker appears to be in the AI Studio → Cloud Run Publish/package handoff rather than in the running application.

I would appreciate confirmation from the AI Studio team whether this is a known platform issue and whether it is currently safe to continue development.

I am particularly reluctant to abandon AI Studio and migrate the application elsewhere, but I also cannot risk losing a long-running application because its development/deployment workspace is no longer reliable.

6

By the way, here’s a handy trick I’ve been using: I asked Gemini

Please run npx --package=bash – bash -c “od -x /app/applet/feature_graphic.png | head -1”

However, when I tried it today, I saw:

0000000 bfef 50bd 474e 0a0d 0a1a 0000 0d00 4849

So now my PNG is corrupted too. I don’t know exactly when that happened. It was originally located in app/src/main/res/drawable, but Gemini relocated it to the root dir when I asked it to build the AAB for release. Now I can’t tell if it got corrupted when copying it from one location to the other; or if there is perhaps a serialisation issue when the workspace gets quiesced and restored; or if the infrastructure assumes that only some directories contain binary files, and applies text processing to the rest.

This could also relate to the trouble I’ve had when I asked it to copy the debug APK to the root directory so that I can easily download and install it on my device. It usually works while I’m in the middle of a build-and-test cycle, but then I often find that the APK has been corrupted and truncated when I come back to it after a while.

Google engineers, please help us!

7

UPDATE — August 13

I spent essentially the entire day recovering from this problem.

Since the original AI Studio Applet could no longer publish successfully and Cloud Run repeatedly reported:

“The provided source archive is corrupted.”

I created a REMIX of the application and then had to reconnect and verify all of the surrounding production pieces: the existing Supabase backend and authentication, application secrets, the new Cloud Run service, Firebase Hosting, and finally the custom production domain.

After a full day of work, the REMIX application is now running successfully in production again.

But the binary image corruption problem has returned as well.

The social-preview JPG files that we had previously repaired and verified as valid are corrupted again after going through the AI Studio environment/publishing process.

So at this point I am giving up on the social-preview functionality for now. I cannot keep spending hours repairing binary assets only to have them become corrupted again.

Dave’s report above is particularly concerning because he is now seeing very similar corruption with PNG and APK files. This increasingly looks like an AI Studio workspace / persistence / serialization / binary-file handling problem rather than something specific to our individual applications.

I also have no idea how long this new REMIX environment will remain healthy before it develops the same kind of problems as the original Applet.

Google engineers: please investigate this.

And if it is already being investigated, please at least acknowledge the issue and let us know that someone is working on it.

At the moment we are spending substantial time rebuilding and working around what appears to be an infrastructure-level problem, without knowing whether our workspaces and binary assets can be trusted to remain intact.

8

Hi

Thank you for sharing this

For the issue around binary assets becoming corrupted, does it happen when you upload them to github ? or when you are deploying the application to Cloud run ?

9

Please see my earlier post, where I said

In my case, I saw the corruption regardless whether I a) downloaded the file using the context menu in the workspace file explorer, b) downloaded the entire project as a zip, or c) downloaded the version that has been synced to GitHub.

10

Also, from my other post:

now my PNG is corrupted too. I don’t know exactly when that happened. It was originally located in app/src/main/res/drawable, but Gemini relocated it to the root dir when I asked it to build the AAB for release. Now I can’t tell if it got corrupted when copying it from one location to the other; or if there is perhaps a serialisation issue when the workspace gets quiesced and restored; or if the infrastructure assumes that only some directories contain binary files, and applies text processing to the rest.

11

Hi,

No, the source of truth for my live app is AI studio and not Github.

12

See Gemini models corrupts large UTF-8 source files during surgical edits - #3 by Eep for a complete breakdown of why this occurs (according to Gemini).

13

A fix has now be rolled out for the UTF-8 replacement issue. If you still see it, please let us know.