Google published an Agent Platform Workbench v2 fix on October 11, 2026 for a failure that prevented gcloud and gsutil from loading. The release notes attribute an AttributeError in OpenSSL.crypto to incompatible versions of pyOpenSSL and cryptography. Users encountering that exact error now have a documented environment-level fix as a starting point, rather than having to diagnose everything from scratch.
The fix appears in release 20261011-2230-rc0, alongside updated upstream dependency packages. It appears again in the October 12 notes under 20261011.00_p0. These are two entries for the same fix, not two separate incidents. They do not imply that every cloud-access problem or OpenSSL error has the same cause or was resolved by this update.
Why a package problem can stop cloud work
gcloud manages Google Cloud resources from the command line and scripts, while gsutil works with Cloud Storage. When a tool cannot load, its intended operation may stop before execution. A small library maintenance change can therefore matter to teams running data workflows or recurring tasks from their development environment.
The announcement concerns package compatibility, not damage to an AI model or changes in answer quality. It does not classify the issue as a security incident. Keep the full error and environment details and compare them with Google’s description: the name OpenSSL alone does not identify the fault or the required remedy.
Before updating, check the environment version on the Google Cloud console’s instances page. Documentation says not every release updates every environment; eligibility depends on the underlying VM image. A release-note entry therefore does not prove the fix is installed on a particular instance or reaches every user through the same path at the same time.
Preparing without disrupting the environment
Google recommends backing up data before upgrading and states that backward compatibility is not guaranteed. The process replaces the boot-disk image while preserving data on the data disk, but user-installed libraries may require reinstallation. Prepare a dependency list rather than relying only on preserved notebooks that can still be opened afterward.
For container-based environments, the image version also depends on what the Dockerfile pulls. Updating the instance does not necessarily update every custom package. Plan a suitable maintenance window, check the supported upgrade path and first try the failing operations in a testable environment. There is no need to change several libraries randomly because their names appear in an error.
Afterward, a useful check is to confirm the tools load, then run a familiar, nondestructive operation that depends on them. If the failure persists, version and error details will support further diagnosis. The benefit is specific: restoring tool loading in the documented scenario so development can continue, without treating one compatibility fix as a solution to every Google Cloud problem.