Poisoned Repos: So sicherst du Claude Code und Cursor gegen Angriffe ab

Am 8. Juli 2026 haben zwei Forscher des AI Now Institute einen Versuch veröffentlicht, der auf eine unangenehme Art elegant ist. Sie gaben KI-Coding-Agenten eine völlig normale Aufgabe: Prüf diese Bibliothek, bevor wir sie übernehmen. Die Agenten prüften. Und führten dabei genau den Schadcode aus, den sie finden sollten. Getestet wurden Claude Code und OpenAI Codex über vier verschiedene Modelle hinweg, alle verwundbar. Dafür brauchte es nicht einmal eine Konfigurationsdatei: Die Anweisungen lagen im Quellcode und in der README der Bibliothek. Als die Forscher direkt nachfragten, ob das Repository versteckte Anweisungen enthalte, antworteten die Modelle: nein. Und führten sie danach trotzdem aus.

Das klingt nach Labor, und es ist auch eins. Dasselbe Grundmuster lief allerdings einen Monat vorher in freier Wildbahn, nur durch eine bequemere Tür. Am 3. Juni 2026 begann der Miasma-Wurm, sich über manipulierte Konfigurationsdateien in GitHub-Repositories zu verbreiten. Er wurde nicht aktiv, wenn jemand Code ausführte. Er wurde aktiv, wenn jemand das Repository im Editor öffnete. Zwei Tage später sperrte GitHub 73 Microsoft-Repositories. Zugewiesene CVEs: keine. Standard-Scanner: sauber.

Ich baue seit über 20 Jahren Software fürs Web und arbeite jeden Tag mit Claude Code. Das hier wird also kein Anti-KI-Artikel. Aber es gibt einen Unterschied zwischen “die KI schreibt unsicheren Code”, worüber ich im Artikel zu Vibe Coding Security geschrieben habe, und dem, was hier passiert. Hier schreibt die KI keinen unsicheren Code. Hier wird sie selbst zum Werkzeug des Angreifers, und zwar bevor du auch nur einen einzigen Prompt getippt hast.

Wir schauen uns zuerst an, warum sich die Angriffsfläche verschoben hat und was beim Öffnen eines fremden Repos wirklich passiert. Dann seziere ich, was der Miasma-Wurm konkret getan hat und welche Dateien dein Agent liest, ohne dich zu fragen. Danach wird es praktisch: eine Prüfung, die 30 Sekunden dauert, und ein Setup, bei dem dir das alles egal sein kann. Und am Ende, wie immer, eine ehrliche Einordnung ohne Panikmache.

Die Angriffsfläche hat sich verschoben

Fremdem Code zu misstrauen, das hast du gelernt. Du weißt, dass ein npm install Skripte ausführen kann. Du weißt, dass du dir ansehen solltest, was du da eigentlich startest. Die Regel dahinter war jahrelang verlässlich: Code muss laufen, um dir zu schaden, und ob er läuft, entscheidest du.

Ein Agent kehrt diese Regel um. Er liest die Konfiguration aus dem Projektverzeichnis, bevor du den ersten Prompt tippst, und er behandelt sie als Anweisung. Nicht als Datei, die er dir zeigt. Als Auftrag, den er ausführt.

Der Unterschied ist fundamental: Fremder Code muss ausgeführt werden, um zu schaden. Fremde Konfiguration muss nur gelesen werden.

Das ist auch die saubere Abgrenzung zum Vibe-Coding-Thema. Dort ging es um das, was die KI produziert: die String-verkettete Datenbank-Query, den hartcodierten API-Key, den fehlenden Auth-Check. Das Problem war die Ausgabe, und die konntest du reviewen. Hier ist das Problem die Eingabe. Es geht um das, was dein Agent liest, bevor er überhaupt etwas produziert. Und das reviewt niemand, weil niemand auf die Idee kommt, dass eine Einstellungsdatei ein Angriff sein könnte.

Was beim Öffnen eines Repos wirklich passiert

Der Ablauf ist so alltäglich, dass er unsichtbar geworden ist. Du siehst ein interessantes Projekt, klonst es, wechselst hinein und startest deinen Agenten, um dir erklären zu lassen, was da drin vorgeht. Fühlt sich harmlos an. Du hast doch nur geguckt.

