Xcode 26.6 Swift Package Manager: Auflösung fehlgeschlagen – Leitfaden 2026

Der Fehler tritt direkt bei „Resolving Package Graph“ auf, obwohl das Projekt zuvor gebaut wurde.

Schnellste Lösung: Löschen Sie nicht zuerst den gesamten Cache. Fixieren Sie zunächst Xcode, Package.resolved und den verwendeten Auflösungsbefehl. Prüfen Sie danach Versionsgraph, Git-Zugriff und Cache getrennt. Nur wenn derselbe Commit keine stabile Basis ergibt, sollten Sie die Build-Umgebung neu aufsetzen.

Dieser Leitfaden ist für Sie gedacht, wenn Sie nach dem Upgrade auf Xcode 26.6 eine fehlgeschlagene Package-Auflösung, ein fehlendes Package Product oder unerwartete Abhängigkeitversionen sehen. Er richtet sich außerdem an Entwickler mit privaten Swift Packages und an kleine Teams, die über xcodebuild auf einem Remote Mac bauen. Wenn Ihr Problem erst beim Kompilieren oder beim Archive-Schritt entsteht, müssen Sie zunächst feststellen, ob die Auflösung überhaupt erfolgreich war.

Die stabile Xcode-Version und die Beta-Grenze sollten Sie für jede Diagnose dokumentieren. Apple führt Xcode 26.6 als veröffentlichte Version; Xcode 27 ist laut Veröffentlichungsübersicht noch als Vorabversion einzuordnen. Prüfen Sie diese Grenze am offiziellen Apple-Releases-Eintrag vom 25.06.2026, bevor Sie eine CI-Umgebung als fehlerhaft bewerten.

1. Eine belastbare Fehlerbasis aus dem Auflösungsergebnis erstellen

„Der Build schlägt fehl“ ist keine ausreichende Diagnose. Eine Swift-Paketauflösung, ein Quellcode-Checkout, die Zuordnung eines Package Products, die Kompilierung und ein Archive sind unterschiedliche Zustände. Wenn Sie diese Zustände vermischen, löschen Sie möglicherweise den falschen Cache oder ändern eine funktionierende Version.

Beginnen Sie mit einer anonymisierten Fehlerbasis. Erfassen Sie:

• die tatsächlich gestartete Xcode-Version;
• den aktiven Developer-Pfad;
• Projekt oder Workspace;
• Scheme und Konfiguration;
• verwendeten Auflösungsbefehl;
• den ersten aussagekräftigen Fehler;
• Commit oder Tag des Quellrepositorys;
• den Zustand von Package.resolved.

Für die Version und den aktiven Developer-Pfad können Sie lokal beispielsweise Folgendes ausführen:

xcodebuild -version
xcode-select -p
xcrun --find xcodebuild

Verwenden Sie in Dokumentation und Support-Tickets keine echten Pfade, Kontonamen oder Repository-Adressen. Ersetzen Sie sie durch Platzhalter wie <PROJEKT>, <WORKSPACE>, <SCHEME>, <REPOSITORY> und <ACCOUNT>. Tokens, SSH-Schlüssel, Hostnamen und private Paketpfade gehören niemals in ein Log.

Führen Sie anschließend zwei getrennte Tests durch. Öffnen Sie den Workspace in Xcode und starten Sie dort die Paketauflösung. Danach wiederholen Sie den Vorgang über die Kommandozeile:

xcodebuild \
  -workspace "<WORKSPACE>.xcworkspace" \
  -scheme "<SCHEME>" \
  -resolvePackageDependencies \
  -clonedSourcePackagesDirPath "<PFAD_ZU_DEN_ABHAENGIGKEITEN>"

Bei einem Projekt ersetzen Sie -workspace durch -project und den entsprechenden Dateinamen. Die verfügbaren Auflösungs- und CI-Einstiegspunkte beschreibt Apple in der Dokumentation zu Swift Packages in Continuous-Integration-Workflows.

Der Vergleich ist diagnostisch wertvoll:

• Xcode funktioniert, xcodebuild scheitert: Prüfen Sie Shell-Umgebung, Benutzer, Developer-Pfad und SSH-Agent.
• Beide Wege scheitern gleich: Prüfen Sie zuerst Versionen, Paketregeln und Repository-Zugriff.
• Die Auflösung funktioniert, aber das Produkt fehlt: Prüfen Sie Package-Namen, Product-Namen, Target-Verknüpfungen und Scheme.
• Die Auflösung funktioniert, Archive scheitert: Suchen Sie bei Signierung, Provisioning, Build-Konfiguration oder Binary Dependencies weiter.

