gcloud 592.0.0 Removed System Python From Its Debian Docker Images, and CLOUDSDK_PYTHON=python3 Now Breaks Them

The Google Cloud CLI 592.0.0 release notes, dated November 3, 2026, list this under breaking changes for Docker: the system Python and C compiler were removed from the Debian-based images. The tools now run on the bundled Python, and setting CLOUDSDK_PYTHON=python3 in these images makes them fail.

The CLI itself keeps working. What breaks is everything that treated the image as a convenient place to run something else.

What was removed, by tag#

According to the release notes, the removals differ per tag:

The notes also say gcloud, gsutil and bq now always run on the bundled Python, on both linux/amd64 and linux/arm64. I read the release notes and not the image Dockerfiles, so this table is only as precise as that page.

Two separate failure modes#

The first is the environment variable. The notes say CLOUDSDK_PYTHON=python3, and the gsutil and bq equivalents CLOUDSDK_GSUTIL_PYTHON and CLOUDSDK_BQ_PYTHON, break these images, and the fix is to unset them. The reason is mechanical: the variable tells the launcher which interpreter to use, and python3 was a path that used to resolve to something. Now it does not. Teams usually set this in a CI template to pin gsutil to a known interpreter, then forget it exists. A job that passed on 591.0.0 fails on 592.0.0 with an error about the interpreter, not about anything the job does.

The second is quieter. Any step that ran pip install, python3 script.py or compiled a C extension inside a gcloud image was using the image’s toolchain by accident. Nothing in the gcloud docs I read promised that toolchain. The release notes now say, for people who need system Python or C extension builds, to install them on top of the image. In practice that is an apt-get install layer, which costs build time and adds a network dependency on Debian mirrors to a job that did not have one.

Who is exposed#

Exposure follows the tag you pull, not the version you think you run.

• Anything on :latest, :slim or :debian_component_based that was not pinned to a version tag picked this up on the next pull after 592.0.0 was published. I did not check Artifact Registry to see when each tag moved, so I cannot say how long that took.
• Pinned versions like 591.0.0 are unaffected until someone bumps them. That makes the bump the moment to find out.
• :emulators users lose python3 and python3-crcmod. The same release also makes the Datastore and Firestore emulators require Java 25 or later, per the notes, so that bump carries two breaking changes.

I did not verify the arm64-only :stable removal on a real image. If you build for Apple Silicon runners or Graviton, that is the one to test on an arm64 host rather than trust the table.

An audit that fits in a few lines#

You do not need to wait for a red build. Search your pipeline definitions and Dockerfiles for the places that assumed the base image:

grep -rnE 'CLOUDSDK(_GSUTIL|_BQ)?_PYTHON' .
grep -rnE 'FROM .*(cloud-sdk|google-cloud-cli)' .

The first finds the variables the notes say to unset. The second finds every image reference, which you then read for pip, python3 and gcc in the steps that follow. These patterns are mine, not Google’s, and they will miss images referenced through build args or a registry mirror.

For a step that needs Python, the cleaner fix is to stop sharing one image: run the Python work in a Python image and the gcloud work in the gcloud image, passing artifacts between steps. If you keep one image, install what you need in a derived Dockerfile so the dependency is written down. Either way, the decision the release forces is whether the gcloud image is a tool or a base, and it is now only the first.

What I could not confirm#

I did not run the 592.0.0 image, so the exact error text from CLOUDSDK_PYTHON=python3 is not in this post. The release notes name the packages but not the Debian release or image size change. I also did not read the 1.7 MB release notes page in full, only the 592.0.0 and 591.0.0 sections near the top.

Sources#

• Google Cloud CLI release notes, 592.0.0 (2026-11-03). Source for the Docker breaking change, the per-tag package list and the emulator Java requirement. This is the vendor’s own statement.
• Google Cloud SDK Docker images. Confirms the images are pulled from Artifact Registry and points to the cloud-sdk-docker repository for image details. I did not read that repository.