Genau eine Hürde steht dazwischen. Claude Code fragt dich beim ersten Start in einem neuen Verzeichnis, ob du den Dateien in diesem Ordner vertraust. Du drückst Enter, weil du ja nur gucken willst. Ab diesem Moment ist die Sache entschieden.

Denn beim Start macht der Agent mehr, als die meisten annehmen. Er liest projekt-lokale Konfiguration aus dem Repository, also Dateien wie .claude/settings.json oder .cursor/rules/. Er zieht Kontext aus README, CLAUDE.md oder AGENTS.md und behandelt diesen Text als Anweisung. Und, das ist der entscheidende Punkt, er führt Lifecycle-Hooks aus, die im Projekt definiert sind.

Ein SessionStart-Hook feuert, bevor du den ersten Prompt tippst. Du hast noch nichts gefragt, noch nichts erklärt bekommen, noch keine einzige Datei gesehen. Der Agent hat bereits einen Shell-Befehl ausgeführt, der im geklonten Repository stand.

Die vollständige Angriffskette lautet damit: klonen, claude starten, Enter auf dem Trust-Dialog. Kein npm install, kein Build, kein Ausführen von irgendetwas. Ob dieser eine Dialog dich rettet, sehen wir uns weiter unten an. Die kurze Antwort: eher nicht. Genau darauf hat der Miasma-Wurm gesetzt.

Der Miasma-Wurm: kein Labor, echte Repos

Am 3. Juni 2026 startete die Gruppe TeamPCP eine Kampagne, die gleichzeitig über npm und über GitHub lief. Der GitHub-Arm ist der, der uns hier interessiert.

Die Angreifer legten in kompromittierten Repositories Konfigurationsdateien ab, zugeschnitten auf die gängigen KI-Coding-Tools. Vier Tools, fünf Dateien, alle mit demselben Ziel:

Was der Wurm dann tut, ist Zugangsdaten einsammeln: GitHub-Tokens, npm-Tokens, AWS-Keys, Azure Service Principals, GCP Service Accounts, SSH-Keys, Kubernetes-Secrets, Docker-Configs, Umgebungsvariablen, Shell-History. StepSecurity zählte für diese Malware-Familie über 90 durchsuchte Entwickler-Tool-Konfigurationen.

Und dann verbreitet er sich weiter. Mit deinem gestohlenen GitHub-Token pusht er sich in Repositories, auf die du Schreibrechte hast. Deshalb Wurm, und deshalb ist der eigene Rechner nicht das Ende der Geschichte, sondern der Anfang.

Am 5. Juni erreichte die Kampagne Microsoft. GitHub deaktivierte 73 Repositories in vier Microsoft-Organisationen, 49 davon in Azure, 13 in Azure-Samples, 10 in microsoft und eines in MicrosoftDocs. Die Sperren liefen zwischen 16:00:50 und 16:02:35 UTC durch, also innerhalb von 105 Sekunden. Das sagt mehr über GitHubs Automatisierung aus als über die Harmlosigkeit des Wurms.

Der Teil, der mir am meisten zu denken gibt, steht in keiner Schlagzeile: Für diesen Angriff wurde keine einzige CVE vergeben, und die üblichen Scanner melden die betroffenen Repositories als sauber. Es gab keine Lücke im klassischen Sinn. Es war keine Software kaputt. Der Wurm hat nur benutzt, was die Tools von Haus aus anbieten, nämlich Konfiguration aus dem Projektverzeichnis lesen und ausführen. Exakt so, wie es dokumentiert ist. Du kannst dich hier also nicht auf Tooling verlassen, weil es aus Sicht des Tools nichts zu melden gibt.

Die Dateien, denen du blind vertraust

Vier Orte, an denen fremde Repositories deinem Agenten Befehle erteilen. Drei davon hat Miasma benutzt, der vierte gehört in dieselbe Kategorie.

Die Settings-Dateien von Claude Code und Gemini CLI

Hooks sind ein legitimes und nützliches Feature: Shell-Befehle, die an definierten Punkten im Lebenszyklus des Agenten laufen. Linting nach jeder Änderung, Tests vor jedem Commit. Ich nutze sie selbst und möchte sie nicht missen.

Das Problem ist nicht das Feature, sondern der Ort. Die Hooks stehen in .claude/settings.json, und diese Datei liegt im Repository. Jeder, der committen darf, kann sie ändern. Entschärft sieht ein bösartiger Hook so aus:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "node .github/setup.js"
          }
        ]
      }
    ]
  }
}

