open-kritt auf VPS selbst hosten: Docker-Setup und SSH

Warum Sie open-kritt auf einem VPS und nicht auf Ihrem Laptop selbst hosten sollten

Hosten Sie open-kritt auf einem Server, den Sie zerstören und neu aufbauen können. Das Tool führt seine Analyseagenten als root in kurzlebigen Job-Containern aus, stellt jedem Agenten eine beschreibbare Kopie Ihres Codes bereit, gewährt direkten Internetzugriff und bindet den Docker-Socket des Hosts in seinen Engine-Dienst ein. Auf einem ausschließlich für diese Aufgabe vorgesehenen System ist das ein vertretbarer Kompromiss. Auf dem Rechner, auf dem Ihre SSH-Schlüssel liegen, ist er riskant.

Vier Eigenschaften der Standardkonfiguration führen zu dieser Empfehlung. Alle vier stammen aus der README-Datei und der Compose-Datei des Projekts.

Die Agenten sind für weitreichende Zugriffsrechte ausgelegt. In der README-Datei steht, dass tool-aktivierte Agenten als root in kurzlebigen Job-Containern ausgeführt werden. Sie erhalten beschreibbare Kopien der Repositorys und direkten Internetzugriff. Dadurch können sie Tools installieren, Ziele kompilieren, Tests ausführen und Proofs of Concept erstellen. Ein Scan ist kein Linter, der Dateien liest. Er führt beliebigen Code aus, den Sie ausdrücklich angefordert haben. Der Internetzugriff wirkt in beide Richtungen: Alles, was ein Agent bei der Untersuchung eines Ziels abruft, ist nicht vertrauenswürdiger Text, der in seinen Prompt gelangt. Derselben Gefährdung setzen Sie sich aus, wenn Sie einem Agenten eine eigene Websuche überlassen.

Die Engine hat Zugriff auf den Docker-Socket. docker-compose.yml bindet den Docker-Socket des Hosts in den Engine-Dienst ein, weil die Engine pro Job einen Scan-Container erstellt und startet. Jeder Prozess, der diesen Socket erreichen kann, kann einen Container starten, der das Dateisystem des Hosts einbindet. Daher hat die Engine auf dem jeweiligen Host effektiv root-Rechte.

Es gibt keine Anmeldeseite. Das Backend wird ohne Anwendungsauthentifizierung ausgeliefert. Der Zugriff auf den Port ermöglicht den Zugriff auf Ihre Ergebnisse und auf Ihr Provider-Guthaben.

Der analysierte Code stammt häufig nicht von Ihnen. Wenn Sie Agenten auf ein Repository eines Dritten ansetzen, wird der Build dieses Repositorys auf Ihrem Rechner als root und mit Netzwerkzugriff ausgeführt.

Wenn Sie gelesen haben, warum Coding-Agenten in eine kurzlebige VM gehören, gilt hier dasselbe Bedrohungsmodell, allerdings mit größeren Auswirkungen. Stellen Sie open-kritt einen VPS bereit, auf dem keine anderen Dienste laufen. Verwalten Sie diesen VPS über ein separates Benutzerkonto mit den geringsten erforderlichen Rechten und nicht über root.

Was open-kritt tatsächlich macht

open-kritt (das Repository ist Kritt-ai/open-kritt und unter AGPL-3.0 lizenziert) zerlegt die Sicherheitsforschung in kleine Aufgaben, führt diese Aufgaben parallel über mehrere KI-Agenten aus und entfernt anschließend Duplikate aus den Ergebnissen und priorisiert sie. Sie definieren einen Workflow als Kette fokussierter Prompts. Jeder Schritt erhält strukturierten Kontext aus den vorherigen Schritten. Das Scan-Ziel ist ein entferntes oder lokales Git-Repository. Die Analyse-Engine ist Codex oder Claude Code. Sobald ein Kandidat gefunden wurde, können optionale Post-Skripte versuchen, ihn zu validieren oder einen Proof of Concept zu erstellen. Das Entwerfen dieser Kette ist normale Agentenarbeit und keine Sicherheitsarbeit. Wenn Prompts, Tools und die Übergabe von Kontext für Sie noch ungewohnt sind, bringt das Verständnis des Aufbaus von Agenten bessere Ergebnisse als jede Einstellung in diesem Leitfaden.

