Post-2026.1.0.52 sweep, Tier 1: Python 3.13, save-as-blueprint global inputs, blueprint category validation

.wordlist.txt

@@ -1656,3 +1656,4 @@ setFeatureCompatibilityVersion
 featureCompatibilityVersion
 Telnet
 sharded
+CPython

docs/admin/setting-up-cloudshell/cloudshell-configuration-options/customer-configuration-keys-repository/blueprint-workspace.md

@@ -274,6 +274,37 @@ sidebar_position: 6
 	</tbody>
 </table>
 
+## Keep global inputs when saving a sandbox as a blueprint
+When saving a sandbox as a blueprint, keep global inputs that were linked to a resource requirement, even when that resource is saved as a concrete resource. Set to `False` to drop them instead, restoring the behavior of earlier versions.
+<table>
+	<tbody>
+		<tr>
+			<td>Key</td>
+			<td>`<add key="KeepResourceGlobalInputsOnSaveAsBlueprint" value="True"/>`</td>
+		</tr>
+		<tr>
+			<td>Possible values</td>
+			<td>True/False</td>
+		</tr>
+		<tr>
+			<td>Where to add/change</td>
+			<td>`customer.config` CloudShell Server installation directory</td>
+		</tr>
+		<tr>
+			<td>Default value</td>
+			<td>True</td>
+		</tr>
+		<tr>
+			<td>Affected CloudShell Component</td>
+			<td>CloudShell Server</td>
+		</tr>
+		<tr>
+			<td>Version</td>
+			<td>2026.1 and above</td>
+		</tr>
+	</tbody>
+</table>
+
 ## Set the route grouping policy
 <table>
 	<tbody>

docs/devguide/develop-custom-cloud-provider-shells/getting-started-with-cp-dev.md

@@ -49,7 +49,7 @@ As of version 9.0, CloudShell supports the ability to define custom cloud provid
     CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following:
 
     - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv).
-    - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
+    - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.13.15 — the versions bundled with CloudShell 2026.1 on Windows; use 3.9.9 to match an earlier version or a Linux Execution Server — and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
     :::
 
 - **IDE/Text Editor**: Your preferred IDE editor. We recommend using PyCharm (which offers a free community edition) because of the tooling we’ve already created for that IDE, including a CloudShell developer plugin.

docs/devguide/develop-orch-scripts/getting-started-with-orch-scripts.md

@@ -18,7 +18,7 @@ Orchestration scripts can enable automating sandbox workflows. You can use orche
     CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following:
 
     - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv).
-    - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
+    - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.13.15 — the versions bundled with CloudShell 2026.1 on Windows; use 3.9.9 to match an earlier version or a Linux Execution Server — and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
     :::
 
 - **IDE/Text Editor:** Your preferred IDE editor. We recommend using PyCharm (which offers a free community edition) because of the tooling we’ve already created for that IDE, including a CloudShell developer plugin.

docs/devguide/developing-shells/getting-started.md

@@ -35,7 +35,7 @@ To learn more about the different versions of the Shells used by CloudShell and
     CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following:
 
     - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv).
-    - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
+    - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.13.15 — the versions bundled with CloudShell 2026.1 on Windows; use 3.9.9 to match an earlier version or a Linux Execution Server — and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
     :::
 
 - **IDE/Text Editor**: Your preferred IDE editor. We recommend using PyCharm (which offers a free community edition) because of the tooling we’ve already created for that IDE, including a CloudShell developer plugin.

docs/devguide/setting-up-dev-env.md

@@ -12,12 +12,22 @@ In this section we’ll go over the recommended steps for setting up a developme
 
 Download and install a current 64-bit version of Python 3 from the [official website](https://www.python.org/downloads/). Shellfoundry, CloudShell's shell development CLI, supports Python 3.9–3.13 (Python 3.13 requires shellfoundry 1.2.29 or later).
 
-Note that shells and scripts *execute* on the Python versions bundled with CloudShell itself — currently Python 3.9.9 (and Python 2.7.18 for legacy shells). Your driver code and its requirements.txt must stay compatible with the bundled version your CloudShell deployment runs, even if your dev machine uses a newer Python.
+Note that shells and scripts *execute* on the Python versions bundled with CloudShell itself, not on your dev machine's Python. As of CloudShell 2026.1 that is:
+
+| Execution Server | Bundled Python 3 | Bundled Python 2 |
+| --- | --- | --- |
+| Windows | 3.13.15 (64-bit) | 2.7.18 |
+| Linux virtual appliance / from script | 3.9.9 | 2.7.18 |
+| Docker Execution Server image | 3.9.9 | 2.7.18 |
+
+Your driver code and its `requirements.txt` must stay compatible with the bundled version your CloudShell deployment runs. If your shells run on both Windows and Linux Execution Servers, they must work on both Python 3.9 and 3.13 — mind the standard-library removals in between, such as the `collections` aliases for the abstract base classes (`collections.Sequence`), which were removed in 3.10 in favor of `collections.abc`.
+
+Earlier CloudShell versions bundle Python 3.9.9 on Windows as well; see [Behavior Changes](../release-notes/behavior-change.md).
 :::tip
 CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following:
 
 - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv).
