Claude Code im Team einrichten: Installation, Proxy, Kontobindung und zentrale Einstellungen

Im Repository von Anthropic liegt mit .devcontainer/init-firewall.sh eine beispielhafte Freigabeliste (Allowlist) für ausgehende Verbindungen. Sie wurde zuletzt am 27. August 2025 geändert und erlaubt unter anderem registry.npmjs.org und api.anthropic.com. In der aktuellen Netzwerkdokumentation kommen jedoch platform.claude.com, claude.ai und downloads.claude.ai hinzu. Über platform.claude.com werden OAuth-Tokens für Console- und claude.ai-Konten ausgetauscht. Wer das Skript unverändert als Unternehmensfreigabe übernimmt, kann Claude Code über npm installieren, aber nicht zuverlässig anmelden.

Der Installationsbefehl ist deshalb nicht der schwierige Teil. Vor einem Teamrollout müssen Installationsweg und Updatestrategie, Konten und Zugangsdaten, Netzwerkfreigaben sowie verwaltete Einstellungen feststehen.

Diese Entscheidungen lassen sich unterschiedlich leicht korrigieren. Berechtigungen, Updateregeln und Anmeldevorgaben sind über verwaltete Einstellungen und die Geräteverwaltung zentral änderbar, der Installationsweg und die beim ersten Start verwendeten Zugangsdaten nicht. Ohne zentrale Softwareverteilung muss jedes Gerät einzeln nachgezogen werden. Die folgenden Abschnitte sind nach diesem Korrekturaufwand geordnet und enden mit einer Prüfliste.

Welche weiteren betrieblichen Maßnahmen der Einsatz von Coding Agents erfordert, erläutert die Betriebsseite des Coding-Agents-Leitfadens. Die vertragliche Freigabe klärt Claude Code im Team freigeben. Dieser Beitrag behandelt die anschließende Installation, Konfiguration und Verteilung.

Direkt zu den Abschnitten:

• Installation und Updates
• Windows und WSL
• Konten und Zugangsdaten
• Proxy und Netzwerk
• Verwaltete Einstellungen
• Prüfliste für den Rollout

Claude Code installieren: die empfohlenen Befehle für macOS, Linux und Windows

Anthropic empfiehlt in der Setup-Dokumentation die native Installation. Für jede Plattform genügt ein Befehl:

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

:: Windows CMD
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Alternativ gibt es mehrere Paketmanager: Homebrew (brew install --cask claude-code), WinGet (winget install Anthropic.ClaudeCode), die signierten APT-, DNF- und APK-Repositories auf downloads.claude.ai sowie npm (npm install -g @anthropic-ai/claude-code).

Unterstützt werden macOS 13.0 oder neuer, Windows 10 ab Build 1809, Windows Server 2019 oder neuer, Ubuntu 20.04 oder neuer, Debian 10 oder neuer und Alpine 3.19 oder neuer. Erforderlich sind außerdem ein x64- oder ARM64-Prozessor, mindestens 4 GB RAM sowie Bash, Zsh, PowerShell oder CMD. Unter Alpine müssen zusätzlich bash, curl, libgcc, libstdc++ und ripgrep installiert und USE_BUILTIN_RIPGREP=0 gesetzt werden.

Seit Version 2.1.113 benötigt die CLI Node.js nicht mehr zur Laufzeit, sondern wird als native Binärdatei für die jeweilige Plattform ausgeliefert. Node.js 22 oder neuer ist seit Version 2.1.198 nur noch für die Installation über npm nötig.

Beim ersten Aufruf von claude öffnet sich ein Browserfenster zur Anmeldung. Wird stattdessen ein Code angezeigt, geben Sie ihn an der Eingabeaufforderung Paste code here if prompted ein. Laut der Authentifizierungsdokumentation ist die Eingabe des Codes erforderlich, wenn der Browser den lokalen Callback-Server nicht erreicht, etwa unter WSL 2, in SSH-Sitzungen und in Containern.

Die CLI ist damit installiert. Konten und Zugangsdaten, Netzwerkfreigaben und verwaltete Einstellungen sind aber noch nicht geprüft.

Der Installationsweg gibt das Updateverhalten vor

Für den Betrieb ist vor allem entscheidend, ob Updates automatisch eingespielt oder über den vorhandenen Paketmanager verteilt werden.

Für Homebrew und WinGet lassen sich automatische Updates mit CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1 einschalten. Die Linux-Pakete bleiben manuell, weil ihre Upgrade-Befehle erhöhte Rechte erfordern.

Wo sich Software auf verwalteten Geräten nicht unbeaufsichtigt aktualisieren darf, gibt es drei Möglichkeiten, Updates unterschiedlich weit einzuschränken. DISABLE_AUTOUPDATER=1 deaktiviert nur die automatische Updateprüfung. Ein manuelles claude update bleibt möglich. DISABLE_UPDATES=1 deaktiviert zusätzlich manuelle Updates. Über autoUpdatesChannel wird zwischen latest und stable gewählt. Einen Einstellungsschlüssel namens autoUpdates gibt es nicht. Bei Homebrew wird der Kanal stattdessen über den Cask gewählt: claude-code folgt stable, claude-code@latest folgt latest. Bei APT, DNF und APK bestimmt die konfigurierte Repository-URL den Kanal.