Am Ende erhalten Sie eine priorisierte Liste von Kandidaten. Behandeln Sie sie als Triage-Warteschlange und nicht als Bericht.

Voraussetzungen

• Ein VPS mit Ubuntu 24.04, Debian 12 oder Rocky Linux 9. In der Installationsdokumentation sind diese Distributionen als getestet aufgeführt, jeweils für x86_64 und ARM64.
• Docker Engine mit dem Compose-Plugin.
• Node.js 20 oder neuer auf dem Host, da die ./kritt CLI auf dem Host und nicht in einem Container ausgeführt wird.
• Einen Modellanbieter: ein Codex-Login oder OPENAI_API_KEY, CODEX_API_KEY, ANTHROPIC_API_KEY oder OPENROUTER_API_KEY.
• GITHUB_TOKEN nur, wenn Sie private Repositorys scannen möchten. Die mitgelieferte .env.example formuliert es eindeutig: Mit einem GitHub-Token allein können keine Scans ausgeführt werden.

Zuerst Docker und Node 20 installieren

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

Melden Sie sich ab und wieder an, damit die neue Gruppenmitgliedschaft aktiv wird. Prüfen Sie anschließend, ob das Compose-Plugin vorhanden ist.

docker compose version

Eine Versionszeichenfolge zeigt an, dass Compose als Plugin installiert ist. docker: 'compose' is not a docker command bedeutet, dass stattdessen die alte eigenständige Binärdatei docker-compose installiert ist, und open-kritt ruft docker compose auf. Die Mitgliedschaft in der Gruppe docker entspricht Root-Rechten auf dem Host. Nehmen Sie daher nur das Konto auf, unter dem open-kritt ausgeführt wird. Eine ausführlichere Beschreibung dieser Einrichtung finden Sie unter Docker auf einem VPS ausführen.

Ubuntu 24.04 stellt im eigenen Repository Node 18 bereit. Die CLI wird mit jeder Version unter 20 beendet. Verwenden Sie NodeSource.

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
node -v

node -v muss v20. oder höher ausgeben. Unter Rocky Linux 9 verwenden Sie entsprechend sudo dnf module enable nodejs:20 -y gefolgt von sudo dnf install -y nodejs.

Get open-kritt und fixieren Sie eine markierte Version

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt
git fetch --tags
git tag --list
git checkout v1.3.0

main wird weiterentwickelt. Ein Tag ändert sich nicht. Im August 2026 ist der neueste Tag v1.3.0, der am 4. August 2026 veröffentlicht wurde. git tag --list zeigt, welche Version am Tag des Klonens vorhanden ist. Wenn Sie einen Tag auschecken, befindet sich das Repository im Zustand „detached HEAD“. Das ist hier korrekt: Sie verwenden diesen Klon als festgelegte Bereitstellung und nicht als Branch, in den Sie Commits schreiben. Lesen Sie für ein späteres Upgrade zunächst die Release-Hinweise. Führen Sie dann git fetch --tags aus, checken Sie den neuen Tag aus und führen Sie anschließend erneut ./kritt start aus, da start die Images neu erstellt.

Führen Sie ./kritt nicht mit sudo aus. Die Dokumentation weist ausdrücklich darauf hin. Die CLI verwaltet projektspezifische Verzeichnisse für Zugangsdaten unter .data/. Wenn Sie den Befehl als root ausführen, gehören diese Verzeichnisse anschließend root. Beim nächsten normalen Aufruf können sie dann nicht beschrieben werden.

Zugriff auf Modelle mit ./kritt setup konfigurieren

./kritt setup

Der Befehl erstellt .env aus .env.example, falls die Datei noch nicht existiert, gibt den Status jedes Zugangsdaten-Eintrags aus und ermöglicht es Ihnen, die Einträge zu setzen oder zu entfernen. Die Werte werden niemals wieder im Terminal ausgegeben. Sowohl .env als auch die Zugangsdaten-Datei der Engine werden mit dem Modus 0600 angelegt.

Wenn Sie dies lieber manuell erledigen möchten:

cp .env.example .env
chmod 600 .env
mkdir -p .data/codex
chmod 700 .data/codex

