Katastrophales Systemdesign in Mac OS 26.x

Unter Mac OS 26.x wird bei Anfragen zur "Local Network" - Berechtigung für Electron-basierte Anwendungen (z.B. Visual Studio Code) nicht die eigentliche App angezeigt, sondern ein generischer Prozess wie "Electron Helper" oder "Code Helper". Diese Prozesse sind für den Nutzer nicht selbstredend identifizierbar und wirken daher wie unbekannte Apps oder potenzielle Malware.

Wenn der Benutzer in dem Dialog dann sicherheitsbewusst zunächst "Nicht zustimmen" klickt, verliert die eigentliche App dauerhaft den Zugriff aufs lokale Netzwerk. Das hat u.a. zur Folge, dass VS Code Remote-SSH im LAN nicht mehr funktioniert. Die Ablehnung ist anschließend nicht zuverlässig über die Systemeinstellungen rücksetzbar.

Probleme:

- Angezeigt wird ein kryptischer Prozessname statt der zugehörigen App.
- Es gibt keinen erkennbaren Hinweis, welcher App die Entscheidung gilt.
- Eine Ablehnung ist praktisch irreversibel.
- TCC-Resets beheben das Problem nicht zuverlässig
- VS Code funktioniert nicht mehr für Remote-Entwicklungen
- Fehlertexte sind irreführend

Ich kenne Mac OS X noch von der Zeit als man noch von NeXTStep-/OpenStep sprach und war immer begeistert davon, wie perfekt alles bis ins kleinste Detail konzipiert und implementiert war. Ich war immer begeistert, dass diese hervorragende Software heute Apple-Produkte antreibt.

Das hat sich inzwischen deutlich geändert und man findet in Mac OS X Software-Anteile, bei denen die Note - wenn man es in Schulnoten bewerten würde - "mangelhaft" noch geschmeichelt wäre. Und das ist nur ein Beispiel.

Ich habe als professioneller Nutzer dafür überhaupt kein Verständnis und kann immer häufiger nur noch mit dem Kopf schütteln.

Mac mini (M4 Pro, 2024)

Gepostet am 07. Dez. 2025 01:58

Antworten

Höchstrangige Antwort

Ghostbuster Autor

Stufe 1

12 Punkte

Gepostet am 08. Dez. 2025 01:54

Es ist vollkommen in Ordnung, dass Du einen anderen Standpunkt vertrittst, halte ihn aber für undifferenziert und realitätsfremd. Ist es wirklich korrekt, dass ein "Experte" oder "Professioneller" diesem Bug nicht auf den Leim hätte gehen dürfen???

Experten sind nicht Experten für alles und ein "Professioneller" ist auf seinen Job fokussiert und möchte aus Kostengründen seine Zeit nicht mit Rand-Problemen vergeuden, bevor er seine Arbeit machen kann.

Natürlich habe ich (zwangsläufig) mich mit diesem Problem inzwischen genauer beschäftigt und es analysiert.

Ergebnis:

Der merkwürdige macOS - Dialog geht darauf zurück, dass VSC eine Electron-Anwendung ist. Ich nutze VSC als Anwender und nicht als Jemand, der die VSC-App oder Plugins dafür programmiert. Daher kenne und nutze ich das Electron-Framework auch nicht. Es gehört m.E. nicht zum Allgemeinwissen eines jeden IT-Experten. Außerdem ist das wegen (2) auch unbedeutsam.
Die Erkenntnis (1) legt die Einschätzung nahe, dass das Problem mit dem irritierenden Dialog bei VSC und nicht bei macOS liegt. Das ist m.E. falsch. macOS zeigt bei Local-Network-Permission-Problemen leider den Prozessnamen an. Genau hier liegt der Designfehler, weil dadurch Implementierungsdetails einer App an den Nutzer weitergereicht werden. Richtig wäre es, wenn macOS die Parent-App anzeigen würde. Technisch ist das möglich. Man könnte dies auch einen UI/UX-Bug in Apple's TCC-System nennen bgzl. Transparenz, Kontrolle und Zustimmung.
Die getroffene falsche Entscheidung ist nicht wirklich irreversibel. Es wirkt nur so. Man kann das über einen "Workaround" doch zurücksetzen und zwar sehr einfach über Systemeinstellungen->Datenschutz & Sicherheit -> Lokales Netzwerk. Hier muss man für VSC den sichtbaren Schalter nur aus- und anschließend wieder einschalten. Aber auch hier ist Kritik berechtigt, denn die Notwendigkeit für einen Workaround zeigt, dass diese Mechanismen "nicht korrekt funktionierend" in macOS implementiert wurden. Das Ablehnen hätte dazu führen müssen, dass der Schalter für VSC auf "off" steht (möglicherweise passiert das deshalb nicht, weil man den Prozess der den Zugriff auslöst anstatt die Parent-App betrachtet??). Und man kann nicht selbstredend erwarten, dass Jeder - inklusive Experten - solche Workaround kennen. Ich persönlich möchte meine wertvolle Zeit nicht mit irgendwelchen Workarounds vergeuden, die eigentlich gar nicht erforderlich sein sollten.

Fazit: Es gibt an macOS durchaus etwas auszusetzen. Und was ich hier beschrieben habe, ist nicht der einzige Design-Fehler.

Antwort im Kontext anzeigen

16 Antworten

07. Dez. 2025 06:58 als Antwort auf Dutchman

Danke für das Feedback. Mac OS X 26.1 läuft stabil auch mit VSC und auch der Remote-SSH-Zugriff funktioniert ohne irgendwelche Probleme, wenn da nicht ....

Das Problem ist: Apple baut ständig weitere sogenannte "Sicherheitsfeatures" in das System ein, die das System ironischer Weise tendenziell unsicherer anstatt sicherer machen, weil sie schlicht grottenschlecht implementiert sind. Es wird beim Design derartiger Feature schlicht nicht konsequent zu Ende gedacht.

Bzgl. VSC ist es so, dass ein offenbar neues Feature den Nutzer "irgendwann" fragt, ob es in Ordnung ist, dass eine für den Nutzer unbekannte App namens Electron "Netzwerk-Kommunikation durchführen darf". Da "Electron" für den Nutzer nicht transparent / leicht identifizierbar ist, wirkt es wie eine unbekannte App oder potenzielle Malware. Der sicherheitsbewusste Nutzer lehnt daher erst mal ab. Das aber hat zur Folge, dass VSC Remote SSH-Zugriff nicht mehr funktioniert und unverständliche Fehlermeldungen kommen. Hat man nach einem Moment verstanden, dass das durch die vorherige Ablehnung ausgelöst wurde, kommt katastrophal hinzu, dass diese Entscheidung irreversibel und nicht über die Systemeinstellungen rücksetzbar ist. What??? Da kann man nur noch mit dem Kopf schütteln.

Antworten

Katastrophales Systemdesign in Mac OS 26.x