DISABLE_AUTOUPDATER und DISABLE_UPDATES werden im env-Block gesetzt. autoUpdatesChannel, requiredMinimumVersion und requiredMaximumVersion sind dagegen eigene Einstellungsschlüssel:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  },
  "autoUpdatesChannel": "stable"
}

Mit requiredMinimumVersion und requiredMaximumVersion lässt sich zentral ein zulässiger Versionsbereich vorgeben. Außerhalb startet Claude Code nicht. Beim nativen Installer lässt sich eine Version schon bei der Installation festschreiben.

Beide Updatestrategien haben Vorteile. Automatische Updates verteilen Fehlerkorrekturen sofort. Ein kontrolliertes Wartungsfenster senkt dagegen das Risiko, dass eine fehlerhafte Version gleichzeitig alle Entwickler trifft. Wer Versionen festschreibt, braucht einen Prozess, der sie regelmäßig prüft und aktualisiert.

Unter macOS und Linux ist die Entscheidung meist einfach. Der native Installer benötigt keine erhöhten Rechte und legt die Binärdatei unter ~/.local/bin/claude ab, die einzelnen Versionen unter ~/.local/share/claude/versions/. In zentral verwalteten Debian- oder RHEL-Umgebungen bietet sich das signierte Repository an, weil Claude Code dann im bestehenden Wartungsfenster mitläuft. Unter Windows ist die Wahl des Installationswegs komplexer.

Hinweis für Teams mit eigenen Startskripten: Vor Version 2.1.207 ersetzte der Auto-Updater ein vorhandenes Startskript unter ~/.local/bin/claude bei jedem Update durch einen eigenen Symlink. Seit Version 2.1.207 bleibt es erhalten.

Warum npm im Teamrollout mehr Voraussetzungen schafft

Seit npm dieselbe Binärdatei wie der native Installer ausliefert, sind die Unterschiede kleiner geworden. npm verlangt aber weiterhin Node.js für die Installation und Zugriff auf registry.npmjs.org. Damit entstehen eine zusätzliche Voraussetzung auf dem Gerät und eine weitere Freigabe in der Firewall.

Die Quellen widersprechen sich: Die Repository-README bezeichnet die npm-Installation als deprecated und nennt im Badge noch Node.js 18, während die Setup-Dokumentation sie ohne Warnhinweis samt Upgrade-Anweisungen aufführt und Node.js 22 voraussetzt. Zuletzt geändert wurde diese README am 12. Januar 2026, weshalb ihr Stand überholt sein dürfte. npm bleibt dokumentiert und wird weiterhin unterstützt, ist aber gegenüber dem nativen Installer nachrangig.

Windows: nativ, WSL 2 oder Desktop-App

Für Projekte mit nativen Windows-Werkzeugketten eignet sich die native Installation. WSL 2 ist sinnvoll, wenn Linux-Toolchains oder die integrierte Sandbox benötigt werden. Die Desktop-App nutzt dieselbe Engine, stellt den Befehl claude im Terminal aber nicht bereit. Dafür ist eine separate CLI-Installation erforderlich. Die native Windows-Version wird in der Setup-Dokumentation ohne Beta- oder Preview-Hinweis geführt.

Die Desktop-App ist eine eigenständige Anwendung und wird deshalb nicht in dieser CLI-Tabelle geführt. Ausschlaggebend für die Sicherheitsentscheidung ist die Sandbox-Unterstützung:

WSL 1 ist nicht als regulär empfohlener Rolloutweg aufgeführt, weil es keine Sandbox unterstützt und von einer dokumentierten Binärdatei-Regression betroffen ist (Einzelheiten weiter unten).

Damit wird der Installationsweg zur Sicherheitsentscheidung. Anthropic dokumentiert, dass die Sandbox in Claude Code integriert ist und unter macOS, Linux und WSL 2 läuft, nicht jedoch unter nativem Windows. Empfohlen wird dort, Claude Code innerhalb einer Distribution unter WSL 2 auszuführen. Andernfalls muss die Absicherung über das Berechtigungsmodell und ergänzende Windows-Kontrollen erfolgen. Windows-ACLs, AppLocker und EDR sind davon unabhängige Schutzmechanismen.

Redaktioneller Nachtrag: Der Beitrag zur Freigabeentscheidung stellt korrekt fest, dass Claude Code nativ unter Windows läuft. Die integrierte Sandbox steht dort jedoch nicht zur Verfügung. Diese Einschränkung muss in die Freigabeentscheidung einfließen.

Git für Windows, Adminrechte und die Ausführungsrichtlinie