Tragen Sie anschließend den Provider-Schlüssel in .env ein und belassen Sie die Datei im Modus 0600. Auf diesem Server liegt dann in beiden Fällen ein gültiger Provider-Zugang, was ein weiterer Grund ist, auf dem System keine anderen Daten zu speichern. Erstellen Sie einen Schlüssel ausschließlich für dieses Projekt. Wenn Sie ihn später widerrufen, werden dadurch keine anderen wichtigen Anwendungen beeinträchtigt. Geheimnisse vor dem Zugriff von KI-Agenten schützen beschreibt diese Vorgehensweise umfassender.

Ausgabenlimit beim Provider vor dem ersten Scan festlegen

open-kritt ist darauf ausgelegt, Aufgaben auf mehrere Prozesse zu verteilen. Genau diese Verteilung verursacht die Kosten. Die Standardwerte in .env.example bei v1.3.0 sind konservativ: ENGINE_WORKER_COUNT=2, in der Datei als konservativer Standardwert für eine kleine Maschine mit 2 vCPUs beschrieben, und ENGINE_MAX_CONCURRENT_SCANS=1. Darüber liegen ENGINE_WORKERS_PER_ACCOUNT=15, die maximal zulässige Anzahl gleichzeitig ausgeführter Aufrufe des Root-Modells über ein Provider-Konto, sowie ENGINE_CODEX_MAX_SUBAGENTS_PER_SESSION=5, weil eine Codex-Sitzung bis zu fünf untergeordnete Agenten ausführen kann. Wenn Sie die Anzahl der Worker auf einem größeren VPS erhöhen, steigt auch die Anzahl der gleichzeitig ausgeführten Modellaufrufe.

Nichts im Repository begrenzt Ihre Ausgaben. In .env.example gibt es keine Budgeteinstellung. Die eigenen Abbruchbedingungen der Engine sind die Worker-Limits sowie ENGINE_HARNESS_TIMEOUT_SECONDS, das standardmäßig 7200 Sekunden pro Harness-Ausführung festlegt. Ein Harness ist hier die Schleife, die das Modell so lange mit Tools und Kontext aufruft, bis etwas die Ausführung beendet. Dieses Timeout ist daher eine Wanduhrzeit für das Programm, das um das Modell herum ausgeführt wird, keine Begrenzung für die Ausgaben, die das Modell innerhalb dieses Programms verursacht. Die Obergrenze muss daher beim Provider festgelegt werden. Öffnen Sie die Konsole Ihres Providers und setzen Sie vor dem ersten Scan ein hartes monatliches Limit, nicht erst danach. Kosten eines AI-Agenten auf einem VPS kontrollieren beschreibt die Einstellungen der einzelnen Provider.

Es gibt auch eine lokale Begrenzung. Wenn Sie ENGINE_WORKER_COUNT=0 setzen, werden keine neuen Jobs mehr übernommen. Die gleichen Worker-Werte können Sie ändern, sobald der Stack läuft, und zwar im Bildschirm Settings.

Dieser Leitfaden nennt keinen Preis pro Scan, weil die Kosten von der Größe des Repositorys, dem erstellten Workflow und dem dahinter verwendeten Modell abhängen. Führen Sie zunächst einen Scan für ein kleines Repository aus. Prüfen Sie anschließend die Nutzungsseite Ihres Providers, bevor Sie den Scan auf größere Repositorys anwenden.

Stack starten und prüfen, ob er fehlerfrei läuft

./kritt start

Damit werden .env und mindestens ein Zugangsdaten-Eintrag geprüft und anschließend docker compose up --build ausgeführt. Der erste Build dauert lange, weil dabei die Images für Frontend, Backend, Engine, Executor-Ansicht und Datenbank erstellt werden. Der Prozess läuft außerdem im Vordergrund. Wenn Sie die SSH-Sitzung schließen, wird der Stack beendet. Starten Sie ihn innerhalb von tmux oder starten Sie ihn nach erfolgreichem ersten Build detached. Keine dieser Varianten übersteht einen Reboot automatisch. Wenn der Stack nach einem Neustart des Servers wieder gestartet werden soll, lässt sich das systemd-Unit-Muster aus einen Self-Hosted-Agent über Reboots hinweg ausführen direkt übertragen.

docker compose up -d --build
docker compose ps

docker compose ps sollte open-kritt-frontend, open-kritt-backend, open-kritt-engine, open-kritt-executor-view und open-kritt-db auflisten. Prüfen Sie anschließend, ob das Backend auf dem Server selbst antwortet.

curl -s http://127.0.0.1:3002/api/health

Eine JSON-Antwort bedeutet, dass das Backend läuft. Failed to connect to 127.0.0.1 port 3002: Connection refused bedeutet, dass dies nicht der Fall ist, und docker compose logs backend zeigt den Grund an. Beenden Sie alles mit docker compose down aus dem Repository-Verzeichnis.

Optional können Sie docker compose exec backend npm run seed verwenden, um Demodaten zu laden. Damit lässt sich die Oberfläche kostengünstig prüfen, bevor Sie einen echten Scan durchführen.

Die Benutzeroberfläche über einen SSH-Tunnel auf Port 5173 erreichen

Jeder Dienst in der Compose-Datei bindet standardmäßig an 127.0.0.1: das Frontend an Port 5173, das Backend an Port 3002, die Executor-Ansicht an Port 8090 und Postgres an Port 5432. Lassen Sie diese Bindings unverändert und leiten Sie den Port von Ihrem eigenen Rechner über SSH weiter.

ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip

Öffnen Sie http://localhost:5173 in Ihrem lokalen Browser, während dieser Befehl läuft. -N bedeutet, dass die Verbindung die Weiterleitung übernimmt und keine Shell öffnet. Fügen Sie demselben Befehl ein zweites -L 8090:127.0.0.1:8090 hinzu, wenn Sie auch die Executor-Ansicht benötigen.

Die naheliegende Lösung ist, FRONTEND_BIND_ADDRESS=0.0.0.0 zu setzen und den Tunnel wegzulassen. Tun Sie das nicht. Das Backend hat keine Anmeldemaske. Jeder, der diese Seite erreicht, kann Scans starten und Ihr Provider-Guthaben verbrauchen. Zum Vergleich: Vaultwarden ist dafür ausgelegt, aus dem Internet erreichbar zu sein. Die Absicherung hängt dort weiterhin vom Admin-Token und der Backup-Datei ab. Diese Optionen bietet open-kritt nicht. Darunter gibt es eine zweite Falle: Ein veröffentlichter Container-Port wird verarbeitet, bevor die Standardrichtlinie von ufw greift. Daher sieht eine ufw deny 5173-Regel zwar korrekt aus, blockiert aber nichts. Docker-Ports, die ufw umgehen zeigt die Regelkette, die dafür verantwortlich ist.

Größe des VPS

ENGINE_MIN_FREE_STORAGE_GB ist standardmäßig auf 20 gesetzt. Die Engine startet keinen neuen Scan-Container pro Auftrag, wenn der freie Speicher darunter fällt. Die erstellten Images, der Checkout-Cache, die Postgres-Daten und die Arbeitsbereiche der Aufträge liegen alle auf derselben Festplatte. Daher startet eine VPS mit 20 GB überhaupt keinen Scan. Betrachten Sie 40 GB als Untergrenze und planen Sie mehr ein, wenn Sie große Repositorys scannen. Versuchen Sie nicht, den ungenutzten Speicher durch einen speicherintensiven Dienst auf demselben System zu nutzen. Die gemessenen Mindestwerte für RAM und Speicherplatz in diesem Vergleich von PhotoPrism und Immich zeigen, wie schnell eine Medienbibliothek den für einen Scan erforderlichen Spielraum aufbrauchen kann. Dasselbe gilt für optionale Ergänzungen, die neben einem Scanner wenig Ressourcen zu benötigen scheinen: Eine Browser-Oberfläche, die eine Jellyfin-Mediathek wie eine Videothek aus den 90er-Jahren darstellt, bringt dennoch einen vollständigen Medienserver und dessen Transkodierungen auf die dahinterliegende Festplatte. Hosten Sie sie daher auf einem anderen System.

