HOWTO: enable “real” code execution in AI Studio (e.g., with 3.8 Flash)

[Ilya_Zakharevich]

Currently, a step right or a step left would permanently disable code execution in a particular chat session in AI Studio. These bugs were reported multiple times:

Code execution switched off if a PDF is attached

Why can’t I attach a PDF reference material (such as a scientific paper or a part of a handbook) to a dialog to help the model write the code without me carrying it over to Google Colab for running every time? The code execution toggle-switch grays out immediately once I do this and the model isn’t able to run its own code anymore, even if it was in the previous turns of the conversation

Code execution tool is disabled

For a week or so I am not able to enable code execution tool on playground on AI Studio. I really don’t understand how a company like Google with the great people has these kind of issues. I have a pro subscription, first I got exceeded quota, now I don’t but without code execution all of my requests failing after 10 mins.

See also another link on

https://discuss.ai.google.dev/t/chat-failure-due-to-binary-data-from-code-execution/114538

My research shows that what triggers this behavior is one of:

• Uploading a file visible to ls (i.e., having no leading dot in the file name).
• When a code section creates a file visible to ls -R and does not delete it at the end of the turn.

I could not find any security vulnerabilities relate to these — so I think that the obvious trivial workarounds must be OK. Avoiding these operations allows (AFAICS) long sessions with chains of “complex” code execution runs.

The workarounds are:

• Before uploading file, rename it by adding a leading dot to the name. (You can also append .txt to trickier-to-parse file names.)
• Provide the following in your “System Instructions” (on the right of the window; you may need to click the icon in the =TR-corner):

Whatever happens, do not create files visible to `ls -R` in the home directory. A bug in the UI’s download Manager would irrevocably remove code execution permission from this session!  You should also religiously watch for the programs you call to not do this.  For this, you need to restrict all file and execution operations strictly to `/tmp` or a hidden directory like `~/.t/` — whatever is feasible (change the working directory to it too).  Your scripts simply need to create the directory (`os.makedirs("~/.t", exist_ok=True)`) and use explicit path references instead of dropping files directly into the default working directory (`.`) when it is the home directory.

The bug is triggered when a code section creates a file visible to `ls -R` (and when you do not delete it at the end of the conversation-turn).

When you see that a user uploaded a file named without a leading dot, and are denied code execution later, remind the user the reason for this — and that the workaround is to prepend dot `.` before uploading.  (But this session is most probably already tainted.)

Remark 1: BTW, first I thought that the trigger was the creation of the file download card (when a code section makes a file visible to ls -R). However, it turned out to be only a side effect: deletion of the file later in the same turn not triggers this bug.

Remark 2: This bug is orthogonal to removal of everything (except the uploaded files) from /tmp and ~ (recursively) at the end of each assistant’s turn.