Seit Version 2.1.120 setzt die CLI Git für Windows nicht mehr voraus. Ohne Git für Windows verwendet Claude Code das PowerShell-Tool. Mit Git steht zusätzlich das Bash-Tool zur Verfügung. Das PowerShell-Tool wird derzeit auch für Installationen mit Git schrittweise als weitere Option ausgerollt und kann mit CLAUDE_CODE_USE_POWERSHELL_TOOL=1 aktiviert werden. Git-Funktionen und die Diff-Anzeige hängen davon nicht ab. Die Desktop-App setzt Git für Windows weiterhin voraus, weil der Code-Tab ohne Git keine lokalen Sitzungen startet.

Auf verwalteten Windows-Geräten sind zunächst die erforderlichen Rechte zu klären. Der Installer benötigt laut Dokumentation keine Administratorrechte. claude.exe wird unter %USERPROFILE%\.local\bin\ installiert, also in einem Verzeichnis mit bestehendem Schreibzugriff des Benutzers.

Auch die PowerShell-Ausführungsrichtlinie blockiert den empfohlenen Einzeiler nicht. Sie gilt für Skriptdateien, und irm ... | iex führt heruntergeladenen Text direkt aus. Die Meldung running scripts is disabled on this system oder eine PSSecurityException betrifft daher meist die von npm angelegten .ps1-Launcher, nicht den nativen Installer. Abhilfe schafft der Aufruf von npm.cmd und claude.cmd statt der .ps1-Launcher. Als Alternative nennt Anthropic folgende Änderung der benutzerspezifischen Ausführungsrichtlinie:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Der Befehl erfordert keine Administratorrechte, ändert aber eine Sicherheitsrichtlinie und sollte auf verwalteten Geräten mit der IT abgestimmt werden.

Häufiger scheitert die Installation auf Unternehmensgeräten an Netzwerk- und Sicherheitskontrollen. Ein Proxy mit TLS-Inspektion kann den PowerShell-Installer blockieren, wenn das Stammzertifikat der für die TLS-Inspektion eingesetzten Unternehmens-CA im Windows-Zertifikatsspeicher fehlt. PowerShell lädt über .NET herunter und prüft die Zertifikatskette anhand dieses Speichers. Blockierte Sperrlistenabfragen führen zum Fehler CRYPT_E_NO_REVOCATION_CHECK (0x80092012), den die Dokumentation als häufiges Problem hinter Unternehmensfirewalls beschreibt. Ob EDR oder AppLocker Ausnahmen für claude.exe und die davon gestarteten Prozesse benötigen, hängt von der Unternehmensrichtlinie ab.

Wenn claude doctor eine unvollständige Suche als OK meldet

Liegt ein WSL-Projekt unter /mnt/c, greift WSL über die Dateisystemgrenze auf das Windows-Dateisystem zu. Laut Anthropic kann das die Suche verlangsamen und zu weniger Treffern führen.

Problematisch ist, dass claude doctor den Suchstatus trotzdem als OK meldet. Relevante Dateien bleiben dadurch unter Umständen unberücksichtigt, ohne dass das Diagnosewerkzeug einen Fehler anzeigt. Anthropic empfiehlt deshalb, das Projekt in das Linux-Dateisystem zu verschieben, etwa unter /home/, oder Claude Code nativ unter Windows zu verwenden.

WSL 1 ist ein Sonderfall. Es wird in der Setup-Dokumentation weiterhin als Ausweichoption geführt, falls WSL 2 nicht verfügbar ist, unterstützt aber keine Sandbox. Die native Binärdatei kann dort mit cannot execute binary file: Exec format error scheitern. Anthropic nennt die Umstellung auf WSL 2 mit wsl --set-version <DistroName> 2 als sauberste Lösung und dokumentiert für unvermeidbare WSL-1-Umgebungen zusätzlich einen Aufruf über den dynamischen Linker.

Welche Zugangsdaten Claude Code bevorzugt

Claude Code bezieht Zugangsdaten aus sechs Quellen mit fester Priorität. Eine angemeldete Gateway-Sitzung in den Claude-Apps liegt außerhalb dieser Liste und hat Vorrang vor allen sechs Quellen. Ist CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX oder CLAUDE_CODE_USE_FOUNDRY gesetzt, stehen die Zugangsdaten des Cloud-Anbieters ganz oben:

Diese Reihenfolge verursacht einen typischen Rolloutfehler: Ein alter ANTHROPIC_API_KEY im Shell-Profil hat Vorrang vor der Anmeldung am Unternehmenskonto. Meist stammt er laut Dokumentation aus einem früheren Projekt oder von einem früheren Arbeitgeber. Das Symptom ist ein API Error: 400 mit dem Text „This organization has been disabled“. Die Anmeldung mit der Unternehmenslizenz gelingt, der Client arbeitet aber ohne sichtbaren Hinweis weiter mit dem alten Schlüssel.

Der Speicherort hängt vom Betriebssystem ab:

Unter Windows liegen die Zugangsdaten also nicht im Credential Manager, sondern in einer Datei, die nur die Profilrechte schützen.

Für eine automatisierte Bestandsaufnahme gibt claude auth status JSON aus:

claude auth status          # JSON, Exit-Code 0 wenn angemeldet, 1 wenn nicht
claude auth status --text   # lesbare Fassung