Für den Speicherbedarf gilt eine einfache Rechnung. ENGINE_MEMORY_RESERVE_GB=2 hält Speicher für die Engine, die Datenbank, die API und kurzlebige Zusatzlast zurück. Jeder Scan-Runner hat außerdem eine Reservierung und ein festes Limit von ENGINE_SCAN_RUNNER_MEMORY_MB=1536. Zwei Worker benötigen daher bereits etwa 5 GB, bevor andere Prozesse laufen. Die Engine lässt nur so viele Runner zu, wie in das verbleibende Budget passen. Auf einem kleinen Server werden Scans daher in die Warteschlange gestellt, statt fehlzuschlagen. Das ist ein deutlich besseres Fehlerverhalten als ein Eingriff des Out-of-Memory-Killers. Dieselbe Rechnung gilt als Mindestwert für jedes Tool, das jeder Arbeitseinheit einen eigenen Container zuweist. Deshalb stößt OpenBots ein Container und Browser pro AI-Mitarbeiter viel früher an eine RAM-Grenze als an eine CPU-Grenze.

Zwei Bereinigungseinstellungen sind standardmäßig auf true gesetzt: ENGINE_AUTO_PRUNE_DOCKER_BUILD_CACHE und ENGINE_AUTO_PRUNE_UNUSED_DOCKER_IMAGES. Nach Abschluss einer Aufgabe entfernt die Engine nicht verwendeten Build-Cache, nicht verwendete Images und beendete Scan-Container. Von einem laufenden Container verwendete Images, Bind-Mounts, Datenbankdaten, Zugangsdaten und Volumes bleiben erhalten. Das ist ein weiterer Grund, den Host nicht gemeinsam zu verwenden: Ein Pruner, den Sie nicht konfiguriert haben, läuft gegen diesen Docker-Daemon.

Lokales Repository scannen, ohne es offenzulegen

LOCAL_REPOS_PATH ist standardmäßig auf ./local_repos gesetzt und wird in den Backend- und Engine-Containern unter /local_repos als Bind-Mount eingebunden. Ein Repository, das Sie in diesen Ordner auf dem Host ablegen, ist daher sofort in den Containern verfügbar. Verwenden Sie einen frischen Clone, nicht Ihren Arbeitsbaum. Der Job-Container erhält eine beschreibbare Kopie, läuft darin als root und hat ausgehenden Internetzugriff. Alles, was sich in dieser Kopie befindet, kann daher geändert oder vom Host übertragen werden. Entfernen Sie .env-Dateien und private Schlüssel, bevor Sie ein Projekt hineinkopieren.

Was Sie erhalten und was nicht

Sie erhalten nach Rang sortierte potenzielle Befunde. Sie erhalten keine verifizierten Schwachstellen. Ranking und Deduplizierung bestimmen die Reihenfolge Ihrer Triage-Warteschlange. Sie beweisen nicht, dass ein Eintrag tatsächlich zutrifft. Post-Skripte können eine Validierung versuchen und einen Proof of Concept erstellen. Das ist jedoch nur das stärkste Signal, das das Tool liefert. Wenn ein Post-Skript fehlschlägt, ist das kein Beleg dafür, dass der Befund falsch ist. Eine Person prüft weiterhin jeden potenziellen Befund. Dieser Unterschied zwischen einem potenziellen Befund und einem Beweis ist der Grund, warum einen Agenten nach selbst erneut ausführbaren Belegen zu fragen auch hier sinnvoll ist: Einen Befund, den Sie bei Bedarf reproduzieren können, sollten Sie höher bewerten als einen nach Rang sortierten Befund, dessen Richtigkeit Sie ungeprüft annehmen müssen.

Dieser Leitfaden macht keine Aussage darüber, wie viele echte Fehler open-kritt findet, da wir dies nicht gemessen haben. Wer für Ihre Codebasis eine Erkennungsrate nennt, hat das Tool nicht gegen Ihre Codebasis ausgeführt. Scannen Sie zunächst ein Repository, das Sie bereits gut kennen. Befunde, die Sie selbst beurteilen können, sind die kostengünstigste verfügbare Kalibrierung.

Die Autorisierung ist hier wichtiger als bei den meisten Self-Hosting-Tools. Die Agenten kompilieren Code, führen ihn aus und greifen auf das Netzwerk zu. Ein Proof-of-Concept-Schritt kann daher aktive Systeme erreichen. Richten Sie das Tool auf Code, der Ihnen gehört oder den Sie vertraglich testen dürfen. Dokumentieren Sie den Zielbereich, bevor Sie irgendetwas ausführen. Wenn Sie ANTHROPIC_API_KEY konfigurieren und die Claude Code Engine verwenden, gelten die Vorgehensweisen für eine sichere Ausführung von Claude Code auf einem VPS aus Claude Code sicher auf einem VPS ausführen auch für diese Agenten.

