Regression in 20260105.41.1: actions/setup-python with 3.14t fails

[alex]

Type of issue

• Error when running a workflow.
• Request for additional tools or software for an existing image.
• Request for a new image, Linux or Windows.
• Other

Describe the issue

When run on the new image, actions/setup-python with:

  with:
    python-version: 3.14t
    architecture: arm64

Has started failing.

The exact output can be seen at https://github.com/pyca/cryptography/actions/runs/20991939976/job/60346101997

This fails consistently on the 2026 image, but works on the previous 2025 image.

To Reproduce

Run the above listed action on Windows 11 Arm runner.

Expected behavior

It works.

Desktop (please complete the following information):

• OS: Windows 11 Arm

[pbk8s]

@alex This does not appear to be an image regression. The latest image has Python 3.14.2 (regular / GIL build) installed and working, which is why tests pass when using python-version: 3.14.
The failure occurs because the workflow is requesting python-version: 3.14t, which refers to the free-threaded (no-GIL) build. That version is not preinstalled on the image. When actions/setup-python sees 3.14t, it attempts to download and install the free-threaded ARM64 build at runtime, and that installation currently fails on Windows Arm, leaving behind an incomplete Python layout (missing stdlib, encodings, etc.).
This can be confusing because the same workflow succeeds on x86 Windows runners, where the free-threaded install path currently works. On Windows Arm, however, this is an upstream setup-python limitation, not a change in the image.

Can you share the previous successful build for this? (for the 2025 image)

[alex]

I'm not sure what you mean by it's not an image regression -- it was working fine previously and now it's not :-)

https://github.com/pyca/cryptography/actions/workflows/wheel-builder.yml -- every build between August and January 12th was building ok :-)

[pbk8s]

Thanks for sharing the earlier successful runs.

One key difference in the latest image is that it now has Python 3.14 (regular/GIL build) pre-installed, which wasn’t the case in the previous image. When the workflow requests 3.14t (free-threaded), actions/setup-python attempts to install it dynamically, and there appear to be issues when 3.14 and 3.14t coexist on Windows Arm64.

I’m seeing similar failures reported upstream in the community - actions/setup-python#1241

I'll investigate it further and keep you posted on the solution.

[alex]

Ah interesting, so possibly this just exposed an existing issue in setup-python?

We do both 3.14 and 3.14t on the x86-64 runners, so that's somehow made to work.

[pbk8s]

Yes, it appears that this issue pertains only to the Windows Arm64 runners. Is it possible for you to try the workflow on 3.13t instead of 3.14t?

[alex]

It also looks fubar: pyca/cryptography#14151

[alex]

Is there any additional debugging info we can provide here? This reproduces pretty readily, and without a remedy the consequence is unfortunately likely to be that we drop support for Windows on arm64.

[pbk8s]

@alex We're working on getting a resolution or at the very least a workaround to unblock your workflow. It seems like a race/file lock condition with a combination of setup-python@v6 action and python 3.14t (when 3.14 is pre-installed on the image). Will provide an update asap.

[alex]

Thanks, much appreciated.