Bewahren Sie vor jeder Änderung das bereinigte Log auf. Eine Diagnose wird erst vergleichbar, wenn Sie die Fehlermeldung vor und nach einer Maßnahme gegenüberstellen.

2. Package.resolved gegen die deklarierte Versionierung prüfen

Package.resolved ist kein beliebiges Cache-Artefakt. Für ein Anwendungstarget beschreibt die Datei, welche Paketversionen und Revisionen in einem konkreten Projektzustand verwendet werden. Die Regeln, nach denen Swift Package Manager Versionen auswählt, sind in der offiziellen Beschreibung der Paketauflösung dokumentiert.

Prüfen Sie deshalb drei Ebenen:

1. Package.swift des Hauptprojekts;
2. Paketabhängigkeiten und Versionsbereiche im Projekt oder Workspace;
3. den Inhalt von Package.resolved.

Achten Sie auf unterschiedliche Paketquellen, inkompatible Mindestversionen, eine festgehaltene Revision außerhalb des erlaubten Bereichs und Änderungen an lokalen Paketpfaden. Ein häufiger Auslöser ist ein Branch-Wechsel: Die Arbeitskopie enthält danach eine Package.resolved, die zum vorherigen Projektzustand gehört. Ein Merge-Konflikt kann außerdem formal gültiges JSON hinterlassen, das aber nicht mehr zum aktuellen Abhängigkeitsgraphen passt.

Soll Package.resolved in Git eingecheckt werden?
Bei einer Anwendung oder einem ausführbaren Produkt ist das in der Regel sinnvoll, wenn reproduzierbare Entwickler- und CI-Builds erforderlich sind. Die Datei macht die gewählten Revisionen überprüfbar und verhindert, dass jeder Build ungeplant einen neuen Versionsgraphen auswählt. Prüfen Sie die konkrete Projektstruktur trotzdem im Review. Bei einer wiederverwendbaren Bibliothek ist die Grenze anders: Dort sollten Sie nicht automatisch die Auflösungsentscheidung jedes Verbrauchers vorgeben. Entscheidend ist, wer den finalen Build kontrolliert.

Behandeln Sie Änderungen an Package.resolved wie Änderungen an einer Build-Eingabe. Im Review sollten Sie nachvollziehen können:

• welches Paket aktualisiert wurde;
• ob sich nur die Revision oder auch die Versionsregel geändert hat;
• ob ein lokales Paket auf eine Remote-Quelle zurückgestellt wurde;
• ob ein privates Paket weiterhin erreichbar ist;
• ob das betroffene Scheme dasselbe Product verwendet.

Für einen Remote Mac sollte der Build zunächst exakt den Commit, die Package.resolved und den Auflösungsbefehl aus Ihrem Repository verwenden. Ein automatisches „Update Packages“ bei jeder Aufgabe ist für eine stabile Pipeline die falsche Voreinstellung. Aktualisieren Sie kontrolliert in einem eigenen Änderungsschritt, testen Sie anschließend den vollständigen Build und archivieren Sie die Änderung gemeinsam mit dem Quellcode.

3. Öffentliche und private Repositories getrennt testen

Ein öffentliches Paket und ein privates Paket können im selben Auflösungslog völlig unterschiedliche Fehlerursachen haben. Prüfen Sie daher jede Quelle einzeln. Zerlegen Sie den Fehler in drei Phasen:

1. Verbindung: DNS, Netzwerk, Proxy und TLS;
2. Authentifizierung: SSH-Schlüssel, Token, Benutzer und Agent;
3. Berechtigung und Abruf: Repository-Rechte, Branch, Tag und Revision.

Kontrollieren Sie zunächst die URL in Package.swift und Package.resolved. Eine kleine Abweichung zwischen HTTPS- und SSH-URL kann dazu führen, dass Xcode eine andere Authentifizierung verwendet als Ihr interaktives Terminal.

Für einen nicht geheimen Verbindungstest können Sie die Erreichbarkeit einer bekannten Repository-Referenz prüfen:

git ls-remote "<REPOSITORY>"

Dieser Test beweist jedoch nicht, dass derselbe Benutzer und derselbe Prozess später im CI-Lauf Zugriff haben. Prüfen Sie zusätzlich, welcher Benutzer den automatisierten Job ausführt:

whoami
echo "$HOME"
ssh-add -l

Wenn kein Schlüssel geladen ist, ist das nicht automatisch ein Fehler. Manche Umgebungen verwenden eine Datei direkt über ~/.ssh/config. Wichtig ist, dass die Konfiguration für den tatsächlichen Build-Benutzer existiert. Ein Schlüssel im persönlichen Benutzerprofil hilft einem Dienstkonto nicht.

Warum baut das Projekt lokal, aber die Abhängigkeit scheitert auf dem Remote Mac?
Lokale Sitzungen besitzen oft andere SSH-Agenten, bekannte Hostschlüssel, Git-Konfigurationen, Proxy-Variablen und Zugriffsrechte. Zusätzlich kann Xcode beziehungsweise xcodebuild eine andere Umgebung verwenden als Ihr interaktives Terminal. Vergleichen Sie deshalb nicht nur die Befehle, sondern auch HOME, PATH, DEVELOPER_DIR, den ausführenden Benutzer und den Pfad zum SSH- beziehungsweise Git-Setup.

Verwenden Sie für den Vergleich zwei bewusst getrennte Logdateien:

env | sort > "<LOKALE_UMGEBUNG>.txt"

und im automatisierten Lauf:

env | sort > "<CI_UMGEBUNG>.txt"

Entfernen Sie daraus vor dem Teilen alle Zugangsdaten. Prüfen Sie außerdem, ob ein Proxy nur in der interaktiven Shell gesetzt ist. Bei einem privaten Repository muss der Fehler an der richtigen Stelle erscheinen: „Host nicht gefunden“ ist kein Berechtigungsfehler, „Permission denied“ kein Versionskonflikt und „revision not found“ kein Cache-Problem.

Apple weist in seiner Anleitung zur Behebung häufiger Xcode-Konfigurations- und Build-Probleme ebenfalls darauf hin, dass der konkrete Ausführungskontext für die Diagnose relevant ist. Nutzen Sie diese Hinweise als Rahmen, nicht als Beweis für einen bestimmten privaten Git-Fehler.

4. Cache-Schichten mit begrenztem Eingriff zurücksetzen

„Cache löschen“ ist keine einzelne Maßnahme. Bei Swift Package Manager müssen Sie mindestens zwischen Repository-Cache, ausgecheckten Quellen, DerivedData und fertigen Build-Artefakten unterscheiden.

• Repository-Cache: Kann das erneute Abrufen von Paketquellen beeinflussen.
• Checkout-Verzeichnis: Enthält die lokal ausgecheckten Paketrevisionen.
• DerivedData: Enthält projektbezogene Index-, Build- und Zwischeninformationen.
• Build- und Archive-Artefakte: Können einen bereits erfolgreich aufgelösten Zustand widerspiegeln, aber keine fehlende Repository-Berechtigung reparieren.

Beginnen Sie mit einem Vergleich. Führen Sie die Auflösung mit dem vorhandenen Zustand aus und sichern Sie das Ergebnis. Danach kopieren oder verschieben Sie nur die betroffene Cache-Schicht in ein eindeutig benanntes Sicherungsverzeichnis. Löschen Sie nicht gleichzeitig Repository-Cache, DerivedData, Schlüsselbunddaten und Signaturmaterial. Zertifikate, Provisioning Profiles und Schlüsselbund-Einträge sind keine normalen Build-Zwischendateien.

Was tun, wenn das Zurücksetzen des Package Cache nicht hilft?
Gehen Sie nicht sofort zur vollständigen Neuinstallation über. Vergleichen Sie zunächst die neue Fehlermeldung mit der ursprünglichen Basis. Bleibt der Fehler identisch, liegt die Ursache eher bei Versionsregeln, Repository-Zugriff, Benutzerrechten oder einem nicht erfüllten Product. Ändert sich die Meldung zu einem Checkout- oder Netzwerkfehler, hat der Cache-Vorgang eine andere Schicht sichtbar gemacht. Dokumentieren Sie genau, was geändert wurde.

Ein kontrollierter Test kann mit einem expliziten Quellpfad erfolgen:

xcodebuild \
  -project "<PROJEKT>.xcodeproj" \
  -scheme "<SCHEME>" \
  -resolvePackageDependencies \
  -clonedSourcePackagesDirPath "<TEMPORAERER_PAKETPFAD>"

Der temporäre Pfad muss für den ausführenden Benutzer beschreibbar sein. Verwenden Sie keine Pfade mit echten Zugangsdaten oder internen Hostnamen in veröffentlichten Beispielen. Wenn die Auflösung im frischen Pfad funktioniert, ist die alte Checkout-Schicht verdächtig. Wenn sie ebenfalls scheitert, sollten Sie Netzwerk, Authentifizierung und Versionierung weiter untersuchen.

5. Package Product, Binärabhängigkeiten und Projektstruktur verifizieren

Eine erfolgreiche Auflösung bedeutet nicht automatisch, dass das benötigte Product im Target verfügbar ist. Prüfen Sie daher nach dem Auflösungsschritt:

• Paketname;
• Product-Name;
• Target-Mitgliedschaft;
• Scheme-Zuordnung;
• Plattformunterstützung;
• lokale Paketüberschreibungen;
• zyklische Abhängigkeiten;
• Binärabhängigkeiten und ihre Prüfsummen.

Bei einem Fehler wie „missing package product“ ist ein erneuter Download oft wirkungslos. Das Paket kann vorhanden sein, während das Projekt ein anderes Product erwartet. Ebenso kann ein Binary Target erfolgreich aufgelöst werden, aber beim Einbinden an einer falschen Plattform, einer fehlenden Architektur oder einer ungültigen Prüfsumme scheitern. Nutzen Sie Apples Dokumentation zur Identifizierung von Binärabhängigkeiten, bevor Sie einen Netzwerkfehler vermuten.

Erstellen Sie, falls möglich, ein minimales Reproduktionsprojekt mit:

• demselben Paket;
• derselben Revision;
• demselben Target-Typ;
• derselben Plattform;
• demselben Xcode-Auflösungsbefehl.

Wenn das Minimalprojekt funktioniert, liegt der Fehler wahrscheinlich in der Workspace-Struktur, einer lokalen Paketregel, einem Scheme oder einer Target-Verknüpfung. Wenn auch das Minimalprojekt scheitert, bleibt die Ursache näher an Repository, Version oder Umgebung.

Die vier Zustände sollten in jedem Ticket getrennt notiert werden:

Zustand	Nachweis	Typische nächste Prüfung
Abhängigkeit aufgelöst	Resolving endet ohne Fehler	Package.resolved und Graph
Quelle ausgecheckt	Revision liegt im Checkout	Git-URL, Rechte, Revision
Product verfügbar	Target erkennt das Product	Product- und Target-Namen
Build oder Archive fertig	Artefakt wurde erzeugt	Signierung, Scheme, Archive

So verhindern Sie, dass ein erfolgreiches Checkout fälschlich als erfolgreicher Build gewertet wird.

6. Mit klaren Bedingungen zwischen Reparatur und Neuaufbau entscheiden

Nutzen Sie für die nächste Maßnahme diese Verzweigung:

• Wenn lokale Xcode-Auflösung und xcodebuild denselben Fehler mit demselben Commit zeigen, dann prüfen Sie zuerst Package.resolved, Versionsregeln und Repository-Zugriff.
• Wenn nur xcodebuild scheitert, dann vergleichen Sie Benutzer, HOME, SSH-Agent, Git-Konfiguration und DEVELOPER_DIR.
• Wenn nur der Remote Mac scheitert, dann reproduzieren Sie den Lauf unter dem tatsächlichen Dienstkonto und testen Sie die private Repository-Authentifizierung.
• Wenn die Auflösung erfolgreich ist, aber ein Product fehlt, dann prüfen Sie Target, Scheme, Product-Namen und lokale Paketüberschreibungen.
• Wenn ein frischer Checkout denselben Fehler erzeugt, dann bringt weiteres Cache-Löschen voraussichtlich keinen Erkenntnisgewinn; wechseln Sie zur Versions-, Netzwerk- oder Berechtigungsprüfung.
• Wenn derselbe Commit mit derselben Package.resolved auf keiner kontrollierten Umgebung stabil aufgelöst wird, dann erstellen Sie eine minimale Reproduktion und planen erst danach eine Umgebungsänderung.
• Wenn nur eine Umgebung instabil ist, dann reparieren oder migrieren Sie diese Umgebung, statt beide Build-Systeme gleichzeitig zu verändern.

Die folgende Übersicht hilft Ihnen, den Eingriff klein zu halten:

Beobachtung	Wahrscheinlichere Ebene	Maßnahme
Version in Package.resolved passt nicht zur Regel	Versionsgraph	Lock-Datei und Regeln im Review vergleichen
Öffentliche Pakete funktionieren, privates Paket nicht	Authentifizierung oder Rechte	URL, Benutzer, SSH und Berechtigung einzeln testen
Frischer Checkout scheitert identisch	Nicht primär Cache	Netzwerk, Revision und Versionierung prüfen
Auflösung gelingt, Product fehlt	Projektstruktur	Target, Scheme und Product-Verknüpfung prüfen
Nur unbeaufsichtigter Lauf scheitert	Ausführungskontext	Dienstkonto und Umgebungsvariablen angleichen

7. Den Remote Mac als reproduzierbare Build-Umgebung abnehmen

Ein Remote Mac ist erst als iOS-Build-Server geeignet, wenn ein Erfolg wiederholbar ist. Ein einzelner grüner Lauf beweist nicht, dass nach einem Neustart, einem leeren Arbeitsverzeichnis oder einem erneuten Checkout dieselbe Paketauflösung gelingt.

Verwenden Sie für die Abnahme immer:

• denselben Commit;
• dieselbe Package.resolved;
• dieselbe Xcode-Version;
• dasselbe Scheme;
• denselben ausführenden Benutzer;
• denselben xcodebuild-Befehl.

Führen Sie anschließend mindestens diese Abfolge aus:

1. Repository in ein sauberes Arbeitsverzeichnis auschecken.
2. Xcode-Version und Developer-Pfad protokollieren.
3. Swift-Paketabhängigkeiten explizit auflösen.
4. Einen normalen Build ausführen.
5. Ein Archive mit derselben Eingabebasis erzeugen.
6. Den Host neu starten und den Ablauf wiederholen.
7. Arbeitsverzeichnis und Paket-Checkout entfernen.
8. Repository und Abhängigkeiten erneut abrufen.
9. Prüfen, ob der unbeaufsichtigte Benutzer dieselbe Git- und SSH-Konfiguration liest.

Die Apple-Anleitung für CI-Builds von Swift Packages und Anwendungen ist dafür der passende Referenzpunkt. Ergänzend sollten Sie die Xcode-26.6-Release-Notes auf bekannte Änderungen prüfen. Release Notes sind eine bestätigte Quelle für dokumentierte Änderungen, aber nicht jeder Einzelfehler in einem Entwicklerforum ist eine allgemeine Xcode-Regel.

Für einen kleinen Team-Runbook genügt eine kurze Übergabedatei mit dem bereinigten Baseline-Log, dem Commit, dem Hash von Package.resolved, dem verwendeten Benutzer und dem Ergebnis jedes Zustands. Ein privater Schlüssel oder ein vollständiger interner Repository-Pfad gehört nicht hinein. Prüfen Sie außerdem DSGVO-relevante Logdaten: Benutzernamen, interne Domains und Pfade können personenbezogene oder vertrauliche Informationen enthalten.

Abnahmetest	Erwarteter Nachweis	Entscheidung
Gleicher Commit, gleiche Lock-Datei	Identischer Paketgraph	Umgebung grundsätzlich vergleichbar
Normaler Build	Targets und Products werden gefunden	Projektstruktur belastbar
Archive	Release-Konfiguration erreicht den Archive-Schritt	Build-Server für Veröffentlichung geeignet
Neustart des Hosts	Konfiguration wird wieder geladen	Kein zufälliger Sitzungszustand
Leeres Arbeitsverzeichnis	Abhängigkeiten werden reproduzierbar bezogen	Cache ist nicht die einzige Voraussetzung
Unbeaufsichtigter Lauf	Derselbe Benutzer findet Git und SSH	CI-Betrieb ist operationalisierbar

Szenario: Der Fehler sitzt nicht im Paket

