Wer mit Claude Code arbeitet, baut sich über Wochen etwas Wertvolles auf:
Skills, Regeln, Wissen über Kunden und Abläufe. Und all das liegt in genau einem Ordner auf genau einem Rechner. Fällt der aus, ist die Arbeit weg — und ein Kollege kommt ohnehin nicht dran.
Dieser Beitrag zeigt, wie du deinen Agent mit einem privaten GitHub-Repository absicherst, ihn im Team teilbar machst und dabei deine Zugangsdaten zuverlässig draußen hältst.
Lieber zuschauen statt lesen? Das komplette Setup gibt's Schritt für Schritt zum Mitklicken im Video.
Drei Fragen entscheiden, ob das für dich relevant ist:
Die Antwort auf alle drei ist dieselbe und kommt aus der Softwareentwicklung:
ein eigenes Repository. In unserem Fall bei GitHub.
Ein Ordner in einem Cloud-Speicher synchronisiert Dateien. Ein Repository verwaltet Zustände. Es merkt sich, was sich wann geändert hat, es erkennt Konflikte zwischen zwei Rechnern und hilft dir, sie aufzulösen, statt dir stillschweigend eine Version zu überschreiben. Genau das brauchst du, wenn mehrere Menschen oder mehrere Geräte an derselben Arbeitsumgebung arbeiten.
Der zweite Grund ist Struktur. Bei einem Repository entscheidest du pro Datei und pro Ordner, was mitgeht. Und diese Entscheidung ist bei einem KI-Agenten wichtiger als bei fast jedem anderen Projekt — dazu kommen wir gleich.
Private Repositories sind bei GitHub im kostenlosen Plan enthalten. Es gibt also keinen Grund, das aufzuschieben, bis „das Setup fertig" ist.
Registrieren kannst du dich mit Google-Konto, Apple-ID oder E-Mail-Adresse. Danach führt dich die Startseite direkt zur Wahl: ein bestehendes Repository importieren oder ein neues anlegen. Wenn du dort nichts findest, gehst du über die Repository-Übersicht auf New Repository.
Name eingeben, optional eine Beschreibung — und dann kommt der wichtigste Klick des ganzen Setups:
Visibility auf „Private" stellen.
Steht das Repository auf „Public", kann jeder deinen Agent lesen und herunterladen. Nicht theoretisch — praktisch, weil öffentliche Repositories durchsuchbar sind. Nach dem Anlegen lohnt sich die Kontrolle: in die Settings, ganz nach unten scrollen, bis zur „Danger Zone". Dort steht, ob das Repository privat oder öffentlich ist. Zehn Sekunden, die dir eine unangenehme Woche ersparen.
Jetzt geht es ins Terminal. Unter Windows über die Suche mit cmd, auf dem Mac über Spotlight und „Terminal".
Du brauchst zwei Dinge: Git (die Versionsverwaltung selbst) und die GitHub CLI (das Kommandozeilen-Werkzeug, das deinen Rechner mit deinem GitHub-Konto verbindet).
Ob beides installiert ist, prüfst du mit:
Kommt eine Versionsnummer zurück, ist alles da. Danach die Verbindung herstellen:
Der Dialog stellt vier Fragen. In dieser Reihenfolge:
Danach zeigt dir das Terminal einen kurzen Code. Den fügst du im Browser ein, der sich öffnet — und die Verbindung steht. Kontrollieren kannst du sie jederzeit:
Anschließend lohnt es sich, direkt in Claude Code nachzufragen, ob die Verbindung zum Repository tatsächlich besteht. Der Agent kann das selbst prüfen und dir sagen, woran es hängt, wenn nicht.
Hier trennt sich ein sauberes Setup von einem, das dir später schadet.
In einem gewachsenen Agent-Ordner liegen nämlich nicht nur Skills und Konfiguration, sondern auch Dinge, die niemand außer dir sehen soll.
Bevor du das erste Mal synchronisierst, lässt du dir am besten eine Übersicht über den Ordner geben — welche Verzeichnisse existieren, was liegt drin, wie viele Dateien.
Erst dann entscheidest du. Das Werkzeug dafür heißt .gitignore: eine Datei, in der steht, was das System bewusst ignorieren soll.
Der wichtigste Eintrag ist die .env. In dieser einen Datei liegen alle Zugangsdaten deines Agents: API-Keys, Schlüssel für angebundene Dienste, Passwörter.
Der Agent holt sie sich von dort, wenn er sich irgendwo anmelden muss. Teilst du das Repository mit dem Team, ohne die .env auszuschließen, hast du deine kompletten Zugänge verteilt.
Und das ist nicht nur ein Sicherheitsthema, sondern ein Governance-Thema: Jede Person im Team soll eigene Keys ziehen. Dann kannst du steuern, wer welche Rechte hat und wer auf welche Systeme zugreift. Mit einem geteilten Schlüsselbund kannst du das nicht.
Outputs, Datenbanken und schweres Material bleiben aus einem anderen Grund draußen:
Sie sind persönlich und sie blähen das Repository auf. Was dein Agent produziert, entsteht auf jedem Rechner neu — es muss nicht wandern.
Mehr brauchst du für den Anfang nicht. Sind zwei Rechner im Spiel, prüft das System selbst, ob es Konflikte zwischen den Versionen gibt, und unterstützt dich beim Auflösen.
Nach dem ersten Push schaust du auf GitHub in dein Repository — und siehst dort genau den Ordner, den du auf dem Rechner hast. Minus die Dinge, die du bewusst draußen gelassen hast.
Das Setup oben bringt dich ans Ziel. Diese vier Punkte kommen aus der Praxis danach — sie beantworten die Fragen, die typischerweise in Woche zwei auftauchen.
1. Die .gitignore gehört vor den ersten Commit, nicht danach.
Sie wirkt nur für Dateien, die noch nie mitgeschickt wurden. Ist eine .env bereits einmal hochgeladen worden, reicht der Eintrag nicht — die Datei muss zusätzlich aus der Verfolgung genommen werden:
Und dann gilt: die betroffenen Keys sind offengelegt. Neue Keys erzeugen, alte widerrufen. Deshalb lohnt sich die Minute, die du vor dem ersten Commit in die .gitignore steckst.
2. Lass dir die Ordner-Übersicht geben, bevor du entscheidest.
Ein gewachsener Agent-Ordner hat schnell mehrere Hundert Dateien in Dutzenden Verzeichnissen. Statt zu raten, was drinsteckt, lässt du dir von Claude Code eine Übersicht ausgeben — welche Verzeichnisse es gibt, was darin liegt, wie viele Dateien. Auf dieser Basis entscheidest du bewusst, statt hinterher zu korrigieren.
3. Am zweiten Rechner immer erst ziehen, dann arbeiten.
Die häufigste Ursache für Konflikte ist nicht die Technik, sondern die Reihenfolge. Wer auf dem Laptop loslegt, ohne vorher den Stand aus dem Repository zu holen, arbeitet auf einer veralteten Version. Merksatz: Pull vor dem Start, Commit und Push am Ende.
4. Ein Kollege braucht mehr als nur den Klon.
Er zieht sich das Repository — und hat damit alle Skills, Regeln und Prozesse. Was ihm fehlt, ist genau das, was du bewusst ausgeschlossen hast: seine eigene .env. Plane das ins Onboarding ein, sonst steht der neue Kollege vor einem Agent, der alles kann, aber sich nirgends anmelden darf. Genau so soll es sein — jede Person mit eigenen Zugängen und eigenen Rechten.
Ab diesem Moment ist dein Agent kein Einzelplatz-Werkzeug mehr:
Ein Punkt, der unterschätzt wird: Es macht einen Unterschied, ob du einen großen Agent mit vielen Fähigkeiten pflegst oder viele kleine. Wir fahren bewusst den großen — weil sich Wissen dort sammelt, statt sich zu verteilen. Genau dieser gesammelte Stand ist der Grund, warum ein Repository nicht optional ist.
Das Setup ist kein Projekt. Account anlegen, Repository auf privat, zwei Installationen, eine Verbindung, eine .gitignore, ein Commit, ein Push. Danach läuft es im Hintergrund mit.
Die eine Erkenntnis, die bleibt:
Der wertvollste Teil deines Agents ist nicht die Software, sondern das, was du hineingelegt hast.
Skills, Regeln, Wissen über deine Kunden — das ist über Monate gewachsen und existiert nirgendwo sonst. Ein privates Repository ist der Unterschied zwischen einem Werkzeug, das auf einem Laptop liegt, und einem Firmenwert, der gesichert ist, überall verfügbar und teilbar.
Ein gesicherter Agent ist der Anfang. Wenn du wissen willst, wie ein KI-System aussieht, das deiner Firma gehört und mit ihr wächst, schau mit uns unverbindlich drauf:
