zhaoJians Tech-Notizen

Claude Code-Konfiguration (CLAUDE.md, Skills, Plugins, MCP) mit cclayer zwischen mehreren Rechnern synchronisieren und Git-Identitäten pro Team trennen

Technologie ~10046 Wörter · 26 Min. Lesezeit - Aufrufe

Wer Claude Code eine Weile benutzt, sammelt unter ~/.claude einiges an: die globale CLAUDE.md, diverse Rules, Skills, Hooks, Berechtigungen und Plugins in settings.json und dazu einen ganzen Haufen MCP-Server. Ich nutze Claude Code auf mehreren Rechnern, und auf jedem musste ich alles neu einrichten. Ändere ich auf einem Rechner eine Regel, muss ich sie auf den anderen von Hand nachziehen, und mit der Zeit passen die Konfigurationen nicht mehr zusammen.

Noch lästiger wird es, weil meine Projekte von verschiedenen Teams kommen. Jedes Team hat eine andere Git-Identität (Name, E-Mail), manche Teams haben eigene Regeln und Hooks. Die sollen nur in den Projekten dieses Teams gelten, nicht in andere Projekte rutschen, und erst recht soll keine Firmen-E-Mail in meinen eigenen Open-Source-Repositorys landen.

~/.claude einfach in ein Git-Repository zu werfen funktioniert auch nicht: Darin liegen Login-Status, Sitzungsverlauf und lokale Berechtigungen, und die Team-Sachen dürfen nicht in ein öffentliches Repository. Deshalb habe ich cclayer geschrieben, genau für dieses Problem.

Was ist cclayer

cclayer teilt die Claude Code-Konfiguration in zwei Arten von „Schichten“ (Layern) auf:

  • Basisschicht: alles, was auf jedem Rechner gleich ist: CLAUDE.md, rules/, skills/, output-styles/, agents/, Hook-Skripte, die gemeinsamen Schlüssel aus settings.json, die Liste der Plugins und Marketplaces und die MCP-Definitionen. Darin steckt keinerlei Identitätsinformation, sie kann also in ein öffentliches Repository.
  • Overlay-Schicht: eine pro Team. Sie enthält die Git-Identität des Teams, Hooks, Regeln für Repository-Adressen (zum Beispiel github.com/acme-inc/*) sowie die .claude/settings.local.json und CLAUDE.local.md, die in diese Projekte geschrieben werden. Eine Overlay-Schicht wirkt nur in passenden Projekten und schreibt nichts nach ~/.claude.

Jeder Rechner holt sich nur die Basisschicht plus die Overlays, die er braucht. cclayer apply verteilt alles mit einem Befehl, cclayer push schickt lokale Änderungen mit einem Befehl zurück.

Eine Schicht kann ein Git-Repository sein oder einfach ein Verzeichnis in einem synchronisierten Cloud-Speicher-Ordner. Wer Git nicht anfassen will, kommt also auch ohne aus.

Installation

Unter macOS mit Homebrew:

Terminal window
brew install --cask zhaojiannet/tap/cclayer

Später aktualisieren:

Terminal window
brew upgrade --cask cclayer

Für Linux und Windows gibt es die Binärdateien auf der Releases-Seite. Git muss installiert sein; für die Schritte mit Plugins und MCP braucht man Claude Code 2.1.288 oder neuer.

Der einfachste Fall: eine Person, mehrere Rechner

Wenn es keine Teams zu trennen gibt, reicht eine Basisschicht.

Der erste Rechner

Terminal window
cclayer setup

setup ist eine Vollbild-Oberfläche zur Konfiguration. Links stehen die Schichten und die lokalen Einstellungen, rechts die Beschreibung des ausgewählten Eintrags und die änderbaren Felder. Bevor man auf Speichern drückt, wird keine einzige Datei geschrieben. Die Oberfläche gibt es auf vereinfachtem Chinesisch, Englisch und Japanisch, standardmäßig folgt sie der Systemsprache.

Screenshot der Vollbild-Konfigurationsoberfläche von cclayer setup: links Einstellungen wie Basisschicht, Projektverzeichnis, lokaler Klon-Speicherort und automatisches Pullen, rechts die Beschreibung des ausgewählten Eintrags, unten die Schaltflächen zum Speichern und Anwenden, nur Speichern und Beenden

Ausfüllen muss man nur zwei Felder:

  1. Basisschicht: ein Verzeichnis (zum Beispiel ~/Dropbox/cclayer/base im Cloud-Speicher) oder die Adresse eines privaten Git-Repositorys. Existiert das Verzeichnis noch nicht, wird beim Speichern automatisch eine Start-layer.toml angelegt.
  2. Projektverzeichnis: das Verzeichnis mit dem Code, zum Beispiel ~/Projects.

„Save and apply“ wählen und dann die vorhandene Konfiguration dieses Rechners in die Schicht übernehmen:

Terminal window
cclayer capture --add CLAUDE.md --add rules/ --add skills/

Die Pfade sind relativ zu ~/.claude. Bevor eine Datei übernommen wird, wird sie geprüft: Schlüssel, E-Mail-Adressen oder absolute Pfade ins eigene Home-Verzeichnis werden abgefangen, und man bekommt die Zeile gesagt. Wenn man die Schicht nur selbst nutzt und sie an einem privaten Ort liegt, kann man in layer.toml unter [layer] die Zeile private = true ergänzen, dann werden E-Mail-Adressen nicht mehr blockiert.

Weitere Rechner

cclayer installieren, ebenfalls cclayer setup ausführen, als Basisschicht dieselbe Adresse eintragen, speichern und anwenden, und schon ist die Konfiguration vom ersten Rechner da. Dateien, die lokal schon existieren, aber einen anderen Inhalt haben, werden aufgelistet und man wird gefragt, ob sie überschrieben werden sollen. Vor dem Überschreiben werden die alten Dateien nach ~/.local/state/cclayer/backups/ gesichert.

Tägliches Synchronisieren

Wenn die Schicht ein Git-Repository ist:

Terminal window
cclayer push # Hochladen: lokale Änderungen einsammeln, Inhalt zum Commit anzeigen, nach Bestätigung committen und pushen
cclayer apply --pull # Herunterladen: neueste Schichten pullen und lokal anwenden

Wenn die Schicht ein Cloud-Speicher-Ordner ist, kümmert sich der Cloud-Dienst um die Synchronisation. Nach Änderungen cclayer capture ausführen, auf dem anderen Rechner cclayer apply, fertig.

Man kann außerdem den folgenden SessionStart-Hook in die claude/settings.json der Basisschicht legen und in setup „Auto pull“ einschalten. Dann wird bei jeder neuen Claude Code-Sitzung automatisch gepullt und angewendet:

{
"hooks": {
"SessionStart": [{
"matcher": "startup",
"hooks": [{ "type": "command", "command": "command -v cclayer >/dev/null && cclayer apply --hook || true" }]
}]
}
}

Unterschiedliche Git-Identitäten für verschiedene Teams

Das ist der Hauptgrund, warum ich cclayer geschrieben habe. Zuerst legt man für das Team ein privates Repository an und legt in dessen Wurzel eine layer.toml mit der Identität und den passenden Repositorys:

[layer]
name = "acme"
kind = "overlay"
[identity]
name = "Full Name"
email = "me@acme.example"
[[match]]
remote = "github.com/acme-inc/*"

Dann fügt man auf den Rechnern, die es brauchen, diese Overlay-Schicht hinzu. cclayer fragt, wie die Zugangsdaten für das Repository eingerichtet werden sollen, klont es und prüft es einmal durch:

Terminal window
cclayer layer add acme git@github.com:you/cclayer-acme.git

Nach apply hängt cclayer ans Ende von ~/.gitconfig einen include-Block an. Über Gits includeIf "hasconfig:remote.*.url:..." gilt diese Identität nur in Repositorys, deren Remote-Adresse zu github.com/acme-inc/* passt. Der bisherige Inhalt von ~/.gitconfig bleibt unangetastet. Bleibt die Standardidentität (default_identity) leer, verweigert Git in Repositorys, zu denen kein Overlay passt, den Commit. Mit der falschen E-Mail committen passiert dann nicht mehr.

Die Match-Regeln müssen Host und Organisation ausdrücklich nennen und dürfen sie nicht durch Wildcards ersetzen, damit das Overlay eines Teams nicht die Repositorys eines anderen Teams für sich beansprucht.

Wer auch Login, Sitzungen und Prompt-Verlauf von Claude Code pro Team komplett trennen will, kann den Profiles-Modus einschalten. Jede Overlay-Schicht bekommt dann ihr eigenes Konfigurationsverzeichnis ~/.claude-profiles/<Schichtname>, cclayer env gibt das passende CLAUDE_CONFIG_DIR aus, und zusammen mit direnv nutzt jedes Projekt automatisch die richtige Konfiguration.

Sicherheit

Synchronisierte Hooks und Skills werden lokal von Claude Code ausgeführt, deshalb ist cclayer hier eher vorsichtig:

  • Einstellungen wie hooks, statusLine oder enabledPlugins, die Programme ausführen oder Plugins aktivieren, sowie Dateien unter hooks/ und skills/ und ausführbare Dateien werden vor dem Schreiben angezeigt und müssen bestätigt werden. Wurde ein Inhalt einmal bestätigt, fragt cclayer nicht erneut.
  • Bei Git-Konfigurationsschnipseln werden nur gängige Einstellungen wie pull.rebase oder push.default durchgelassen. Schlüssel, die Programme ausführen können, etwa Aliase, core.hooksPath oder credential.helper, funktionieren nur, wenn man der Schicht in der Geräteliste ausdrücklich vertraut.
  • Der Login-Status von Claude Code, history.jsonl und projects/ werden nie in eine Schicht eingelesen, permissions.allow und env bleiben lokal.
  • Symbolische Links sind in Schichten nicht erlaubt, und beim Schreiben von Dateien wird symbolischen Links nicht gefolgt.

Häufige Befehle

BefehlZweck
cclayer setupVollbild-Konfigurationsoberfläche, für die Ersteinrichtung und spätere Änderungen
cclayer applySchichten lokal anwenden, mit --pull vorher pullen
cclayer captureLokale Änderungen in die Schichten zurückschreiben, ohne Commit
cclayer pushNach capture die Schicht-Repositorys committen und pushen
cclayer checkPrüfen, ob in den Schichten etwas steht, das dort nicht hingehört
cclayer statusGit-Status der Schichten und gefundene Projekte
cclayer keys setup <Schicht>Zugangsdaten für das Schicht-Repository auf diesem Rechner einrichten (Deploy Key oder HTTPS-Token)
cclayer layer add <Name> <Adresse>Eine Overlay-Schicht auf diesem Rechner hinzufügen
cclayer leave <Schicht>Eine Schicht von diesem Rechner entfernen und alles löschen, was sie geschrieben hat
cclayer doctorHäufige Probleme mit Claude Code und Git prüfen

Ausführlichere Anleitungen, unter anderem zum Anlegen der Git-Repositorys, zu Zugangsdaten für private Repositorys und zu häufigen Fragen, stehen im cclayer-Tutorial (auf Englisch).

GitHub-Projekt: https://github.com/zhaojiannet/cclayer

Teilen:

Kommentare