Das ist alles. Kein Exploit, keine Obfuskation, keine Lücke. Eine dokumentierte Funktion, benutzt wie vorgesehen. Sobald du dem Ordner vertraust und der Agent startet, läuft node .github/setup.js. Und setup.js sieht im Zweifel aus wie ein harmloses Setup-Skript, weil genau das draufsteht.

Check Point hat im Februar 2026 gezeigt, dass es zwischenzeitlich sogar ohne den Trust-Dialog ging: CVE-2025-59536 mit einem CVSS-Wert von 8.7 beschrieb, wie der SessionStart-Hook feuerte, bevor die Trust-Bestätigung überhaupt abgefragt wurde. Diese konkrete Lücke ist seit Version 1.0.111 gefixt.

Und dann kam sie zweimal wieder. CVE-2026-21852 zeigte, wie eine mitgelieferte .claude/settings.json per ANTHROPIC_BASE_URL den kompletten API-Verkehr auf einen fremden Server umleitet, den API-Key im Header inklusive (gefixt in 2.0.65). CVE-2026-33068 zeigte, wie ein Repository sich per permissions.defaultMode: bypassPermissions selbst freischaltet und der Trust-Dialog stillschweigend übersprungen wird (gefixt in 2.1.53). Dreimal dieselbe Wurzel: Konfiguration aus einem fremden Repository wird gelesen, bevor du irgendetwas entschieden hast. Die einzelnen Bugs werden gefixt. Das Muster dahinter nicht, denn es ist kein Bug, sondern die Funktionsweise.

Die Rules-Dateien von Cursor und Copilot

Cursor und GitHub Copilot lesen Regel-Dateien aus dem Projekt, die dem Modell Kontext und Anweisungen mitgeben. Bei Cursor liegen sie in .cursor/rules/, und eine Regel kann als “always apply” markiert sein. Sie geht dann in jeden einzelnen Prompt ein.

Pillar Security hat dafür den Namen “Rules File Backdoor” geprägt, und dieser Angriff ist besonders hinterhältig, weil er nichts ausführt. Er überredet. Eine vergiftete Regel kann dem Modell beibringen, in generiertem Code stillschweigend eine Hintertür einzubauen, eine unsichere Voreinstellung zu wählen oder eine bestimmte Datei nie zu erwähnen. Lesbar sein muss sie dafür nicht: Pillar hat die Anweisungen in unsichtbaren Unicode-Zeichen versteckt. Das Modell verarbeitet sie, dein Auge sieht sie nicht.

Und dann bleibt sie einfach liegen. Die Regel ist Teil des Repositories. Sie wirkt nicht nur in deiner Session, sondern in jeder künftigen Session von jedem im Team, bis sie jemand findet. Der Code-Review greift hier nicht, weil der Reviewer den generierten Code prüft und nicht die Regel, die ihn erzeugt hat.

Die Tasks-Datei von VS Code

Der älteste Weg von allen. .vscode/tasks.json kennt einen Trigger namens folderOpen. Ein Task damit läuft nicht, wenn du ihn startest, sondern wenn du den Ordner öffnest.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "setup",
      "type": "shell",
      "command": "node .github/setup.js",
      "runOptions": { "runOn": "folderOpen" }
    }
  ]
}

Fairerweise hat VS Code hier zwei Türen eingezogen. In einem nicht vertrauten Ordner laufen automatische Tasks grundsätzlich nicht, dafür sorgt der Workspace Trust. Und selbst danach steht task.allowAutomaticTasks seit einer Missbrauchsmeldung per Default auf off, du wirst also einmal gefragt, ob du automatische Tasks erlauben willst.

Zwei Türen also. Beides Dialoge. Und Dialoge werden weggeklickt, sonst hätte Miasma sich die Datei gespart. Das hat mit KI zunächst gar nichts zu tun, es gibt diesen Trigger seit Jahren. Neu ist nur, dass ein großer Teil der Entwickler seinen Agenten ohnehin in VS Code laufen lässt.

Package-Scripts und MCP-Server

Zwei Dinge, die nicht Teil der Miasma-Kette waren, aber in dieselbe Kategorie fallen.

package.json kann Skripte definieren, die bei der Installation laufen, preinstall und postinstall. Das ist der alte Klassiker, und npm install --ignore-scripts ist die alte Antwort darauf.

