Repository navigation
Setting up Python 3.14t on windows-11-arm runner doesn't work since January 12 #1267
Description
Activity
- changed the title
[-]Setting up Python 3.14 on Windows ARM Runner doesn't work since January 12[/-][+]Setting up Python 3.14t on Windows ARM Runner doesn't work since January 12[/+]on Jan 17, 2026 - changed the title
[-]Setting up Python 3.14t on Windows ARM Runner doesn't work since January 12[/-][+]Setting up Python 3.14t from a matrix on Windows ARM Runner doesn't work since January 12[/+]on Jan 17, 2026 Python 3.13t also fails with similar issue[xref] on Windows-11-arm runner.
- changed the title
[-]Setting up Python 3.14t from a matrix on Windows ARM Runner doesn't work since January 12[/-][+]Setting up Python 3.14t using a python-version matrix on windows-11-arm runner doesn't work since January 12[/+]on Jan 18, 2026 - changed the title
[-]Setting up Python 3.14t using a python-version matrix on windows-11-arm runner doesn't work since January 12[/-][+]Setting up Python 3.14t on windows-11-arm runner doesn't work since January 12[/+]on Jan 18, 2026 It doesn't work at al: neither matrix, single version of Python 3.14t nor Python 3.14 with
freethreaded: trueworksHello @w8sl 👋,
Thank you for your report. We'll investigate the issue and get back to you with the details!Reacted by SylvesterThis regression has also been reported to the ARM issue tracker: actions/runner-images#14058
Python 3.14.2 is already preinstalled, but deleting it doesn't help. It looks like the installer from org doesn't work on Windows ARM runner. Python 3.14t from nuget.org used by CIBW works correctly: https://api.nuget.org/v3-flatcontainer/pythonarm64-freethreaded/3.14.2/pythonarm64-freethreaded.3.14.2.nupkg
Reacted by Gleb KhmyznikovHello Everyone👋,
Thank you for your patience as we investigated this issue. Based on our findings, thewindows-11-armrunners currently have cached Python patch versions 3.12.10, 3.13.11, and 3.14.2, with 3.14.2 introduced in the updated VM image after January 12 (moving from image version 20251217.39.1 to 20260105.41.1, as seen in the workflow runs shared in the description). The screenshot below shows the preinstalled Python versions on the runner before thesetup-pythonstep:
Only these specific cached versions (3.12.10, 3.13.11, 3.14.2) are currently setting up successfully. Attempting to set up other patch or variant builds for Python 3.12, 3.13, and 3.14 results in failures, while other major and minor versions, such as Python 3.11.x or 3.15.x, are working as expected as seen in the additional screenshot below:
The root cause appears to be a runner image-level regression that was introduced when Python 3.14.2 (GIL) became preinstalled on Windows-11-arm, rather than a problem with the
setup-pythonaction itself or the Python binaries.As noted by @w8sl, even manually removing the preinstalled Python does not fully resolve the problem, likely due to residual registry entries or interpreter registration within the Windows environment.
Additionally, we’ve observed that installing Python via NuGet succeeds because it places Python in a separate, user-specific directory, rather than thehostedtoolcachepath. This approach avoids conflicts with the system’s global Python installation and environment settings.We hope this clarifies the current situation. Thank you!
Reacted by Daniele Parmeggiani and MUGUNDANHi @priya-kinthali,
Please let us know if there are any updates on this issue.It works again with Python 3.14.3 !
Reacted by MUGUNDANReacted by Clément RobertClosing this issue as the affected workflow is functioning again with Python 3.14.3
Hello @w8sl👋,
Thanks for the confirmation! As mentioned in my previous comment, the failure of other patch versions was due to a regression at the runner image level. Any patched versions(ex: 3.13.12, 3.14.3) above the cached versions (ex: 3.13.11, 3.14.2) will always pass. In case of any further issues or concerns, please consider reporting or tracking in the actions/partner-runner-images repository.
Thanks again for your feedback!Reacted by MUGUNDAN and Sylvester@priya-kinthali, could you please clarify what the issue was, how it was resolved, and whether we’re confident it won’t occur again?
Hello everyone👋, Thank you all for your patience!
Based on our further investigation, we found this was due to an ARM64-specific registry cleanup edge case, where stale/cached registrations could conflict and block new Python installations onwindows-11-armrunners.
We’ve addressed this in actions/python-versions#387, and updated artifacts have now been released:This should now be resolved. Please re-run your workflows and let us know if you still run into any issues.
Reacted by Gleb Khmyznikov and Ralf GommersHello everyone👋, Thank you all for your patience! Based on our further investigation, we found this was due to an ARM64-specific registry cleanup edge case, where stale/cached registrations could conflict and block new Python installations on
windows-11-armrunners. We’ve addressed this in actions/python-versions#387, and updated artifacts have now been released:This should now be resolved. Please re-run your workflows and let us know if you still run into any issues.
FYI @alex and @khmyznikov
Reacted by Gleb KhmyznikovReacted by Sylvester
Description:
I'm not sure if this issue is a duplicate as everything was working until January 12th. The downloaded Python 3.14.2 image is
exactly the same, including the SHA-256 checksum. CIBW update is coincidental. Affected steps are not using CIBW
Successful run: Jan 12 at 7:48 PM GMT+1
https://github.com/rasterio/rasterio/actions/runs/20931105785/job/60151291265#step:3:1
Broken since Jan 12 at 11:07 PM GMT+1
https://github.com/rasterio/rasterio/actions/runs/20936661761/job/60168515989#step:3:1
Action version:
actions/setup-python@v6
Platform:
Runner type:
Tools version:
Python 3.14t
Repro steps:
Expected behavior:
Working as before. Appreciate any hint about what may be broken.
Actual behavior:
Issue persists as of Jan 17