Angenommen, ein Workspace löst lokal erfolgreich auf. Auf dem Remote Mac erscheint dagegen ein Fehler beim Zugriff auf ein privates Repository. Nach dem Wechsel auf den Build-Benutzer zeigt sich, dass HOME auf ein anderes Verzeichnis verweist und dort keine SSH-Konfiguration vorhanden ist. Das Löschen von DerivedData hätte daran nichts geändert.

In diesem Fall lautet die richtige Reparatur nicht „Cache vollständig leeren“. Sie besteht darin, den Zugriff für den tatsächlich ausgeführten Prozess sauber einzurichten, den Hostschlüssel kontrolliert zu prüfen und danach denselben Auflösungsbefehl erneut mit anonymisiertem Log auszuführen. Erst wenn die Verbindung funktioniert, lässt sich beurteilen, ob die Lock-Datei oder das Package Product zusätzlich fehlerhaft ist.

Option	Vorteil	Nachteil	Geeignet, wenn
Lokaler Mac	Direkte Bedienung und vorhandene Entwickleranmeldung	Hardware, Wartung und dauerhafte Verfügbarkeit liegen bei Ihnen	Sie täglich interaktiv entwickeln
Remote Mac	Separater Build- und Testplatz ohne eigenen Dauerbetrieb	Benutzer-, Netzwerk- und Zugriffskonfiguration müssen sauber dokumentiert werden	Sie temporäre oder kontinuierliche Builds trennen möchten
Neuaufbau der Umgebung	Entfernt unbekannte Altlasten	Verdeckte Konfigurationsfehler können erneut auftreten	Eine reproduzierbare Basis zuvor dokumentiert wurde
Bestehende Umgebung reparieren	Lock-Datei, Cache und Zugänge bleiben nachvollziehbar	Diagnose erfordert mehr Disziplin	Nur eine Schicht nachweislich fehlerhaft ist

Vor der nächsten Änderung: die minimale Entscheidung treffen

Wenn Ihr lokaler und automatisierter Lauf mit derselben Eingabebasis identische Auflösungsfehler zeigen, arbeiten Sie am Repository- und Versionsgraphen weiter. Wenn nur der Remote Mac betroffen ist, sind Benutzerkontext, SSH, Git-Anbieter, Arbeitsverzeichnis oder Umgebungsvariablen die erste Spur. Ein vollständiger Neuaufbau ist erst gerechtfertigt, wenn eine dokumentierte Minimalreproduktion auch nach sauberem Checkout keine stabile Basis ergibt.

Für den Betrieb auf einem Remote Mac sollten Sie die Abnahme außerdem an Ihrem tatsächlichen Miet- und Arbeitsmodell testen. Prüfen Sie vor einer dauerhaften Nutzung, ob der Rechner nach Neustart, Verzeichnisbereinigung und erneutem Repository-Checkout denselben Ablauf durchläuft. Einen passenden Einstieg bietet die deutsche Übersichtsseite von MACCOME. Wenn Sie den Kauf eines eigenen Geräts gegen einen zeitweise benötigten Build-Platz abwägen, können Sie zusätzlich die Informationen zum Mac mini als Vergleichspunkt heranziehen.

Die Alternative ist nicht immer eine Miete. Für dauerhaft hohe Auslastung, besondere physische Schnittstellen oder eine langfristig unveränderte Umgebung kann ein eigener Mac wirtschaftlich und organisatorisch sinnvoller sein. Ein Remote Mac ist dagegen häufig die passendere Option, wenn Sie Xcode nur für Releases, CI-Tests oder einen begrenzten Entwicklungszeitraum benötigen. Ein lokaler Windows- oder Linux-Arbeitsplatz löst die Abhängigkeit von macOS für Xcode, Signierung und Archive nicht; zusätzliche Übergaben, wechselnde Zugangsdaten und unklare Cache-Zustände machen die Pipeline eher schwerer prüfbar. Wenn Sie dafür bei MACCOME einen Remote Mac mieten, sollten Sie nicht mit dem Paketpreis beginnen, sondern mit dem beschriebenen Baseline-Test: erst auflösen, dann bauen, dann archivieren und den Ablauf nach einem Neustart wiederholen.

Damit bleibt die Diagnose nachvollziehbar: Versionen und Package.resolved bilden die feste Eingabe, Git und SSH belegen den Zugriff, der Cache erklärt nur einen begrenzten Fehlerbereich, und die Remote-Umgebung muss denselben Ablauf unbeaufsichtigt wiederholen können.