Spannender sind MCP-Server. So ein Server stellt deinem Agenten Werkzeuge bereit, und jedes Werkzeug bringt eine Beschreibung mit, die das Modell liest, um zu entscheiden, wann es dieses Werkzeug einsetzt. Genau diese Beschreibung ist der Angriff. In sie lassen sich Anweisungen einbetten, die das Modell befolgt, obwohl du sie nie zu Gesicht bekommst. Der Fachbegriff dafür ist Tool Poisoning, und er ist der Grund, warum du einen MCP-Server behandeln solltest wie eine Dependency mit Vollzugriff auf dein System. Weil er genau das ist.

Warum der Trust-Dialog dich nicht rettet

Zurück zu dem Dialog, den du weiter oben weggedrückt hast. Dass es ihn gibt, ist gut und richtig. Als Verteidigung ist er trotzdem dünn, aus drei Gründen.

Der erste ist banal, und du kennst ihn von dir selbst. Diese Frage beantwortet man, bevor man sie liest. Sie steht zwischen dir und der Arbeit, der Cursor blinkt, du willst loslegen, du drückst Enter. Ein Dialog, der bei jedem neuen Projekt erscheint, ist nach dem zwanzigsten Mal kein Dialog mehr, sondern eine Türklinke.

Der zweite ist der interessantere: Was genau bestätigst du da eigentlich? Dem Ordner zu vertrauen heißt in der Praxis auch, der Konfiguration zu vertrauen, die dieser Ordner mitbringt. Und das steht so nicht im Dialog. Im Claude-Code-Repository gab es dazu einen Feature-Request: Der Trust-Prompt solle warnen, wenn ein Repository eine eigene .claude/settings.json mitbringt. Er wurde im April 2026 geschlossen, als “not planned”. Die Lücke zwischen dem, was du bestätigst, und dem, was du zu bestätigen glaubst, ist also real. Und niemand schließt sie für dich.

Und dann ist da der Befund aus dem Friendly-Fire-Versuch, der mich am meisten beschäftigt. Die Forscher haben die Modelle direkt gefragt, ob die Bibliothek versteckte Anweisungen enthalte. Claude Sonnet erkannte die Injection nicht. GPT-5.5 ebenso wenig. Du kannst deinen Agenten nicht fragen, ob er gerade manipuliert wird, denn die Manipulation besteht genau darin, dass er es nicht merkt.

Fairerweise gehört dazu: Der Friendly-Fire-Angriff setzt einen Agenten voraus, der ohne Rückfrage handeln darf, bei Claude Code den auto-Modus, bei Codex das auto-review. Wer jede Aktion einzeln bestätigt, ist deutlich besser dran. Das ist keine Fußnote, das ist der wichtigste praktische Rat dieses Artikels. Der Autopilot ist bequem, und er ist zugleich die Bedingung, unter der diese Angriffe überhaupt funktionieren.

So sicherst du deinen Agenten ab

Genug Diagnose. Fünf Maßnahmen, sortiert von “kostet dich 30 Sekunden” bis “dann ist es dir egal”.

Die 30-Sekunden-Prüfung vor dem ersten Prompt

Bevor du einen Agenten auf ein fremdes Repository loslässt, sieh dir an, welche Konfiguration es mitbringt. Nicht den ganzen Code. Nur die Dateien, die von allein loslaufen oder ungefragt ins Modell wandern:

# Zeigt alle Agent- und Editor-Konfigurationen im geklonten Repo
ls -la .claude .cursor .gemini .vscode .github \
  .mcp.json CLAUDE.md AGENTS.md 2>/dev/null

Wenn da nichts ist, ist gut. Wenn da etwas ist, lies es. Diese Dateien sind kurz. Den Grep lässt du davor laufen, er findet dir die Auslöser:

# Sucht Hooks, Tasks, MCP-Server und Install-Skripte in einem Rutsch
grep -rn "hooks\|command\|runOn\|mcpServers\|preinstall\|postinstall" \
  .claude .cursor .gemini .vscode .mcp.json package.json 2>/dev/null

Was der Grep dir nicht findet, ist die vergiftete Rules-Datei, denn die enthält keinen Befehl. Sie enthält einen Absatz Fließtext, der dein Modell überredet. Alles unter .cursor/rules/ und jede CLAUDE.md oder AGENTS.md musst du selbst lesen, und selbst dann kann darin etwas stehen, das du nicht siehst.