Die Ausgabe enthält in Version 2.1.223 unter anderem authMethod, email, orgId, orgName und subscriptionType. So lässt sich geräteübergreifend prüfen, mit welcher Organisation der jeweilige Client arbeitet. Die Feldnamen sind kein dokumentiertes Schema. Ein auswertendes Skript sollte deshalb die Claude-Code-Version mitprüfen. claude doctor gibt dagegen keine Kontoinformationen aus.

Anmeldemethode und erlaubte Organisationen lassen sich zentral vorgeben. forceLoginOrgUUID beschränkt die Anmeldung auf eine oder mehrere Organisationen und erwartet eine Organisations-UUID oder eine Liste davon. forceLoginMethod akzeptiert die Werte claudeai, console und gateway. Sind beide gesetzt und gehören die aktiven Zugangsdaten zu keiner erlaubten Organisation, bricht Claude Code den Start ab. Ein leeres Array blockiert sämtliche Anmeldungen.

Für den Rollout zählen vier Einschränkungen:

1. claude setup-token und /install-github-app berücksichtigen nur forceLoginMethod und können einen Token für eine andere Organisation erzeugen.
2. Cloud-Provider-Sitzungen werden davon nicht blockiert und müssen über die IAM-Richtlinien des jeweiligen Cloud-Anbieters eingeschränkt werden.
3. Servergesteuerte Einstellungen greifen erst nach der ersten Anmeldung. Die zulässige Organisation muss daher vor der ersten Anmeldung über die Geräteverwaltung vorgegeben werden.
4. forceLoginOrgUUID blockiert auch Sitzungen mit ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN oder apiKeyHelper, weil sich deren Organisationszugehörigkeit nicht überprüfen lässt.

Vertragsmodell, Nutzungsdaten und Quellcodeverarbeitung behandelt Claude Code im Team freigeben. Benutzerlizenzen und API-Abrechnung stellt der Kostenvergleich für KI-Coding-Tools gegenüber.

Von privaten auf Unternehmenskonten wechseln

Für einen Kontowechsel sieht die dokumentierte Prozedur eine vollständige Abmeldung und erneute Anmeldung vor. Der Wechsel vom privaten Abonnement zur Unternehmenslizenz erfordert vier Schritte. Drei davon dienen dazu, alte Zugangsdaten und Einstellungen zu entfernen.

1. Mit claude auth logout oder /logout abmelden. Das löscht die gespeicherten OAuth-Zugangsdaten.
2. ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN und CLAUDE_CODE_OAUTH_TOKEN aus den Shell-Profilen entfernen. Betroffen sind ~/.zshrc, ~/.bashrc und ~/.profile, unter Windows zusätzlich das PowerShell-Profil und die Benutzervariablen. Alle drei Variablen haben Vorrang vor der Abo-Anmeldung.
3. Einen konfigurierten apiKeyHelper aus ~/.claude/settings.json entfernen. Auch dieser hat Vorrang vor der Abo-Anmeldung.
4. Mit /login am Unternehmenskonto anmelden und die Kontozuordnung mit claude auth status prüfen.

Eine Neuinstallation ist nicht nötig. Ein Befehl claude uninstall fehlt. Die vollständige Entfernung erfolgt abhängig vom Installationsweg manuell. Zu löschen sind unter macOS und Linux die Datei ~/.local/bin/claude und das Verzeichnis ~/.local/share/claude, unter Windows %USERPROFILE%\.local\bin\claude.exe und %USERPROFILE%\.local\share\claude. Die Konfiguration bleibt dabei erhalten. ~/.claude und ~/.claude.json müssen separat gelöscht werden. Davor warnt die Dokumentation, weil dann Einstellungen, freigegebene Werkzeuge, MCP-Konfiguration und Sitzungsverlauf verloren gehen.

Die VS-Code-Erweiterung, das JetBrains-Plugin und die Desktop-App legen ebenfalls Daten unter ~/.claude/ ab und können das Verzeichnis erneut anlegen, solange sie installiert bleiben. Unter macOS liegen die Zugangsdaten im Schlüsselbund und überstehen das Löschen der genannten Pfade. Ein Verfahren zum direkten Löschen der Schlüsselbunddaten ist nicht dokumentiert. Deshalb sollte zuerst /logout laufen. Erst danach sollten die Dateien gelöscht werden.

Warum private Konten entstehen und was Verbote daran ändern, behandelt Schatten-KI in Entwicklerteams.

Buildagenten und Container ohne Browser

Da Buildagenten meist ohne Browser laufen, scheidet die Anmeldung über den lokalen Callback dort aus. Anthropic dokumentiert drei Zugangswege:

• API-Schlüssel: ANTHROPIC_API_KEY wird im nicht interaktiven Modus mit -p ohne Rückfrage verwendet.
• apiKeyHelper: Ruft kurzlebige Zugangsdaten aus einer zentralen Schlüsselverwaltung ab, erneut nach fünf Minuten oder einer HTTP-401-Antwort.
• claude setup-token: Erzeugt einen OAuth-Token mit einem Jahr Gültigkeit, der über CLAUDE_CODE_OAUTH_TOKEN bereitgestellt werden muss. Setzt ein Pro-, Max-, Team- oder Enterprise-Abonnement und eine einmalige Anmeldung im Browser voraus. Der Token ist auf Modellanfragen beschränkt und kann weder Remote-Control-Sitzungen starten noch claude.ai-Connectors abrufen.

ANTHROPIC_API_KEY und apiKeyHelper werden bei gesetztem forceLoginOrgUUID blockiert, weil sich ihre Organisationszugehörigkeit nicht überprüfen lässt. Cloud-Provider-Sitzungen müssen über die IAM-Richtlinien des jeweiligen Anbieters eingeschränkt werden.

Für eine vollständig automatisierte Ersteinrichtung scheidet claude setup-token damit aus. Die Dokumentation empfiehlt den Bare Mode, einen Minimalmodus für Skript- und SDK-Aufrufe, und kündigt ihn als künftigen Standard für -p an. Dort liest Claude Code weder gespeicherte OAuth-Zugangsdaten noch den Systemschlüsselbund und laut Dokumentation auch CLAUDE_CODE_OAUTH_TOKEN nicht. Pipelines, die heute darauf beruhen, können ausfallen, wenn -p künftig standardmäßig im Bare Mode läuft und die Pipeline keinen anderen Modus setzt. Robuster sind ein apiKeyHelper oder ein API-Schlüssel, dessen Abrechnung dem zugehörigen Konto oder Projekt folgt. Er gehört in die zentrale Schlüsselverwaltung, nicht in die Pipeline-Konfiguration.

Bei Verwendung von --dangerously-skip-permissions darf Claude Code unter Linux und macOS nicht als root laufen. Da viele CI-Images standardmäßig root verwenden, muss der Container einen anderen Benutzer setzen.

Proxy, Zertifikate und Hostfreigaben müssen zusammenpassen

Hinter einem Unternehmensproxy und einer restriktiven Firewall müssen Proxyvariablen, Zertifikate und Hostfreigaben zusammenpassen. Welche Daten der Agent dabei überträgt, behandelt Wohin telefoniert Ihr Coding-Agent?. Wie sich der Agent gezielt einschränken lässt, beschreibt Lokale Coding-Agents absichern.

Claude Code beachtet NO_PROXY und liest die Proxyvariablen in dieser Reihenfolge: https_proxy, HTTPS_PROXY, http_proxy, HTTP_PROXY. Kleingeschriebene Variablennamen haben Vorrang. Ein veralteter Wert in https_proxy überschreibt deshalb die zentrale Vorgabe, ohne dass das sofort auffällt. Claude Code unterstützt authentifizierte Proxys nur mit Basic Auth. Benutzername und Passwort stehen dabei in der Proxy-URL und gehören deshalb in die zentrale Schlüsselverwaltung, nicht fest in ein Skript. SOCKS, NTLM und Kerberos werden für den eigenen ausgehenden Verkehr nicht unterstützt. Für solche Umgebungen verweist Anthropic auf ein LLM-Gateway.

Seit Version 2.1.101 nutzt Claude Code standardmäßig den mitgelieferten und den systemweiten Zertifikatsspeicher. Hinter Proxys mit TLS-Inspektion genügt das ohne weitere Konfiguration, sofern das Stammzertifikat des Unternehmens im Zertifikatsspeicher des Betriebssystems liegt und der Prozess darauf zugreifen kann. Als Beispiele nennt Anthropic CrowdStrike Falcon und Zscaler. NODE_EXTRA_CA_CERTS sollte daher nur als Ausweichlösung dienen.

CLAUDE_CODE_CERT_STORE legt fest, welche Zertifikatsspeicher Claude Code verwendet. Der Standardwert lautet bundled,system. Da settings.json dafür keinen eigenen Schlüssel enthält, muss die Variable im env-Block gesetzt werden. Für die wechselseitige TLS-Authentifizierung verwendet Claude Code CLAUDE_CODE_CLIENT_CERT und CLAUDE_CODE_CLIENT_KEY.

Für den Betrieb auf vielen Geräten zählt, dass Claude Code in der Shell exportierte Netzwerkvariablen nur beim Start einliest. Hintergrundagenten übernehmen in der Shell exportierte Variablen laut Dokumentation nur dann, wenn diese Shell den übergeordneten Claude-Code-Prozess gestartet hat. Für den Rollout gilt daher: Proxyeinstellungen und die Pfade zu CA- und Client-Zertifikaten sollten im env-Block der zentralen Einstellungen stehen und nicht ausschließlich in .bashrc.

Erforderliche Hostfreigaben

Grundlage für ein Firewall-Ticket ist Anthropics Tabelle der erforderlichen Netzwerkzugriffe. Welche Hosts nötig sind, hängt vom Installationsweg und den genutzten Funktionen ab.