FAQ

Warum benötigt open-kritt einen eigenen VPS?

Die Analyse-Agenten laufen als root in temporären Job-Containern mit beschreibbaren Kopien Ihres Codes und direktem Internetzugriff. Außerdem bindet der Engine-Dienst den Docker-Socket des Hosts ein, damit er für jeden Job einen Container starten kann. Jeder Prozess, der diesen Socket erreicht, kann einen Container starten, der das Dateisystem des Hosts einbindet. Deshalb sollte der gesamte Stack so behandelt werden, als hätte er root-Rechte auf seinem Host. Auf einem dedizierten VPS ist dieser Kompromiss vertretbar. Eine Neuinstallation des Systems verursacht dort keinen nennenswerten Aufwand. Auf Ihrer täglichen Workstation befinden sich Ihre SSH-Schlüssel und Browserprofile dann innerhalb derselben Vertrauensgrenze wie der Code, den Sie prüfen.

Kann ich Port 5173 statt eines SSH-Tunnels veröffentlichen?

Das sollten Sie nicht tun. Das Backend wird ohne Anwendungsauthentifizierung ausgeliefert. Der Port ist daher die einzige Barriere zwischen dem Internet sowie Ihren Analyseergebnissen und dem Guthaben beim Provider. Die Compose-Datei bindet deshalb jeden Dienst an 127.0.0.1. Führen Sie stattdessen ssh -N -L 5173:127.0.0.1:5173 you@your-server-ip aus und rufen Sie http://localhost:5173 lokal im Browser auf. Eine ufw-Regel ist kein Ersatz dafür, weil ein veröffentlichter Docker-Port verarbeitet wird, bevor die Standardrichtlinie von ufw greift.

Wie verhindere ich, dass open-kritt mehr ausgibt als geplant?

Legen Sie vor dem ersten Scan in der Konsole Ihres Modell-Providers ein hartes Limit fest, weil open-kritt keine eigene Budgeteinstellung besitzt. Behalten Sie für die ersten Durchläufe die ausgelieferten Nebenläufigkeitsstandards bei: ENGINE_WORKER_COUNT=2 und ENGINE_MAX_CONCURRENT_SCANS=1. Beachten Sie außerdem, dass ein Provider-Konto standardmäßig bis zu 15 gleichzeitige Aufrufe des root-Modells erlaubt, während eine Codex-Sitzung bis zu fünf untergeordnete Agenten ausführen kann. ENGINE_WORKER_COUNT=0 hält die Aufnahme neuer Jobs an und ist der schnellste lokale Stopp.

Welche Version sollte ich auschecken?

Ein Tag, niemals main. git fetch --tags gefolgt von git tag --list zeigt, was verfügbar ist. v1.3.0, veröffentlicht am 4. August 2026, ist zum Zeitpunkt der Erstellung dieses Textes die neueste Version. Durch das Festlegen einer Version erzeugt ein Monate späterer Neuaufbau denselben Stack. Außerdem wird das Upgrade zu einer bewussten Entscheidung nach dem Lesen der Release Notes und nicht zu einem Nebeneffekt des Klonens an einem anderen Tag.

Ein Scan startet nie. Was sollte ich prüfen?

Prüfen Sie zuerst den freien Speicherplatz. Die Engine startet keinen Scan-Container pro Job, wenn weniger freier Speicher als ENGINE_MIN_FREE_STORAGE_GB verfügbar ist; der Standardwert beträgt 20 GB. Prüfen Sie anschließend, dass ENGINE_WORKER_COUNT nicht auf 0 gesetzt ist, weil dieser Wert die Aufnahme neuer Jobs pausiert. Bestätigen Sie danach mit ./kritt setup, dass ein Modellzugang tatsächlich konfiguriert ist. Ein GITHUB_TOKEN allein kann keine Scans ausführen. docker compose logs engine nennt den Grund, aus dem der Job übersprungen wurde.