macOS 27 tauchte am selben Tag in zwei Release Notes auf, und keines kann es allein lösen
Serguey Asael Shinder2 Min. LesezeitAm 9. Oktober veröffentlichten zwei voneinander unabhängige Projekte Release Notes, in denen dasselbe Betriebssystem vorkam. In keinem Fall ging es um einen Fehler im eigenen Code.
Python 3.15.0. Die Release-Seite warnt, dass unter macOS 27.0 Tk-Programme — IDLE und alles mit tkinter — hängen können, wenn ein Menübefehl einen Dialog öffnet; am Ende hilft nur Sofort beenden. Das Python-Team führt das auf eine Verhaltensänderung des Betriebssystems zurück, die vermutlich alle aktuellen Tk-Versionen betrifft und damit tkinter in jedem aktuellen Python, nicht nur im neuen. Empfehlung: mit macOS 27.0 warten oder den eigenen Ablauf vorher testen.
CodeQL 2.27.2. Laut GitHub-Changelog liefert Apple mit macOS 27 und Xcode 27 keine Multi-Architektur-Binärdateien für x86-64/arm64 mehr, auf die die Traced-Analyse von CodeQL angewiesen ist. Autobuild und manueller Build-Modus für kompilierte Sprachen sind deshalb auf macOS 27 mit jedem Xcode nicht unterstützt, ebenso auf macOS 26 mit gewähltem Xcode 27. Empfehlung: bei macOS 26 mit Xcode 26 bleiben.
Was beide verbindet. In beiden Fällen liegt die Lösung nicht im Code des Projekts. Python kann das Zusammenspiel von Tk mit dem Fenstersystem nicht aus dem Interpreter heraus reparieren, CodeQL kann Apples Universal Binaries nicht selbst ausliefern. Beide Projekte taten das Einzige, was ihnen blieb: Sie schrieben die Einschränkung in die Release Notes und nannten die sichere Version. Damit wandert die Arbeit zu dem, der die Betriebssystemversion kontrolliert — dem Entwickler, der entscheidet, wann er auf Aktualisieren klickt, oder der CI-Konfiguration, die festlegt, worauf ein Runner-Label zeigt.
Wo es unbemerkt zuschlägt. Wer seinen Laptop aktualisiert, sieht ein hängendes IDLE und bringt es mit dem Update in Verbindung. In einer CI-Pipeline ist das anders. Ein Workflow mit einem gleitenden Label wie macos-latest wechselt das Betriebssystem, sobald der Anbieter das Label verschiebt — ohne einen Commit im Repository. Läuft dort CodeQL mit Autobuild für ein Swift- oder C++-Projekt, ist das erste Anzeichen womöglich eine fehlgeschlagene oder leere Analyse an einem Tag, an dem niemand etwas geändert hat.
Die praktische Regel aus beiden Notes ist dieselbe: festpinnen. Für macOS-Runner mit Traced-Builds von CodeQL ausdrücklich macOS 26 anfordern und Xcode 26 gewählt lassen, bis GitHubs Arbeit an build-mode: none für macOS fertig ist. Für Rechner, die auf Tk-Werkzeuge angewiesen sind, macOS 27.0 als zu testende Änderung behandeln, nicht als Routine-Update, und CPython-Issue #158053 verfolgen. Und wenn der Pin irgendwann fällt, dann bewusst und mit einer Notiz, welche Änderung upstream ihn überflüssig gemacht hat — sonst überlebt der Pin seinen Grund und wird zur nächsten unerklärten Einschränkung.
Die allgemeine Lehre ist älter als beide Releases: Ändert sich eine Abhängigkeit außerhalb des eigenen Repositorys, können Release Notes das Problem beschreiben — eindämmen kann es nur eine Version, die man selbst kontrolliert.
Quellen: Release-Seite zu Python 3.15.0 — https://www.python.org/downloads/release/python-3150/ ; GitHub Changelog, CodeQL 2.27.2, 9. Oktober 2026 — https://github.blog/changelog/2026-10-09-codeql-2-27-2-improves-c-go-rust-and-javascript-analysis