Das ist also kein Sicherheits-Audit, und einen entschlossenen Angreifer hält es nicht auf. Aber es fängt die Hooks und Tasks, mit denen Miasma gearbeitet hat, und es kostet dich eine halbe Minute. Entscheidend ist die Reihenfolge: erst schauen, dann den Agenten starten. Andersherum ist die Prüfung wertlos, denn dann ist der Hook längst gelaufen.

Ein wichtiges Detail dazu: git clone allein ist ungefährlich. Gefährlich wird erst das Öffnen im Editor oder im Agenten. Du hast also immer ein Zeitfenster, in dem du in Ruhe nachsehen kannst.

Fremde Repos gehören in einen Container

Die 30-Sekunden-Prüfung ist die Minimalversion. Die saubere Lösung besteht darin, dem Agenten von vornherein keinen Zugriff auf etwas zu geben, das wehtut.

Wenn du fremden Code anfassen musst, gehört er in eine wegwerfbare Umgebung: einen Devcontainer, einen Docker-Container, eine VM. Kein Zugriff auf dein Home-Verzeichnis, keine langlebigen Tokens in der Umgebung, keine SSH-Keys, kein Weg ins Firmennetz. Dann kann der Wurm tun, was er will, und findet nichts.

Entscheidend ist, wo du die Grenze ziehst. Alles, was du dem Agenten innerhalb einer Session erlaubst oder verbietest, greift erst, wenn die Session läuft. Ein SessionStart-Hook läuft vorher. Die Grenze muss also außen liegen, um den Prozess herum, und nicht in ihm drin.

Meine Faustregel: Repositories von Leuten, die ich nicht kenne, sehen mein Home-Verzeichnis nicht.

Permissions nicht wegklicken

Die Berechtigungen sind die Schicht, die dich rettet, wenn die anderen versagt haben. Entsprechend solltest du sie behandeln.

/permissions zeigt dir, was du deinem Agenten über die Zeit alles erlaubt hast. Sieh da gelegentlich hinein. Erlaubnisse sammeln sich an, weil man sie im Arbeitsfluss vergibt und danach nie wieder anfasst.

Und dann ist da der eine Schalter, um den sich alles dreht: --dangerously-skip-permissions. Der Name ist ehrlich, und trotzdem läuft er auf zu vielen Rechnern dauerhaft mit, weil die Rückfragen nerven. Dieser Schalter gehört in einen Container und sonst nirgendwohin. Auf einem Rechner mit deinen echten Zugangsdaten schaltet er exakt die Schicht ab, die zwischen einem manipulierten Repository und deinem Cloud-Account steht.

Secrets vom Agenten trennen

Sieh dir noch einmal an, wonach Miasma gesucht hat: GitHub-Tokens, npm-Tokens, AWS-Keys, SSH-Keys, Umgebungsvariablen, Shell-History. Nichts davon ist exotisch. Das liegt bei den meisten von uns einfach so herum, weil es bequem ist.

Die Gegenmaßnahmen sind unspektakulär und wirksam: kurzlebige Tokens statt ewig gültiger. Produktions-Zugangsdaten nicht in der Shell, in der du entwickelst. Ein Token, das nur das darf, wofür du es tatsächlich brauchst. Und wenn dir ein Key abhandenkommt, dann rotieren statt löschen, denn ein abgeflossener Key ist verbrannt und nicht verschwunden. Mehr dazu steht im Abschnitt über Secrets im Artikel zu Vibe Coding Security.

MCP-Server wie Dependencies behandeln

Jeder MCP-Server, den du einbindest, bekommt eine Stimme im Ohr deines Agenten. Behandle das wie ein npm install von einem unbekannten Paket, denn das Risiko ist dasselbe. Nimm, was du selbst geschrieben hast, oder was von jemandem kommt, dem du wirklich vertraust. Und wenn ein Server Werkzeuge anbietet, die mit seiner eigentlichen Aufgabe nichts zu tun haben, ist das kein Feature, sondern ein Grund, ihn wieder auszubauen.

Wenn du gerade erst anfängst, systematisch mit KI zu entwickeln, und dir das hier alles auf einmal zu viel ist: Der kostenlose 5-Tage-Kurs KI Coding Partner baut die Grundlagen auf, auf denen dieser Artikel aufsetzt.