-- [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
+- [Downloading separate installers](https://www.python.org/downloads/) for the bundled versions listed above and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done.
 :::
 ## Pick and install an IDE
 

docs/install-configure/cs-system-requirements/third-party-software.md

@@ -20,8 +20,8 @@ If any of the below 3rd Party components are missing from your computer, the Clo
 - Microsoft Visual C++ 14.0 or greater
 - Microsoft Windows Installer 4.5
 - Node.js 24.14.0 LTS (64-bit only)
-- pip 21.2.4 and up for Python 3.7 and pip 19.2.3 for Python 2.7.18
-- Python Python 2.7.18 and 3.9.9
+- pip 21.2.4 and up for Python 3 and pip 19.2.3 for Python 2.7.18
+- Python 2.7.18 and 3.13.15 (64-bit)
 - RabbitMQ 3.12.0 (installed as part of the Quali Server installation)
 - Erlang 26.2.3
 - VCTools++ (For all users. Required for compiling Python dependencies)
@@ -33,10 +33,13 @@ The following bundled prerequisites were updated:
 - **Node.js**: 22.15.0 → 24.14.0 LTS (used by Sandbox API Gateway and Server Proxy)
 - **Erlang OTP**: 25.2.3 → 26.2.3 (RabbitMQ prerequisite)
 - **MongoDB**: 6.0.4 → 7.0.30
+- **Python 3**: 3.9.9 (32-bit) → 3.13.15 (64-bit). The bundled Python 2.7.18 is unchanged. This applies to the Python bundled with CloudShell on Windows; Linux Execution Servers and the Docker Execution Server image still provide Python 3.9.9.
 
 The CloudShell installer handles these upgrades automatically. Standalone MongoDB deployments must be upgraded manually to 7.0 before upgrading CloudShell.
 
 **Breaking change**: Node.js 24 dropped 32-bit (x86) Windows support. The x86 Node.js prerequisite has been removed from the CloudShell installer. Only 64-bit Windows is supported.
+
+**Driver compatibility**: shells and scripts running on a Windows Execution Server now execute on Python 3.13. See [Behavior Changes](../../release-notes/behavior-change.md).
 :::
 
 ## Optional

docs/release-notes/behavior-change.md

@@ -17,6 +17,9 @@ The following list includes changes in behavior introduced into CloudShell by ve
 | Editing an active maintenance window | When editing an **active** maintenance window, an end time that is not in the future (at or before the current time) is now rejected — including the former within-grace "ends immediately" behavior. To end an active maintenance window immediately, use the **Stop** action. | 2026.1 |
 | Custom PyPI repository applied at setup | The `RequirementsRepository`, `RequirementsTrustedHost`, and `RequirementsExtraRepository` keys are now honored during Execution Server setup and default-environment bootstrap, not only at driver-command time. Deployments that set a custom PyPI index will use it earlier; there is no change when no custom repository is configured. | 2026.1 |
 | Portal session survives app-pool recycle | The Portal now rebuilds a user's session from the sign-in cookie after an application-pool recycle instead of forcing a re-login, and a transient CloudShell Server `MessageSecurityException` no longer signs users out. Controlled by the `EnableSessionRehydration` app setting (default `true`); set it to `false` to restore the previous force-logout behavior. | 2026.1 |
+| Bundled Python 3 version (Windows) | The Python 3 interpreter bundled with CloudShell on Windows was upgraded from CPython 3.9.9 (32-bit) to 3.13.15 (64-bit). Drivers and scripts running on a Windows Execution Server now execute on Python 3.13, so driver code and `requirements.txt` must be valid on 3.13 — the most common breakage is the `collections` ABC aliases (for example `collections.Sequence`), removed in Python 3.10 in favor of `collections.abc`. Python 2.7.18 is unchanged. Linux Execution Servers, the Linux virtual appliance and the Docker Execution Server image still provide Python 3.9.9, so shells running on both platforms must stay compatible with 3.9 and 3.13. | 2026.1 |
+| Global inputs kept on save as blueprint | Saving a sandbox as a blueprint now keeps global inputs that were linked to a resource requirement, where previously they were dropped. Where the requirement is carried over to the saved blueprint the input is linked back to it; where the resource was pinned down the input is kept as a plain value linked to nothing. These inputs are visible in the Reserve dialog and in the blueprint editor. Set `KeepResourceGlobalInputsOnSaveAsBlueprint=false` in `customer.config` to drop them instead and restore the previous behavior. | 2026.1 |
+| Blueprint import fails on a missing category | Importing a blueprint that references a category that does not exist in the target domain now fails the import with an explicit error. Previously the blueprint imported successfully and the category association was silently dropped. Create the missing categories in the target domain before importing, or remove the category references from the blueprint. | 2026.1 |
 | Erlang version | To accommodate the upgraded RabbitMQ version (3.12.0) explained in [Breaking Changes](#breaking-changes), Erlang will be upgraded to newer version 25.2.3. This version is the maximum supported Erlang for RabbitMQ 3.12.0. Environment variables will be updated accordingly to suite the new Erlang version. | 2023.2 EA |
 | Python versions | In 2022.1, we updated CloudShell's Python versions as follows: <ul><li>2.7.10 to 2.7.18</li><li>3.7.1 to 3.9.9</li></ul> This may cause unexpected behavior if your automation is constrained to use specific Python versions.  | 2022.1 EA |
 | API tokens | To increase security and to allow time-based token access to the system, CloudShell 2022.1 generates a time-based token for our product APIs. In previous versions, only some of the APIs used such a system. By default, the token validity period is 5 hours. Notes: <ul><li>For security reasons, we recommend upgrading to the latest version of CloudShell.</li><li> Existing automation code utilizing Quali API may need to be updated to regenerate a token whenever an existing token expires.</li></ul> | 2022.1 EA |

docs/release-notes/whats-new.md

@@ -60,6 +60,28 @@ New TestShell API method that returns the list of reservations (current and hist
 ### Improved Abstract Resource Resolution Diagnostics
 When a blueprint reservation fails due to unresolvable abstract resources or route conflicts, the error message now includes detailed diagnostics — showing which resources could not be resolved, which routes failed, and the specific conflicts that prevented resolution.
 
+### Bundled Python 3 Upgraded to 3.13 (Windows)
+The Python 3 interpreter bundled with CloudShell on Windows has been upgraded from CPython 3.9.9 (32-bit) to **3.13.15 (64-bit)**. Shell drivers and orchestration scripts that run on a Windows Execution Server now execute on Python 3.13. The bundled Python 2.7.18 slot is unchanged and still ships, so legacy Python 2 shells are unaffected.
+
+:::warning Driver compatibility
+Driver code and its `requirements.txt` must be valid on Python 3.13. Modules and aliases removed between 3.9 and 3.13 are the most common cause of breakage — for example the `collections` aliases for the abstract base classes (`collections.Sequence`), which were removed in Python 3.10 and must be imported from `collections.abc` instead. Test your shells against Python 3.13 before upgrading.
+:::
+
+:::note Linux and Docker Execution Servers still use Python 3.9.9
+This upgrade covers the Python bundled with CloudShell on Windows. Linux Execution Servers — including the Linux virtual appliance and the Docker Execution Server image — still provide Python 3.9.9. If your shells run on both Windows and Linux Execution Servers, keep driver code compatible with both 3.9 and 3.13.
+:::
+
+### Global Inputs Kept When Saving a Sandbox as a Blueprint
+Saving a sandbox as a blueprint now keeps global inputs that were linked to a resource requirement, instead of dropping them:
+
+- Where the requirement is carried over to the saved blueprint (the work order flow), the kept global input is linked back to that requirement, so it still drives something.
+- Where the resource was pinned down as a concrete resource, there is nothing left to link to, so the input is kept as a plain value.
+
+Controlled by the `KeepResourceGlobalInputsOnSaveAsBlueprint` key (default `true`). Set it to `false` to drop these inputs instead, which restores the previous behavior.
+
+### Blueprint Import Validates Categories
+Importing a blueprint that references a category that does not exist in the target domain now fails the import with an explicit error, instead of importing the blueprint and silently dropping the category association. This completes the import validation set — family, model, attribute, script, driver and resource references already failed the import when missing.
+
 ### Bug Fixes
 - Fixed an issue where App deployment could retry unnecessarily on certain internal errors instead of failing fast with clear diagnostics.
 - Fixed SSO (SAML) users being bounced to the login page in a loop, instead of seeing the maintenance page, when signing in during a maintenance window. Aborted logins no longer leave a half-authenticated session.