Claude Code läuft im Terminal, stellt aber Anforderungen an Laufzeitabhängigkeiten, Verzeichnisrechte, die Ablage von Schlüsseln und Unternehmens-Proxys. Dieser Leitfaden erklärt in praktischer Reihenfolge, was lokal vorbereitet werden muss und wie Teams Konfigurationen gemeinsam nutzen können.
Claude Code ist ein Tool für das Terminal. Nach der Installation genügt ein einzelner Befehl, deshalb konzentrieren sich viele zuerst nur auf das Netzwerk. In der Praxis liegen die häufigeren Stolpersteine woanders: Passt die Laufzeitversion, hat das Projektverzeichnis Schreibrechte, wo liegen die Schlüssel, wie läuft der Unternehmens-Proxy und wie teilt das Team eine gemeinsame Konfiguration?
Laufzeitumgebung und Abhängigkeiten zuerst abstimmen
Prüfe zunächst in der offiziellen Dokumentation, welche Laufzeitversion aktuell verlangt wird, und installiere genau diese. Verwende nicht versuchsweise eine Version, die erst seit wenigen Tagen veröffentlicht ist. Beim Paketmanager sollte das Team einheitlich bleiben: npm, pnpm und yarn zu mischen führt schnell zu Konflikten zwischen Lockdateien. git und grundlegende Kommandozeilenwerkzeuge sind Pflicht, weil solche Tools Repositorys lesen, Befehle ausführen und Tests starten müssen. Fehlt ein Teil, treten sofort Fehler auf.
Teste nach der Installation zunächst in einem leeren Verzeichnis drei Dinge: Dateien lesen, Dateien ändern und Tests ausführen. In einem kleinen Verzeichnis werden Umgebungsprobleme schnell sichtbar; mitten im Produktivcode ist die Fehlersuche deutlich aufwendiger.
Projektverzeichnis, Berechtigungen und Grenzen
Starte das Tool nicht im Benutzerverzeichnis oder direkt im Stammverzeichnis der gesamten Festplatte. Gib ihm ein klar definiertes Repository-Stammverzeichnis und beschränke Lese- und Schreibzugriffe auf das Projekt. Wenn ausnahmsweise ein größerer Bereich nötig ist, erteile dafür eine einmalige Freigabe statt dauerhaften Vollzugriff.
Prüfe vor einem Commit die .gitignore. Lokal erzeugte Caches, Logs und temporäre Skripte gehören nicht ins Repository. In Teams entstehen die heikelsten Probleme oft nicht durch fehlerhaften Code, sondern dadurch, dass jemand versehentlich sensible Dateien aus dem lokalen Debugging eincheckt.
Schlüssel und Zugangsdaten ablegen
API-Keys, Zugriffstoken und ähnliche Geheimnisse gehören in Umgebungsvariablen oder die Schlüsselverwaltung des Betriebssystems, nicht in Quellcode, Konfigurationsdateien oder Skriptkommentare. Auch .env gehört in die .gitignore; im Repository sollte nur eine Beispieldatei bleiben, die die Bedeutung der Felder erklärt.
Trenne persönliche von gemeinsam genutzten Zugangsdaten. Wenn mehrere Personen denselben Key verwenden, lässt sich bei Problemen nicht nachvollziehen, wer ihn benutzt hat. Lege den Rotationsrhythmus vorher fest: regelmäßig wechseln, am Tag eines Austritts wechseln und bei Verdacht auf ein Leck sofort wechseln. Wird ein Leck entdeckt, zuerst widerrufen und dann untersuchen; Logs nicht zuerst löschen.
Zusammenspiel mit Unternehmens-Proxy und Netzwerk
In Firmennetzen liegt das Problem bei solchen Tools meist nicht darin, ob eine Verbindung möglich ist, sondern bei Proxy und Zertifikaten. Führt ein Unternehmens-Gateway TLS-Interception durch, kann das Tool wegen einer nicht vertrauenswürdigen Zertifikatskette direkt abbrechen. Fordere in diesem Fall bei der IT das interne Root-Zertifikat an und installiere es am richtigen Vertrauensort, statt die Prüfung vorübergehend abzuschalten.
Der Anmeldevorgang öffnet einen Browser. Deshalb sollten Kommandozeile und Browser möglichst denselben Ausgang verwenden, und dieser Ausgang sollte fest, stabil und kontrollierbar sein. Fehlt eine dieser Eigenschaften, kommt es leicht zu wiederholten Anmeldungen oder CAPTCHA-Prüfungen. Häufige Knotenwechsel lösen eher Prüfungen aus als ein fester Knoten, weil Letzterer eher wie ein dauerhaft genutzter Zugang wirkt.
Ob der Ausgang wirklich verwendet wird, lässt sich direkt prüfen: Lass die Kommandozeile mit Proxy-Parameter einmal eine IP-Abfrage ausführen.
curl -x http://127.0.0.1:7897 https://ipinfo.io
Die angezeigte Adresse sollte der erwarteten entsprechen. Auch Zeitzone und Sprache des Browsers sollten zur Region des Ausgangs passen; vermeide beispielsweise eine Kombination aus nordamerikanischem Ausgang und UTC+8-Einstellungen.
Konfigurationen im Team teilen
Teilbar ist die Struktur, nicht der Schlüssel. Lege Arbeitsverzeichnis-Konventionen, Proxy-Routing-Regeln, erlaubte Befehlsbereiche und Vorgaben zum Codestil in einer versionierbaren Konfigurationsdatei im Repository ab. Die Schlüssel werden auf jedem Rechner separat über Umgebungsvariablen injiziert.
Neue Teammitglieder können dann der Dokumentation folgen und direkt starten, ohne jede Person einzeln fragen zu müssen. Wenn im Team mehrere Identitäten oder Umgebungen parallel existieren, kann PurpleMark außerdem den Browserzustand jeder Umgebung festhalten, sodass später nachvollziehbar bleibt, in welcher Umgebung ein bestimmter Login stattgefunden hat.
Abschluss
Wenn solche Tools Probleme machen, liegt es häufig nicht an einem eigenen Bug, sondern an nicht abgestimmten Voraussetzungen. Laufzeit und Abhängigkeiten, Verzeichnisrechte, Schlüsselablage, Proxy-Ausgang und gemeinsame Konfiguration: Wer diese fünf Punkte in einem kleinen Projekt sauber einrichtet, spart später viel wiederholte Fehlersuche.