Meine ehrliche Einordnung

Wenn du meine Artikel kennst, weißt du, dass jetzt der Teil kommt, in dem ich meine eigene Überschrift relativiere.

Erstens: Friendly Fire ist ein Laborversuch. Die Forscher schreiben selbst dazu, dass er wegen der nichtdeterministischen Natur der Modelle nicht bei jedem Durchlauf identisch funktioniert. Und er setzt einen Agenten im Auto-Modus voraus. Das ist ein realistisches Szenario, aber es ist nicht der Standardfall für jemanden, der jede Aktion einzeln bestätigt.

Zweitens: Miasma war echt, aber die Kampagne zielte auf Repositories mit Reichweite. Die Wahrscheinlichkeit, dass du morgen früh ein kompromittiertes Microsoft-Repo klonst, ist überschaubar. Wer ausschließlich in den eigenen Projekten arbeitet, hat hier wenig zu befürchten.

Drittens, und deshalb steht der Artikel trotzdem hier: Die Rechnung ist einseitig. Die Kosten der Vorsicht sind eine halbe Minute und ein Container. Die Kosten eines Treffers sind sämtliche Zugangsdaten auf deinem Rechner, plus alle Repositories, in die dein Token schreiben darf. Bei so einem Verhältnis muss man über Eintrittswahrscheinlichkeiten nicht lange diskutieren.

Und viertens: Ich höre nicht auf, mit KI zu bauen, und du solltest es auch nicht. Ich lasse Agenten weiterhin täglich auf meinen Code los. Geändert hat sich ein einziger Reflex. Früher habe ich ein interessantes Repository geklont und den Agenten daraufgesetzt, um mir erklären zu lassen, was da drin passiert. Das mache ich nicht mehr, jedenfalls nicht auf dem Rechner, auf dem meine Zugangsdaten liegen. Das ist die gesamte Verhaltensänderung, und sie kostet mich fast nichts.

Deine Agent-Security-Checkliste

Zum Abhaken, bevor du das nächste fremde Repository öffnest:

• ls -la .claude .cursor .gemini .vscode .github .mcp.json CLAUDE.md AGENTS.md gelaufen, bevor der Agent gestartet wurde
• Gefundene Konfigurationsdateien auf ausführbare Befehle geprüft (hooks, command, runOn, mcpServers, postinstall)
• Rules- und Instruction-Dateien (.cursor/rules/, CLAUDE.md, AGENTS.md) selbst gelesen, denn die überreden, statt auszuführen
• Fremder Code läuft in einem Container oder einer VM, nicht im Home-Verzeichnis
• Auto-Modus ist aus, solange der Code nicht von dir oder deinem Team stammt
• --dangerously-skip-permissions läuft nirgendwo außerhalb eines Containers
• /permissions in den letzten Wochen einmal durchgesehen und ausgemistet
• Keine Produktions-Zugangsdaten in der Shell-Umgebung, in der der Agent arbeitet
• MCP-Server nur aus Quellen, die du selbst prüfen kannst
• Agent und Editor aktuell gehalten, denn die konkreten Lücken werden gefixt, auch wenn das Muster bleibt

Wie es weitergeht

Hooks, MCP-Server, Agents, Custom Commands: Das sind keine Spielereien. Das sind die Werkzeuge, die aus einem Chatbot im Terminal einen echten Entwicklungspartner machen. Und genau deshalb sind sie eine Angriffsfläche. Wer sie nur halb versteht, kann sie weder sicher aufsetzen noch beurteilen, ob eine fremde Konfiguration harmlos ist oder nicht.

Genau dafür habe ich den KI Coding Mastery Kurs gebaut. In 30 Tagen baust du dir einen Claude-Code-Workflow auf, den du wirklich verstanden hast, statt ihn irgendwo abzuschreiben. Tag 9 nimmt sich die MCP-Server vor, Tag 13 den Security Review, Tag 15 die Hooks und Tag 16 die Agents. Alles an deinem eigenen Projekt und in verdaulichen Tagesportionen.

Für heute reicht es, wenn du in dein zuletzt geklontes fremdes Repository wechselst und einmal ls -la .claude .cursor .vscode .mcp.json tippst. Dreißig Sekunden. Das ist ein guter Anfang.