Für den Betrieb ist api.anthropic.com erforderlich. Der native Installer wird von claude.ai geladen. Binärdateien, Paketquellen und Signaturschlüssel liegen auf downloads.claude.ai, den auch der Auto-Updater anspricht. Bei npm kommt registry.npmjs.org hinzu, Homebrew benötigt zusätzlich formulae.brew.sh für die Versionsprüfung. Für die Anmeldung nennt Anthropic claude.com, claude.ai und platform.claude.com. Über platform.claude.com werden OAuth-Tokens für Konten der Claude Console und für claude.ai-Konten ausgetauscht, erneuert und widerrufen.

An dieser Stelle ist das eingangs genannte Referenzskript unvollständig. Die Freigabeliste in .devcontainer/init-firewall.sh, zuletzt geändert am 27. August 2025, umfasst registry.npmjs.org, api.anthropic.com, sentry.io, statsig.anthropic.com, statsig.com und drei Hosts für VS-Code-Erweiterungen. Die Netzwerktabelle nennt mit Stand vom 6. August 2026 darüber hinaus claude.ai und downloads.claude.ai. Im Referenzskript fehlen damit platform.claude.com, claude.ai und downloads.claude.ai.

Weitere Hosts hängen von der genutzten Funktion ab. Die folgende Tabelle zeigt eine Auswahl. Die vollständige Liste steht in der oben verlinkten Herstellertabelle.

Die beiden Datadog-Hosts dienen optionaler Betriebstelemetrie und lassen sich mit CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC gemeinsam deaktivieren. Bei Sitzungen über Bedrock, Vertex oder Foundry werden diese Hosts nicht verwendet.

Zwei Fälle werden leicht übersehen. Wer Claude Code über Bedrock, Vertex oder ein Gateway betreibt, benötigt api.anthropic.com weiterhin für die Vorabprüfung des WebFetch-Tools, sofern skipWebFetchPreflight nicht gesetzt ist. Und die Desktop-App braucht mehr Hosts als die CLI, unter anderem assets-proxy.anthropic.com. Das Fehlerbild ist irreführend: Sind diese Hosts blockiert, zeigt die Desktop-App unter Umständen nur eine leere Seite statt einer Fehlermeldung.

Was claude doctor im Netzwerk prüft, ist nicht dokumentiert

Wenn die TLS-Prüfung scheitert, gibt Claude Code folgenden Hinweis aus:

SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a
corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA
bundle path, or ask IT to allowlist *.anthropic.com. Run `claude doctor` for details.

Die Dokumentation beschreibt claude doctor als Prüfung des Installationszustands, der Einstellungsdateien und der Eignung für Remote Control. Eine Netzwerk-, Proxy- oder Zertifikatsprüfung ist nicht dokumentiert. Ob der Befehl intern mehr prüft, ist offen.

Belastbar ist stattdessen claude --debug. Der Zusatz "api,mcp" beschränkt die Ausgabe auf bestimmte Kategorien. Die Debug-Datei liegt unter ~/.claude/debug/<session-id>.txt. Relevant sind vor allem diese Einträge:

CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS (/etc/ssl/certs/corp-ca.pem)
mTLS: Loaded client certificate from CLAUDE_CODE_CLIENT_CERT

Failed to read oder Failed to load bedeuten, dass die angegebene Datei nicht gelesen oder nicht geladen werden konnte. Vorsicht bei /status: Die Zeile „Additional CA cert(s)“ zeigt nur den konfigurierten Pfad aus NODE_EXTRA_CA_CERTS, nicht das erfolgreiche Laden. Die mTLS-Einträge erscheinen dagegen nur bei Erfolg. Fehlen sie trotz entsprechender Konfiguration, wurden Zertifikat oder Schlüssel nicht erfolgreich geladen. Den Grund nennt die Debug-Datei.

Beim Start prüft Claude Code lediglich die Proxy-URL. Fehler in den übrigen Netzwerk- und Zertifikatsangaben zeigen sich erst bei der ersten Anfrage.

Verwaltete Einstellungen haben Vorrang vor lokalen Einstellungen

Claude Code wertet Einstellungen in absteigender Priorität aus: verwaltete Einstellungen, Kommandozeilenargumente, .claude/settings.local.json, .claude/settings.json und ~/.claude/settings.json. Die Datei mit den verwalteten Einstellungen liegt unter macOS in /Library/Application Support/ClaudeCode/managed-settings.json, unter Linux und WSL in /etc/claude-code/managed-settings.json und unter Windows in C:\Program Files\ClaudeCode\managed-settings.json. Zusätzliche Dateien im Verzeichnis managed-settings.d/ werden in alphabetischer Reihenfolge mit der Basisdatei zusammengeführt. So lassen sich die zentralen Vorgaben modular nach Teams oder Verantwortungsbereichen aufteilen.

Alternativ lassen sich die Einstellungen per Geräteverwaltung verteilen. Unter macOS dient dafür die Preferences-Domain com.anthropic.claudecode. Unter Windows enthält der Registry-Schlüssel HKLM\SOFTWARE\Policies\ClaudeCode den JSON-Wert Settings. Die Desktop-App ist ein eigenes Produkt und verwendet andere Schlüssel: com.anthropic.claudefordesktop unter macOS und SOFTWARE\Policies\Claude unter Windows. Beim Rollout dürfen beide nicht verwechselt werden. Der Benutzerzweig HKCU eignet sich nicht für Vorgaben, weil Benutzer ihn ohne erhöhte Rechte ändern können.

Innerhalb der verwalteten Ebene verwendet Claude Code nur eine Quelle. Quellen mit niedrigerer Priorität werden ignoriert und nicht zusammengeführt. Die Reihenfolge lautet policyHelper, dann servergesteuerte Einstellungen, dann Richtlinien aus Geräteverwaltung und Betriebssystem, dann die verwalteten Dateien managed-settings.json und managed-settings.d/, zuletzt die HKCU-Registry. Wer sowohl eine plist als auch eine managed-settings.json verteilt, erhält daher keine zusammengeführte Konfiguration. Claude Code wertet nur die plist aus. Die formal korrekte JSON-Datei bleibt wirkungslos.

Zentral vorgegeben werden sollten insbesondere:

1. die Berechtigungsregeln unter permissions.allow, permissions.ask und permissions.deny
2. permissions.disableBypassPermissionsMode mit dem Stringwert "disable"
3. die Updatevariablen im env-Block
4. die Vorgaben zur Anmeldemethode und Organisation
5. die Freigabe verwalteter MCP-Server

permissions.disableBypassPermissionsMode deaktiviert zugleich --dangerously-skip-permissions.

Bei MCP-Servern ist besondere Vorsicht nötig: Freigabelisten aus verwalteten und lokalen Einstellungen werden standardmäßig zusammengeführt. Entwickler können eine zentral vorgegebene Liste deshalb erweitern. Soll ausschließlich die zentral verwaltete Freigabeliste gelten, müssen allowedMcpServers und allowManagedMcpServersOnly: true gemeinsam in verwalteten Einstellungen gesetzt werden. Für einen fest vorgegebenen, exklusiven Serversatz steht alternativ managed-mcp.json zur Verfügung. Diese Datei lässt sich nicht über servergesteuerte Einstellungen verteilen. Was MCP-Server sind, steht in Was ist ein MCP-Server?.

Claude Code verarbeitet fehlerhafte verwaltete Einstellungen abhängig vom betroffenen Feld. Viele ungültige Einträge werden entfernt, während die übrige Konfiguration aktiv bleibt. Einige sicherheitsrelevante Felder werden dagegen restriktiv behandelt. Ein ungültiger Wert für forceLoginOrgUUID blockiert beispielsweise alle Organisationsanmeldungen, bis er korrigiert wurde. Auch allowManagedMcpServersOnly gilt bei einem ungültigen Wert als aktiviert. Vor einem organisationsweiten Rollout sollten die Einstellungen deshalb auf einem Testgerät mit claude doctor geprüft und sämtliche Warnungen ausgewertet werden.

Die vereinfachte Regel „verwaltete Einstellungen gewinnen immer“ gilt nicht überall: Bei einigen Schlüsseln setzt sich über mehrere Ebenen hinweg der restriktivere Wert durch. Ein Entwickler kann disableBypassPermissionsMode lokal verschärfen, eine zentral gesetzte Sperre aber nicht lockern.

Unter examples/mdm stellt Anthropic Vorlagen bereit (plist und Konfigurationsprofil für Jamf oder Kandji, PowerShell-Skript für Intune, ADMX/ADML-Paar für Gruppenrichtlinien), die laut README von der Community gepflegt werden, Fehler enthalten können und deshalb vor dem Rollout selbst zu prüfen sind.

Prüfliste für den Rollout

Die folgende Prüfliste ordnet die Schritte so, wie sie im Rollout anfallen.

1. Installationsweg festlegen und begründen. Wenn APT, DNF oder WinGet bereits zentral verwaltet werden und Updates verteilen, sollte Claude Code über denselben Kanal verteilt und aktualisiert werden. Ohne zentrale Softwareverteilung empfiehlt Anthropic den nativen Installer.
2. Updatestrategie festlegen. Entscheiden Sie, ob Hintergrundupdates erlaubt sind. Soll nur die automatische Prüfung entfallen, setzen Sie DISABLE_AUTOUPDATER=1. Sollen Entwickler auch keine manuellen Updates ausführen können, verwenden Sie DISABLE_UPDATES=1. Einen verbindlichen Versionsbereich geben Sie zusätzlich mit requiredMinimumVersion und requiredMaximumVersion vor. Wer Versionen festschreibt, braucht einen regelmäßigen Prüf- und Aktualisierungsprozess.
3. Ein Firewall-Ticket erstellen und die Hosts nach Installation, Anmeldung, Betrieb und Updates gruppieren. platform.claude.com muss ausdrücklich genannt werden. Referenzskripte dürfen nicht ungeprüft übernommen werden.
4. Verwaltete Einstellungen konfigurieren und über genau einen Kanal verteilen. Sie sollten Organisationsbindung, Berechtigungsregeln, Updateregeln sowie Proxy- und Zertifikatswerte im env-Block enthalten. Stehen diese Netzwerkwerte nur in .bashrc, übernehmen Hintergrundagenten sie möglicherweise nicht.
5. Unternehmenslizenzen zuweisen und die zulässige Organisation vorgeben. Da servergesteuerte Einstellungen erst nach der ersten Anmeldung greifen, muss diese Vorgabe vor dem ersten Aufruf von claude über die Geräteverwaltung ausgerollt sein.
6. Vorhandene Installationen und Zugangsdaten prüfen. Mit which -a claude beziehungsweise where.exe claude nach Binärdateien suchen. Die VS-Code-Erweiterung bringt eine eigene CLI-Kopie mit, deren Verzeichnis nicht in PATH steht. Claude Code kann deshalb auf einem Gerät vorhanden sein, obwohl ~/.local/bin/claude fehlt. Shell-Profile und Benutzervariablen auf alte Werte für ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN und CLAUDE_CODE_OAUTH_TOKEN prüfen, ~/.claude/settings.json auf einen apiKeyHelper. Alte claude-Aliase müssen entfernt werden.
7. Rollout prüfen. Die Prüfung darf sich nicht auf claude doctor beschränken. claude auth status liefert Organisation und Abonnementtyp als JSON. Die Datei unter ~/.claude/debug/ aus claude --debug protokolliert das Laden von CA- und Client-Zertifikaten. Fehlen die mTLS-Erfolgseinträge trotz entsprechender Konfiguration, wurden Zertifikat oder Schlüssel nicht geladen. Den Grund nennt die Debug-Datei. /status zeigt unter Setting sources, welche Einstellungsquellen in der laufenden Sitzung geladen wurden, und damit zumindest die aktive Quelle der verwalteten Einstellungen. Welche Updateregel greift, belegen diese Befehle nicht.

Pilotgruppe, Schulung und Aufgabenauswahl sind die nächsten organisatorischen Schritte. Der 90-Tage-Plan für die Einführung behandelt diese Phase.

Stand und Wartung: Dieser Beitrag ist stark versionsabhängig. Die Datei CHANGELOG.md im Repository enthält keine Datumsangaben. Die folgenden Daten beruhen deshalb auf den Veröffentlichungszeitstempeln der npm-Registry. Zwischen Version 2.1.8 vom 15. Januar 2026 und 2.1.223 vom 5. August 2026 erschienen mehr als zweihundert Patch-Versionen in rund zweihundert Tagen.

In den sechzehn Tagen vor Redaktionsschluss betrafen die Versionen 2.1.217, 2.1.222 und 2.1.223 allesamt das Verhalten von Proxy, Zertifikaten und Einstellungen, darunter eine Verbindungsprüfung beim Start, die hinter einem HTTPS-Proxy hängen blieb. Ein im März dokumentierter Konfigurationsweg kann wenige Monate später entfallen. Auch der Windows-Speicherort für verwaltete Einstellungen wurde mit Version 2.1.75 geändert.

Deshalb sollten Teams jede Rolloutentscheidung mit Datum und Begründung dokumentieren. Ein solches Entscheidungsprotokoll bleibt auch dann aussagekräftig, wenn Anthropic Installationswege, Einstellungsfelder oder Standardwerte später ändert.

Quellen

Die Herstellerseiten wurden am 6. August 2026 abgerufen. Die zu diesem Zeitpunkt aktuelle Claude-Code-Version war 2.1.223. Da Claude Code häufig aktualisiert wird, sollten Sie vor der Umsetzung die aktuelle Dokumentation prüfen.

• Anthropic: Set up Claude Code · Installationswege, Updateverhalten, Systemvoraussetzungen, Windows-Entscheidungstabelle, Deinstallation
• Anthropic: Enterprise network configuration · Proxy-Variablen, Zertifikatsspeicher, mTLS und die Tabelle der erforderlichen Hosts
• Anthropic: Authentication · Rangfolge der Zugangsdaten, Speicherorte, forceLoginMethod und forceLoginOrgUUID
• Anthropic: Settings · Rangfolge der Einstellungen, Pfade der verwalteten Einstellungen, Registry und Preferences-Domain
• Anthropic: Sandboxing · die fehlende Sandbox-Unterstützung unter nativem Windows
• Anthropic: Troubleshoot installation · Fehlermeldungen bei der Installation, Ausführungsrichtlinie, Sperrlistenprüfung, alter API-Key im Shell-Profil
• Anthropic: Troubleshooting · eingeschränkte Suchleistung unter WSL auf /mnt/c
• Anthropic: CLI reference · claude auth status, claude doctor, --debug, Schalter für die nicht interaktive Nutzung
• Anthropic: Set up Claude Code for your organization · Reihenfolge innerhalb der verwalteten Ebene, Verteilungswege
• Anthropic: Desktop · Unterschiede zwischen Desktop-App und CLI, Git-Voraussetzung unter Windows
• anthropics/claude-code · Changelog, .devcontainer/init-firewall.sh (letzter Commit 27. August 2025), examples/mdm/