Skip to main content
Cloud-Umgebungen gelten für Cloud-Sitzungen, die auf Pro-, Max- und Team-Plänen verfügbar sind, sowie für Enterprise-Benutzer mit Premium-Sitzen oder Chat + Claude Code-Sitzen.
Jede Cloud-Sitzung wird in einer Cloud-Umgebung ausgeführt. Sie können eine Umgebung so konfigurieren, dass sie Netzwerkzugriff zulässt oder verweigert, Umgebungsvariablen für die Sitzung festlegt, Netzwerk-Secrets speichert, die Sitzungen verwenden, ohne sie zu sehen, und ein Setup-Skript ausführt, bevor Claude mit der Arbeit beginnt. Die gleichen Umgebungen gelten überall dort, wo Sie eine Cloud-Sitzung starten: Jede dieser Oberflächen kann auch zu einer selbstgehosteten Umgebung weiterleiten. Verfügbarkeit und Einschränkungen behandelt, was Claude noch nicht verwenden kann, wenn eine Claude Tag-Sitzung in einer ausgeführt wird.
Remote Control-Sitzungen verbinden die Web- und Mobile-Schnittstellen mit einer Sitzung auf Ihrem eigenen Computer, die das Netzwerk und die Dateien Ihres Computers nutzt, nicht eine Cloud-Umgebung. Claude Tag-Kanalsitzungen verwenden nur Umgebungen auf Organisationsebene, entweder gemeinsame Umgebungen oder selbstgehostete Umgebungen.

​
Die Standard-Umgebung

Wenn Sie noch keine Umgebung haben, richtet das Onboarding die Standard-Umgebung für Sie ein. Wie hängt davon ab, wo Sie das Onboarding durchführen:
  • CLI-Flüsse wie /web-setup: erstellen Standard für Sie
  • Web-Onboarding auf Pro und Max: erstellt Standard für Sie
  • Web-Onboarding auf Team und Enterprise: zeigt ein Formular Erstellen Sie Ihre erste Cloud-Umgebung, es sei denn, ein Eigentümer hat Schnelles Setup aktiviert; behalten Sie die Standardwerte des Formulars bei und klicken Sie auf Erstellen und fertig, um die gleiche Standard-Umgebung zu erhalten
Standard hat keine eigene Konfiguration: Wenn nur Standard verfügbar ist, wird jede Sitzung darin ausgeführt. Wenn Sie mehr als eine Umgebung haben, wählen Sitzungen eine pro Oberfläche:
  • In der Desktop-App, der Mobile-App und unter claude.ai/code verwenden Sitzungen die im Selector angezeigte Umgebung. Ein Organisations-Standard, der von einem Eigentümer festgelegt wurde, füllt die Auswahl, wenn Sie noch keine ausgewählt haben. Threads in einem Projekt verwenden stattdessen die in den Projekteinstellungen festgelegte Umgebung.
  • Aus der CLI verwendet Claude Code Ihre /remote-env-Auswahl oder fällt auf die von Anthropic gehostete Umgebung zurück, wenn Ihre Liste eine hat, und andernfalls auf die erste Umgebung in Ihrer Liste, die keine Bridge-Umgebung ist, ein Eintrag Remote Control registriert, um Ihren eigenen Computer darzustellen, anstatt eine Cloud-Umgebung. Für eine selbstgehostete Umgebung überschreibt das Übergeben von --environment <environment-id> mit ihrer ccpool_-ID wenn Sie eine Sitzung versenden die /remote-env-Auswahl und den Fallback für diese Invocation. Claude Code lehnt von Anthropic gehostete env_-IDs ab, die an das Flag übergeben werden, daher verwenden Sie /remote-env, um diese anzusteuern. Das Flag erfordert Claude Code v2.1.224 oder später.
Konfigurieren Sie eine Umgebung, wenn der Standard nicht ausreicht: wenn Claude Domänen außerhalb der Standard-Whitelist erreichen muss, Umgebungsvariablen für seine Sitzungen benötigt oder Abhängigkeiten installiert werden müssen, bevor es mit der Arbeit beginnt.

​
Konfigurieren Sie Ihre Umgebung

Fügen Sie Umgebungen über den Umgebungswähler unter dem Nachrichtenfeld auf dem Bildschirm hinzu, auf dem Sie unter claude.ai/code eine neue Sitzung starten, und bearbeiten und archivieren Sie sie dort. Um diesen Bildschirm zu erreichen, schließen Sie das Web-Onboarding ab. Informationen zur Desktop-App finden Sie unter Cloud-Sitzungen. Umgebungen, die Sie erstellen, sind persönlich für Ihr Konto; gemeinsame Umgebungen, die von einem Owner erstellt wurden, erscheinen im selben Wähler. Siehe Installierte Tools für das, was ohne Konfiguration verfügbar ist. Der Wähler wird nur angezeigt, bis Sie die erste Nachricht einer neuen Sitzung senden. Um die Umgebung einer laufenden eigenen Cloud-Sitzung zu bearbeiten, wählen Sie oben das Caret-Symbol nach dem Sitzungstitel aus und wählen Sie dann Cloud-Umgebung bearbeiten.
1

Öffnen Sie den Umgebungswähler

Wählen Sie auf dem Bildschirm für neue Sitzungen das erste Steuerelement in der Zeile unter dem Nachrichtenfeld aus.
2

Fügen Sie eine Umgebung hinzu oder bearbeiten Sie sie

  • Eine Umgebung hinzufügen: Wählen Sie Neue Umgebung unten im Menü aus, um den Dialog Neue Umgebung zu öffnen. Füllen Sie das Formular aus und wählen Sie Umgebung hinzufügen. Ihre neue Sitzung verwendet dann die hinzugefügte Umgebung.
  • Eine Umgebung bearbeiten: Suchen Sie ihre Zeile unter Cloud. Wenn Cloud eine einzelne Zeile ist, wählen Sie sie aus, um die Liste zu öffnen. Wenn Ihre Umgebung nicht unter Cloud aufgeführt ist, wählen Sie die Zeile Mehr unter dieser Überschrift aus. Bewegen Sie den Mauszeiger über die Zeile der Umgebung und wählen Sie das Einstellungssymbol aus, das auf der rechten Seite angezeigt wird, um ihren Dialog zu öffnen.
Wenn Sie eine Umgebung hinzufügen oder eine Ihrer eigenen bearbeiten, wählen Sie im Dialog die Zeile Netzwerkzugriff, Setup-Skript oder Umgebungsvariablen aus, um die jeweilige Einstellung zu öffnen. Speichern Sie nach Ihrer letzten Änderung mit Umgebung hinzufügen für eine neue Umgebung oder mit Änderungen speichern für eine vorhandene. Informationen zum Speichern eines Schlüssels, den Sitzungen verwenden, ohne ihn zu sehen, finden Sie unter Fügen Sie Netzwerk-Secrets hinzu.

​
Legen Sie Umgebungsvariablen fest

Umgebungsvariablen verwenden das .env-Format, ein KEY=value-Paar pro Zeile. Einfache Werte benötigen keine Anführungszeichen, und wenn Sie einen Wert mit einem passenden Paar in Anführungszeichen setzen, werden die Anführungszeichen nicht Teil des Wertes. Setzen Sie einen Wert in Anführungszeichen, der sich über mehrere Zeilen erstreckt oder ein # enthält: in einem Wert ohne Anführungszeichen startet # einen Kommentar und der Rest der Zeile wird verworfen. Das folgende Beispiel definiert drei Variablen.
Eine Sitzung liest die Werte der Umgebung in gewöhnliche Umgebungsvariablen, die jeder Befehl, den Claude ausführt, lesen kann, außer OTEL_*-Variablen. Claude Code verwendet diese für seinen eigenen Telemetrie-Export und übergibt sie nicht an die Befehle, die es ausführt. In einer von Anthropic gehosteten Umgebung liest eine Sitzung die Werte der Umgebung, wenn Sie sie erstellen, und erneut jedes Mal, wenn Claude Code in der VM der Sitzung danach startet, was in zwei Fällen geschieht:
  • Die VM wird nach Leerlauf wiederhergestellt: Nach einigen Minuten ohne Aktivität wird die VM einer Sitzung mit ihren Dateien gespeichert angehalten. Ihre nächste Nachricht stellt dieselbe VM wieder her und startet Claude Code erneut.
  • Die VM wurde freigegeben und wird neu erstellt: Wenn die angehaltene VM seitdem freigegeben wurde, wird beim erneuten Öffnen der Sitzung eine neue VM bereitgestellt.
Nachdem Sie eine Variable bearbeitet, hinzugefügt oder entfernt haben, behält eine vorhandene Sitzung in einer von Anthropic gehosteten Umgebung die Werte, die sie zuletzt gelesen hat, bis ihre VM das nächste Mal wiederhergestellt oder neu erstellt wird, und verwendet Ihre Änderung von da an. Ihre VM wird von selbst angehalten, sobald die Sitzung untätig ist, und Sie können sie nicht selbst anhalten. Um einen neuen Wert sofort zu verwenden, bitten Sie Claude, ihn auf dem Befehl zu setzen, den es ausführt, zum Beispiel LOG_LEVEL=trace npm test, oder starten Sie eine neue Sitzung. Eine Cloud-Sitzung setzt auch einige Variablen selbst, wenn sie startet. Für CLAUDE_AUTOCOMPACT_PCT_OVERRIDE überschreibt der Wert, den die Sitzung setzt, einen, den Sie hier hinzufügen, daher hat das Hinzufügen dieses Schlüssels hier keine Auswirkung. Jeder, der die Umgebung nutzt, kann die Werte lesen. Verwenden Sie in einer von Anthropic gehosteten Umgebung stattdessen ein Netzwerk-Secret für einen Schlüssel, den der Agent-Proxy an eine Anfrage anhängen kann. Die Anfragen, die niemals ein Secret erhalten, sind dort aufgelistet.

​
Fügen Sie Netzwerk-Secrets hinzu

Ein Netzwerk-Secret ist ein API-Schlüssel oder Token, den Sie in einer Cloud-Umgebung speichern, damit Claude diese API aus jeder Sitzung in der Umgebung aufrufen kann, ohne den Schlüssel zu sehen. Der Agent-Proxy von Anthropic fügt den Schlüssel zu Anfragen für die Hosts hinzu, die Sie auflisten, nachdem jede Anfrage die VM der Sitzung verlässt, sodass der Schlüssel selbst außerhalb der VM bleibt. Netzwerk-Secrets sind in Pro-, Max-, Team- und Enterprise-Plänen verfügbar. Ob Sie selbst eines hinzufügen können, erfahren Sie unter Anforderungen.

​
Anforderungen

Diese Anforderungen entscheiden, ob Sie ein Secret hinzufügen können und ob der Agent-Proxy es nach dem Hinzufügen verwenden kann:
  • Rolle: In Pro-, Max- und Team-Plänen können Sie unabhängig von Ihrer Rolle Secrets in Ihren eigenen Umgebungen hinzufügen und löschen. In Team und Enterprise haben Owner eine Organisationsadministrator-Rolle in Ihrer claude.ai-Organisation, Admins nicht, was in diesen Fällen ändert, was Sie sehen:
    • Ihre eigene Umgebung in Enterprise: Mit einer Organisationsadministrator-Rolle fügen Sie Secrets hinzu und löschen sie. Ohne diese Rolle öffnet die Zeile Netzwerk-Secrets die Liste der Secrets mit dem Hinweis „Nur ein Organisationsadministrator kann Netzwerk-Secrets hinzufügen oder löschen“ und ohne Schaltfläche Secret hinzufügen oder Löschen. Bitten Sie einen Owner, das Secret zu einer gemeinsamen Umgebung hinzuzufügen, und führen Sie Ihre Sitzungen dann dort aus
    • Eine gemeinsame Umgebung: Owner fügen ihre Secrets hinzu und löschen sie über die Admin-Einstellungen. Ohne Organisationsadministrator-Rolle bitten Sie einen Owner, das Secret hinzuzufügen, da der Dialog der Umgebung keinen Bereich Netzwerk-Secrets hat
    • Ihre eigene Umgebung in Team: Ohne Organisationsadministrator-Rolle öffnet Secret hinzufügen ein kürzeres Formular, das einen einzelnen Host aufnimmt
  • Umgebungstyp: eine von Anthropic gehostete Cloud-Umgebung, die bereits existiert. Eine selbst gehostete Umgebung hat keine Netzwerk-Secrets
  • API-Erreichbarkeit: die API akzeptiert Verbindungen aus dem Internet, da Anfragen aus dem Netzwerk von Anthropic ausgehen
  • Verschlüsselungsschlüssel: wenn Ihre Organisation kundenverwaltete Verschlüsselungsschlüssel verwendet, können Sie keine Netzwerk-Secrets speichern

​
Fügen Sie ein Secret hinzu

Sie fügen Secrets einzeln hinzu. Um die Hosts oder den Wert eines Secrets zu ändern, löschen Sie es und fügen Sie es erneut hinzu. Um ein Secret zu einer gemeinsamen Umgebung hinzuzufügen, öffnen Sie diese zur Bearbeitung über die Seite Cloud-Umgebungen in den Admin-Einstellungen und fahren Sie dann mit Schritt 2 im Bereich Netzwerk-Secrets fort. Wenn Sie einen Team-Plan nutzen und keine Organisationsadministrator-Rolle haben, folgen Sie Schritt 1 in Ihrer eigenen Umgebung und füllen Sie dann das kürzere Formular aus.
1

Öffnen Sie die Netzwerk-Secrets der Umgebung

Öffnen Sie die Umgebung zur Bearbeitung unter claude.ai/code. Wählen Sie im Dialog Cloud-Umgebung bearbeiten die Zeile Netzwerk-Secrets aus. Sie sehen die Secrets, die bereits in der Umgebung vorhanden sind, jeweils mit den Hosts, auf die sie sich beziehen.
2

Fügen Sie das Secret hinzu

Wählen Sie Secret hinzufügen, in den Admin-Einstellungen mit Hinzufügen beschriftet, und füllen Sie das Formular aus. Behalten Sie den Standard-Secret-Typ, Bearer, für einen API-Schlüssel, der in einem Request-Header übertragen wird, und füllen Sie diese Felder aus:
  • Name: eine Bezeichnung für das Secret, wie Internal billing API
  • Zulässige Websites: die Hosts der API, wie api.example.com. Ein führendes *. passt zu jeder Subdomain
  • Benutzerdefinierte Header: eine Zeile für den Header, der den Schlüssel trägt. Die Zeile beginnt mit Authorization als Name des Headers und Bearer als Präfix; fügen Sie den Schlüssel selbst als Wert ein. Für einen Header wie X-Api-Key, der den bloßen Wert nimmt, ändern Sie den Namen und löschen Sie das Präfix
Für eine API, die sich anders authentifiziert, wählen Sie einen anderen Secret-Typ. Die Liste ist dieselbe, die Claude Tag, die Slack-Integration für Team- und Enterprise-Pläne, für Verbindungen anbietet.
3

Speichern Sie das Secret

Wählen Sie Hinzufügen. Das Secret erscheint in der Liste mit seinen Hosts, gespeichert ohne die Schaltfläche Änderungen speichern des Dialogs. Sie können den Wert nach dem Speichern nicht erneut anzeigen.
Um zu bestätigen, dass das Secret funktioniert, starten Sie eine Sitzung in der Umgebung und bitten Sie Claude, die API aufzurufen, zum Beispiel mit curl. Die API antwortet, als wäre der Schlüssel in der Anfrage, und der Schlüssel erscheint nicht in den Umgebungsvariablen der Sitzung oder in einer Datei. Wenn die Liste ein Secret stattdessen als Nicht gesendet markiert, sagt der Hinweis darunter, warum und was zu tun ist. Zwei Secrets, deren Hosts sich überlappen, ohne genau übereinzustimmen, erhalten keine Markierung, und der Agent-Proxy sendet nur eines davon.

​
Fügen Sie ein Secret in einem Team-Plan ohne Organisationsadministrator-Rolle hinzu

Wenn Sie einen Team-Plan nutzen und keine Organisationsadministrator-Rolle haben, nimmt das Formular Secret hinzufügen ein Secret für einen einzelnen Host auf. Wählen Sie die Zeile Netzwerk-Secrets Ihrer Umgebung und dann Secret hinzufügen aus. Füllen Sie diese Felder aus und wählen Sie die Schaltfläche Secret hinzufügen des Formulars:
  • Host: der eine Host, der das Secret erhält, wie api.example.com. Das Formular akzeptiert keinen *.-Platzhalter
  • Name: eine optionale Bezeichnung für das Secret
  • Secret-Typ: Token für einen Schlüssel, der in einem Request-Header übertragen wird, oder Benutzername und Passwort. Fügen Sie bei einem Token den Schlüssel als Wert ein

​
Welche Anfragen erhalten das Secret

Der Agent-Proxy fügt ein Secret an eine Anfrage an, wenn der Host der Anfrage mit einem übereinstimmt, den Sie bei diesem Secret aufgelistet haben. Sitzungen können diese Hosts erreichen, auch wenn die Netzwerkzugriffsstufe der Umgebung dies sonst nicht zulassen würde, außer den Hosts, die niemals das Secret erhalten. Das Secret gilt in jeder Sitzung, die in der Umgebung ausgeführt wird, wer sie auch gestartet hat, bis Sie es löschen.

​
Anfragen, die niemals das Secret erhalten

Der Agent-Proxy fügt niemals ein Secret, das Sie hinzufügen, zu diesen Anfragen hinzu:
  • GitHub: der GitHub-Proxy authentifiziert stattdessen Anfragen an GitHub, daher benötigen Sie kein Netzwerk-Secret dafür
  • Die Anthropic API und öffentliche Paketregistrierungen: api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io und proxy.golang.org
  • Setup-Skript-Anfragen: Claude Code verbindet sich mit dem Agent-Proxy, wenn er startet, nachdem das Setup-Skript ausgeführt wurde
  • Claude Code’s Telemetrie-Export: Claude Code sendet seinen Telemetrie-Export selbst, anstatt durch einen Befehl, den es ausführt, und diese Anfrage geht nicht durch den Agent-Proxy

​
Wählen Sie eine Umgebung aus der CLI

Führen Sie /remote-env in Ihrem Terminal aus, um die Standardumgebung für Cloud-Sitzungen auszuwählen, die Sie aus der CLI erstellen, wie claude --cloud. Der Befehl öffnet einen Picker Ihrer vorhandenen Umgebungen und speichert Ihre Auswahl im Schlüssel remote.defaultEnvironmentId in Ihren Benutzereinstellungen, damit er in jedem Projekt auf Ihrem Computer gilt, bis Sie ihn ändern, es sei denn, derselbe Schlüssel ist in einer höheren Prioritäts-Einstellungsebene gesetzt, wie den Projekteinstellungen eines Repos. Eine selbst gehostete Umgebung ID, die die Form ccpool_... hat, folgt einer strengeren Quellregel. Siehe remote.defaultEnvironmentId für die Einstellungsebenen, die Claude Code dafür berücksichtigt. /remote-env setzt nur den Standard: es startet keine Sitzung und kann keine Umgebungen hinzufügen oder bearbeiten. Verwalten Sie sie aus dem Umgebungswähler.

​
Archivieren Sie eine Umgebung

Um eine Ihrer eigenen Umgebungen zu archivieren, öffnen Sie sie zur Bearbeitung, wählen Sie Umgebung archivieren und bestätigen Sie. Wenn die Umgebung mit Ihrer Organisation geteilt ist, archiviert stattdessen ein Owner sie über die Seite Cloud-Umgebungen in den Admin-Einstellungen. Wenden Sie sich daher an einen Owner, sofern Sie nicht selbst einer sind. Das Archivieren wirkt sich auf neue Sitzungen aus, nicht auf laufende:
  • Sitzungen, die bereits in der Umgebung laufen, funktionieren weiterhin.
  • Die Umgebung verschwindet aus dem Wähler und aus /remote-env, daher können Sie sie nicht für neue Sitzungen auswählen.
  • Netzwerk-Secrets in der Umgebung bleiben in ihren laufenden Sitzungen angehängt. Löschen Sie alle, die Sie nicht mehr benötigen, bevor Sie archivieren.
  • Keine neue Sitzung kann in einer archivierten Umgebung starten, auf keiner Oberfläche:
    • Gespeicherter CLI-Standard: Wenn die Umgebung Ihr gespeicherter CLI-Standard war, startet Claude Code CLI-Cloud-Sitzungen in der von Anthropic gehosteten Umgebung, wenn Ihre Liste eine hat. Andernfalls startet es sie in der ersten Umgebung in Ihrer Liste, die keine Remote-Control-Bridge-Umgebung ist.
    • Explizit konfiguriert: Alles, das explizit mit der Umgebung konfiguriert ist, wie eine geplante Cloud-Aufgabe, kann keine neuen Sitzungen darin starten. Zeigen Sie es auf eine andere Umgebung.
Wenn Sie eine von Anthropic gehostete Umgebung nicht mehr benötigen, archivieren Sie sie. Weder der Umgebungsdialog noch die Admin-Seite Cloud-Umgebungen bietet eine Option zum Löschen einer von Anthropic gehosteten Umgebung. Wenn die Umgebung selbst gehostet ist, kann ein Owner sie über die Seite Cloud-Umgebungen in den Admin-Einstellungen löschen. Wenn Sie kein Owner sind, bitten Sie einen Owner, sie zu löschen.

​
Gemeinsame Organisationsumgebungen

In Team- und Enterprise-Plänen kann ein Owner Cloud-Umgebungen erstellen, die mit jedem Mitglied der Organisation geteilt werden. Dieselbe Rolle verwaltet alles andere auf der Seite Cloud-Umgebungen in den Admin-Einstellungen, einschließlich selbst gehosteter Umgebungen; die Admin-Rolle kann die Seite nicht öffnen. Die vollständige Liste der Rollen, die die Seite öffnen können, ist die für Verwaltung von Server-verwalteten Einstellungen. Gemeinsame Umgebungen erscheinen im Umgebungswähler jedes Mitglieds unter einer Organisation-Überschrift, nach den eigenen Umgebungen des Mitglieds unter Persönlich, damit ein Team sich auf eine Konfiguration standardisieren kann, statt dass jedes Mitglied sie neu erstellt. Das Auswählen des Einstellungssymbols einer gemeinsamen Umgebung dort öffnet eine schreibgeschützte Zusammenfassung ihrer Konfiguration für jedes Mitglied, einschließlich Owner. Ein Owner macht eine Umgebung der Organisation auf eine von zwei Arten verfügbar:
  • Erstellen Sie eine gemeinsame Umgebung: verwenden Sie die Seite Cloud-Umgebungen in den Admin-Einstellungen, wo Owner auch gemeinsame Umgebungen bearbeiten und archivieren. Jede hat einen Namen, eine Netzwerkzugriffsstufe, Umgebungsvariablen im .env-Format und ein Setup-Skript.
  • Teilen Sie eine persönliche Umgebung: öffnen Sie eine Ihrer eigenen Umgebungen zur Bearbeitung im Umgebungswähler, dann teilen Sie sie aus der Zeile Wer kann sie verwenden. Die Umgebung behält ihre ID, daher sind Sitzungen und geplante Aufgaben, die sie bereits verwenden, nicht betroffen, und jedes Mitglied kann sie dann sehen und Sitzungen darin starten.
Owner wählen die Standardumgebung der Organisation separat unter claude.ai/admin-settings/claude-code. Um den Sitzungen einer gemeinsamen Umgebung einen Schlüssel zu geben, den sie nicht lesen können, fügen Sie ein Netzwerk-Secret hinzu, wenn Sie die Umgebung auf der Seite Cloud-Umgebungen bearbeiten. Fügen Sie keine Secrets in ihre Variablen ein, da die Sitzungen jedes Mitglieds sie lesen.

​
Legen Sie die Umgebung fest, die ein Claude Tag-Kanal verwendet

In Claude Tag-Kanälen arbeitet Claude als die gemeinsame Identität Ihrer Organisation, nicht als ein Mitglied, daher verwenden Kanalsitzungen nur Umgebungen auf Organisationsebene, entweder gemeinsame Umgebungen oder selbst gehostete Umgebungen. Um einem Kanal eine Toolchain zu geben, die nicht vorinstalliert ist, wie .NET, kann ein Owner eine gemeinsame Umgebung von der Seite Cloud-Umgebungen in den Admin-Einstellungen mit einem Setup-Skript erstellen, das sie installiert. Zeigen Sie den Kanal auf eine Umgebung auf eine von zwei Arten:

​
Netzwerkzugriff

Jede Umgebung legt eine Netzwerkzugriffsstufe fest, die steuert, welche ausgehenden Verbindungen ihre Sitzungen herstellen können. Die Standardstufe, Vertraut, ermöglicht Paketregistrierungen und andere zulässige Domänen; Benutzerdefiniert verwendet Ihre eigene Domänenliste. Um den Netzwerkzugriff einer Umgebung zu ändern, öffnen Sie sie zum Bearbeiten und verwenden Sie den Selektor Netzwerkzugriff im Dialog. Eine gemeinsam genutzte Umgebung wird dort schreibgeschützt geöffnet, daher ändert ein Owner ihren Netzwerkzugriff stattdessen auf der Seite Cloud-Umgebungen in den Admin-Einstellungen. Das Steuerelement, das den Selektor öffnet, wird auf den App-Oberflächen angezeigt, die unter Die Standardumgebung aufgelistet sind, und im Editor für geplante Cloud-Aufgaben. Persönliche Umgebungen haben keine separate Seite in Ihren claude.ai-Kontoeinstellungen. Wenn Sie den Netzwerkzugriff einer von Anthropic gehosteten Umgebung ändern, folgen ihre vorhandenen Sitzungen der neuen Einstellung innerhalb von etwa einer Minute für Anfragen, die durch die Netzwerkzulassungsliste der Sitzung gehen. Sie müssen keine neue Sitzung starten.
MCP-Konnektoren, die Sie in einer Sitzung oder geplanten Aufgabe aktivieren, funktionieren, ohne ihre Hosts zu Zulässigen Domänen hinzuzufügen, da der Konnektordatenverkehr über die Server von Anthropic verläuft und nicht über das Netzwerk der Sitzung. Dies basiert auf demselben Anthropic-gebundenen Kanal, der unter Sicherheit und Isolation erwähnt wird. Deaktivieren Sie alle Konnektoren, die Sie nicht benötigen, um einzuschränken, auf welche Tools Claude zugreifen kann.

​
Zugriffsstufen

Das Feld Netzwerkzugriff im Umgebungsdialog akzeptiert eine von vier Stufen: Unabhängig davon, welche Stufe Sie wählen, können Sitzungen diese trotzdem erreichen, da jede einen Pfad nimmt, der nicht durch die Zulassungsliste des Netzwerks der Sitzung verläuft:

​
Bestimmte Domänen zulassen

Um Domänen zuzulassen, die nicht in der Liste „Vertraut“ enthalten sind, wählen Sie Benutzerdefiniert in den Netzwerkzugriffseinstellungen der Umgebung aus und listen Sie dann eine Domäne pro Zeile im Feld Zulässige Domänen auf. Dieses Beispiel ermöglicht drei Hosts, die ein internes Projekt möglicherweise benötigt.
Sitzungen in dieser Umgebung können jetzt auf api.example.com, jede Subdomäne von internal.example.com und registry.example.com zugreifen, und auf keine anderen Domänen über das Netzwerk der Sitzung. GitHub-Datenverkehr, MCP-Konnektordatenverkehr und Anfragen an die Hosts der Netzwerk-Secrets der Umgebung, außer den Hosts, die das Secret niemals erhalten, gehen nicht durch diese Allowlist. Ein führendes *. entspricht jeder Subdomäne. Um die vertrauten Domänen ebenfalls zu behalten, aktivieren Sie Auch Standardliste häufiger Paketmanager einschließen; lassen Sie es deaktiviert, um nur das zuzulassen, was Sie auflisten. Wenn Ihre Organisation Artefakte verwendet, benötigen Sie *.frame.claudeusercontent.com nicht in der Liste, damit Sitzungen diese lesen können. Wenn die Liste diesen Host auslässt, liest Claude Code Artefaktinhalte stattdessen über die Verbindung der Sitzung zu Anthropic. Behalten Sie den Host in einer Zulassungsliste in zwei Situationen:
  • Sitzungen in dieser Umgebung öffnen öffentliche Artefakte einer anderen Organisation: Claude Code ruft diese direkt vom Host ab, daher fügen Sie ihn dieser Liste hinzu.
  • Sie konfigurieren die lokale CLI oder einen selbstgehosteten Runner: Behalten Sie den Host in dieser Zulassungsliste. Siehe Netzwerkzugriffsanforderungen und die Netzwerkanforderungen des selbstgehosteten Runners.
Jede Umgebung hat ihre eigene Liste zulässiger Domänen; es gibt keine Zulassungsliste auf Organisationsebene, die Administratoren an die Umgebungen jedes Mitglieds übertragen können. Auch keine serverseitig verwaltete Einstellung fügt Domänen zur Netzwerkzulassungsliste einer Umgebung hinzu. Um einem Team eine Standardliste zu geben, kann ein Besitzer eine gemeinsam genutzte Organisationsumgebung mit Benutzerdefiniertem Netzwerkzugriff und dieser Liste erstellen.

​
GitHub-Proxy

In von Anthropic gehosteten Umgebungen gehen alle GitHub-Operationen durch einen dedizierten Proxy, der Ihre echten GitHub-Anmeldedaten außerhalb der VM der Sitzung hält, unabhängig von der Zugriffsstufe der Umgebung. Sitzungen in einer selbstgehosteten Umgebung authentifizieren Git-Operationen mit Anmeldedaten, die Ihre Bereitstellung bereitstellt; Git konfigurieren behandelt die Optionen, einschließlich pro-Sitzung ausgegebener Anmeldedaten und einer Opt-in zu diesem gleichen Proxy. Der Proxy bietet:
  • Git-Anmeldedaten: Der Git-Client in der VM verwendet eine begrenzte Anmeldedaten, die der Proxy überprüft und gegen Ihr echtes GitHub-Token austauscht.
  • API-Anfragen: Anfragen von den integrierten GitHub-Tools und von gh unter dem proxy-injected Platzhalter gehen mit Ihren echten Anmeldedaten aus.
  • Push-Einschränkungen: Der Proxy lehnt das Löschen von Branches sowie Pushes von allem ab, was kein Branch ist, etwa einem Tag. Er schränkt nicht ein, welche Branches ein Push aktualisieren kann. Verwenden Sie dafür Branch-Schutzregeln oder Rulesets auf GitHub.
  • Repository-Bereich: Der Proxy bedient GitHub-API-Anfragen für die Repositorys, die an die Sitzung angehängt sind. Eine API-Anfrage für ein anderes Repository erhält einen 403, dessen Meldung mit GitHub access to beginnt und is not enabled for this session enthält. Ein Quellarchiv, das Sie über eine URL github.com/{owner}/{repo}/archive/ oder codeload.github.com abrufen, erhält denselben 403, wenn das Repository nicht angehängt ist, selbst wenn es öffentlich ist.
  • GraphQL-Einschränkungen: Der Proxy lehnt Anfragen an den GraphQL-Endpunkt von GitHub mit einem 403 ab, dessen Meldung mit GitHub GraphQL is not available from Claude Code sessions beginnt und den REST-Fallback gh api repos/{owner}/{repo}/... nennt. gh-Unterbefehle, die GraphQL verwenden, wie gh pr und gh issue, erhalten denselben 403. Die Einschränkung gilt für jede Anfrage durch den Proxy, unabhängig von den Anmeldedaten, die Sie bereitstellen, daher erhält ein GH_TOKEN, das Sie setzen, den gleichen 403. Claude kann nicht auf GitHub-APIs zugreifen, die nur in GraphQL vorhanden sind, wie Projects v2, über den Proxy.
Committete Dateien aus öffentlichen Repositories kommen über raw.githubusercontent.com an, das der Sicherheitsproxy stattdessen verarbeitet. Diese Domäne befindet sich in der Standard-Vertraut-Liste, daher bleiben diese Dateien erreichbar, es sei denn, die Zugriffsstufe der Umgebung schließt sie aus.

​
Sicherheitsproxy

Cloud-Sitzungen in von Anthropic gehosteten Umgebungen laufen hinter einem HTTP/HTTPS-Netzwerk-Proxy für Sicherheits- und Missbrauchspräventionszwecke; in einer selbstgehosteten Umgebung verläuft ausgehender Datenverkehr stattdessen über Ihre eigene Netzwerkgrenze. Der gesamte ausgehende Internetdatenverkehr aus einer von Anthropic gehosteten Sitzung verläuft durch diesen Proxy, der Folgendes bietet:
  • Schutz vor böswilligen Anfragen
  • Ratenbegrenzung und Missbrauchsprävention

​
Was ist in Cloud-Sitzungen verfügbar

In von Anthropic gehosteten Umgebungen erhält jede Sitzung eine frische virtuelle Maschine (VM) mit Ubuntu 24.04 auf x86_64, unabhängig von Ihrem eigenen Betriebssystem und CPU-Architektur, mit Ihrem geklonten Repository und vorinstallierten gängigen Toolchains. Wenn eine Abhängigkeit vorkompilierte Binärdateien bereitstellt, wie Ruby-Gems mit nativen Erweiterungen oder vorgefertigte Python-Wheels, verwenden Sie seinen x86_64 Linux-Build, um die VM zu entsprechen. Dieser Abschnitt behandelt die von Anthropic gehosteten Standardeinstellungen, die integrierten GitHub-Tools, wie man Tests und Services ausführt, die Ressourcenlimits, die jede VM erhält, und die Zeitlimits für langfristige Arbeiten.
Sitzungen, die Ihre Organisation zu einer selbstgehosteten Umgebung leitet, laufen stattdessen auf Ihren eigenen Runnern mit den Tools, die Ihr Runner-Image bereitstellt.

​
Was wird von Ihrem Setup übernommen

Von der Repository-Konfiguration in dieser Tabelle lädt ein Cloud-Thread in einem Projekt nur die CLAUDE.md, die .claude/CLAUDE.md und die .claude/rules/-Dateien aus dem Stammverzeichnis des Repositorys, die nicht pfadspezifisch sind. Siehe Was Threads aus Ihren Repositorys übernehmen.
Cloud-Sitzungen starten aus einem frischen Klon Ihres Repositorys. Alles, das Sie in das Repo committen, ist verfügbar. Alles, das Sie nur auf Ihrem eigenen Computer installiert oder konfiguriert haben, ist nicht in der Sitzung verfügbar. Die Richtlinie Ihrer Organisation kommt separat über Server-verwaltete Einstellungen an. Um Ihre eigene Konfiguration in Cloud-Sitzungen verfügbar zu machen, committen Sie sie in das Repo. Jeder, der die Umgebung nutzt, kann ihre Umgebungsvariablen und ihr Setup-Skript lesen. Der Hinweis des Dialogs unter Umgebungsvariablen sagt dies und warnt vor dem Hinzufügen von Geheimnissen. Speichern Sie in einer von Anthropic gehosteten Umgebung einen Schlüssel, den der Agent-Proxy anhängen kann, stattdessen als Netzwerk-Secret.

​
Persönliche Präferenzen hinzufügen, ohne sie in das Repo zu committen

Fügen Sie in einer von Anthropic gehosteten Umgebung ein Setup-Skript hinzu, das ~/.claude/CLAUDE.md für Präferenzen schreibt, die Sie lieber nicht in ein gemeinsam genutztes Repository aufnehmen möchten. Claude Code lädt diese Datei in der Sitzung als Benutzeranweisungen. Dieses Beispiel legt eine Präferenz für Commit-Nachrichten fest:
Legen Sie das Skript in einer Ihrer eigenen Umgebungen ab statt in einer gemeinsam genutzten. Führen Sie /context in Ihrer nächsten Cloud-Sitzung aus und bestätigen Sie, dass /root/.claude/CLAUDE.md unter Memory files erscheint.

​
Installierte Tools

Cloud-Sitzungen werden mit gängigen Sprach-Runtimes, Build-Tools und Datenbanken vorinstalliert geliefert. Die folgende Tabelle fasst zusammen, was nach Kategorie enthalten ist. ¹ Bun ist installiert, hat aber bekannte Proxy-Kompatibilitätsprobleme beim Paket-Abrufen. Um die Versionen der meisten Tools in dieser Tabelle zu erhalten, bitten Sie Claude, check-tools in einer Cloud-Sitzung auszuführen. Es ist ein Shell-Befehl, der auf der Sitzungs-VM installiert ist, kein Befehl, den Sie mit / eingeben; Sie bitten Claude, weil Claude alle VM-Befehle für Sie ausführt. Für ein Tool, das es nicht meldet, wie Ruby, PHP, bun, PostgreSQL oder Redis, bitten Sie Claude, den Versions-Befehl des Tools selbst auszuführen, zum Beispiel psql --version. Node.js-Versionen sind unter /opt/node20, /opt/node21 und /opt/node22 installiert, mit 22 auf PATH standardmäßig. Um mit einer anderen Version zu arbeiten, bitten Sie Claude, das bin-Verzeichnis dieser Version, wie /opt/node20/bin, PATH voranzustellen. Toolchains außerhalb dieser Liste, wie das .NET SDK, sind nicht vorinstalliert, auch wenn ihre Paketregistrierungen auf der Standard-Allowlist sind. Installieren Sie sie mit einem Setup-Skript.

​
Arbeiten Sie mit GitHub-Issues und Pull Requests

Cloud-Sitzungen enthalten integrierte GitHub-Tools, die Claude Issues lesen, Pull Requests auflisten, Diffs abrufen und Kommentare posten lassen, ohne Setup. Diese Tools authentifizieren sich über den GitHub-Proxy mit der Methode, die Sie unter GitHub-Authentifizierungsoptionen konfiguriert haben, daher gelangt Ihr Token niemals in den Container. Sie können GH_TOKEN oder GITHUB_TOKEN selbst in Umgebungseinstellungen setzen, oder beide ungesetzt lassen und den GitHub-Proxy für Sie authentifizieren lassen:
  • Wenn Sie ein Token setzen, wird es unverändert an den Container übergeben, daher verwenden Ihre Skripte und GitHubs gh CLI es direkt.
  • Wenn Sie keines setzen und der GitHub-Proxy die Authentifizierung für Ihre Sitzung handhabt, lesen beide Variablen als die Platzhalter-Zeichenkette proxy-injected in den Befehlen, die Claude ausführt, und der Proxy ersetzt Ihre echten Anmeldedaten bei ausgehenden GitHub-Anfragen. gh api-Aufrufe für angehängte Repositorys funktionieren ohne ein eigenes Token, aber ein Skript, das GITHUB_TOKEN direkt liest, erhält den Platzhalter, nicht ein verwendbares Token.
Ein Token, das Sie setzen, ist eine gewöhnliche Umgebungsvariable, daher kann jeder, der die Umgebung nutzt, es lesen; der Proxy-Pfad hält die Anmeldedaten aus der Umgebungskonfiguration und der Sitzungs-VM heraus. Um zu überprüfen, welcher Fall auf Ihre Sitzung zutrifft, bitten Sie Claude, echo $GH_TOKEN auszuführen. GitHubs gh CLI ist vorinstalliert. Wenn Sie eine GitHub-Operation benötigen, die die integrierten Tools nicht abdecken, bitten Sie Claude, die REST API mit gh api aufzurufen. gh-Unterbefehle, die die REST API verwenden, wie gh workflow list, funktionieren ebenfalls. Der Proxy lehnt Unterbefehle ab, die GraphQL verwenden, wie gh pr und gh issue. gh liest GH_TOKEN automatisch, daher müssen Sie gh auth login nicht ausführen. Jede Cloud-Sitzung hat eine Transkript-URL auf claude.ai, und die Sitzung kann ihre eigene ID aus der Umgebungsvariable CLAUDE_CODE_REMOTE_SESSION_ID lesen. Verwenden Sie dies, um einen nachverfolgbaren Link in PR-Bodies, Commit-Nachrichten, Slack-Posts oder generierten Berichten zu platzieren, damit ein Reviewer den Lauf öffnen kann, der sie produziert hat. Commits, die Claude in einer Cloud-Sitzung erstellt, enthalten einen Claude-Session: <url> Git-Trailer, und PR-Bodies enthalten die Sitzungs-URL auf einer eigenen Zeile. Um den Trailer und den PR-Body-Link wegzulassen, setzen Sie attribution.sessionUrl auf false. Um den Sitzungs-Link in etwas anderem als einem Commit oder PR einzuschließen, wie einer Slack-Nachricht, die Claude postet, oder einer Berichtsdatei, die es schreibt, lassen Sie Claude den folgenden Befehl ausführen und verwenden Sie seine Ausgabe. Der Befehl konvertiert das cse_-Präfix im Wert der Umgebungsvariable in das session_-Präfix, das die Transkript-URL erwartet:

​
Führen Sie Tests aus, starten Sie Services und fügen Sie Pakete hinzu

Sie erhalten keine Shell in die Sitzungs-VM. Claude führt jeden Befehl für Sie aus, daher formulieren Sie die Aufgaben in diesem Abschnitt als Anfragen in Ihrem Prompt.

​
Führen Sie Tests aus

Claude führt Tests als Teil der Arbeit an einer Aufgabe aus. Bitten Sie darum in Ihrem Prompt, wie „Beheben Sie die fehlgeschlagenen Tests in tests/“ oder „Führen Sie pytest nach jeder Änderung aus.“ Test-Runner, die mit den vorinstallierten Toolchains kommen, wie pytest und cargo test, funktionieren ohne zusätzliches Setup. Ein Runner, den Ihr Projekt als Abhängigkeit deklariert, wie jest, wird mit Ihren Abhängigkeiten installiert.

​
Starten Sie Services

PostgreSQL und Redis sind vorinstalliert, laufen aber standardmäßig nicht. Bitten Sie Claude, diejenigen zu starten, die Sie benötigen; die Befehle, die es ausführt, sind:
Docker ist für die Ausführung von containerisierten Services verfügbar. Bitten Sie Claude, docker compose up auszuführen, um die Services Ihres Projekts zu starten. Der Netzwerkzugriff zum Abrufen von Images folgt der Zugriffsstufe Ihrer Umgebung, und die Trusted-Standardeinstellungen enthalten Docker Hub und andere gängige Registrierungen. Wenn Ihre Images groß oder langsam zum Abrufen sind, fügen Sie docker compose pull oder docker compose build zu Ihrem Setup-Skript hinzu. Der Umgebungs-Cache behält die abgerufenen Images, daher hat jede neue Sitzung sie auf der Festplatte. Der Cache speichert nur Dateien, keine laufenden Prozesse, daher startet Claude die Container in jeder Sitzung trotzdem.

​
Fügen Sie Pakete hinzu

Um Pakete hinzuzufügen, die nicht vorinstalliert sind, verwenden Sie ein Setup-Skript. Der Umgebungs-Cache behält das, was das Skript installiert, daher sind Pakete, die Sie dort installieren, am Anfang jeder Sitzung verfügbar, ohne jedes Mal neu zu installieren. Sie können Claude auch bitten, Pakete während der Sitzung zu installieren, aber diese Installationen werden nicht auf andere Sitzungen übertragen.

​
Ressourcenlimits

Cloud-Sitzungen in von Anthropic gehosteten Umgebungen laufen mit ungefähren Ressourcen-Obergrenzen, die sich im Laufe der Zeit ändern können:
  • 4 vCPUs
  • 16 GB RAM
  • 30 GB Festplatte
Die VM kann Aufgaben stoppen, die erheblich mehr Speicher benötigen, wie große Build-Jobs oder speicherintensive Tests. Für Workloads jenseits dieser Limits verwenden Sie Remote Control, um Claude Code auf Ihrer eigenen Hardware auszuführen, oder führen Sie Cloud-Sitzungen in einer selbstgehosteten Umgebung auf Compute aus, die Ihre Organisation betreibt.

​
Zeitlimits

In von Anthropic gehosteten Umgebungen gelten diese Zeitlimits für langfristige Arbeiten in einer Cloud-Sitzung, wie ein Build, eine Installation oder ein Test-Lauf. Jeder Eintrag verlinkt auf den Abschnitt, der das Limit definiert.
  • Befehle, die Claude ausführt: Eine Cloud-Umgebung setzt kein eigenes Befehls-Timeout, daher gelten die Standardeinstellungen des Bash-Tools. Claude wartet standardmäßig 2 Minuten auf einen Vordergrundbefehl und kann bis zu 10 Minuten anfordern. Wenn ein Befehl sein Timeout erreicht, verschiebt Claude Code ihn in den Hintergrund, anstatt ihn zu stoppen, es sei denn, der Befehl beginnt mit sleep. Ein Befehl, der auf diese Weise verschoben wird, kann bis zu 30 weitere Minuten laufen, bevor Claude Code ihn bei seinem Hintergrund-Zeitlimit stoppt. Das Setzen von BASH_DEFAULT_TIMEOUT_MS über 1800000 Millisekunden verlängert dieses Limit sowie die Vordergrund-Standardeinstellung.
  • SessionStart-Hooks: Claude Code bricht einen command-Hook nach 600 Sekunden ab, es sei denn, Sie setzen timeout in Sekunden auf dem Hook-Eintrag. Claude Code erzwingt das Timeout nicht auf einem Hook, den Sie mit async: true ausführen.
  • Setup-Skript: Ein Skript, das länger als ungefähr fünf Minuten dauert, wird nicht gecacht. Script-Anforderungen behandelt, wie Sie darunter bleiben.
  • Untätige Sitzungen: Nach ein paar Minuten ohne Aktivität pausiert die VM einer Sitzung mit ihren Dateien gespeichert, und eine pausierte VM kann später freigegeben werden. Umgebungsvariablen setzen beschreibt, was eine Sitzung in jedem Fall aufgreift, und Environment expired behandelt, wie Sie eine Sitzung erneut öffnen, deren VM freigegeben wurde.
Um die Befehls-Timeouts für die Sitzungen einer Umgebung zu erhöhen, fügen Sie BASH_DEFAULT_TIMEOUT_MS und BASH_MAX_TIMEOUT_MS zu ihren Umgebungsvariablen hinzu. Beide nehmen Millisekunden. Zum Beispiel macht BASH_DEFAULT_TIMEOUT_MS=600000 10 Minuten zur Standardeinstellung.

​
Setup-Skripte

Ein Setup-Skript ist ein Bash-Skript, das ausgeführt wird, wenn eine neue Cloud-Sitzung startet, bevor Claude Code gestartet wird. Verwenden Sie Setup-Skripte, um Abhängigkeiten zu installieren, Tools zu konfigurieren oder alles zu beschaffen, das die Sitzung benötigt und nicht vorinstalliert ist. Skripte werden als Root auf Ubuntu 24.04 ausgeführt, daher funktionieren apt install und die meisten Sprachpaket-Manager.

​
Ein Setup-Skript hinzufügen

Um Ihrer eigenen Umgebung ein Setup-Skript hinzuzufügen, können Sie es eingeben oder einfügen oder eine Textdatei wie setup.sh laden. Fügen Sie die Umgebung hinzu oder bearbeiten Sie sie und wählen Sie die Zeile Setup-Skript aus. Geben Sie das Skript in das sich öffnende Feld ein, oder wählen Sie Datei auswählen, um den Inhalt des Felds durch den Text einer Datei mit bis zu 64 KB zu ersetzen. Wählen Sie anschließend Umgebung hinzufügen oder Änderungen speichern aus. Dieses Beispiel installiert ShellCheck, das nicht vorinstalliert ist.

​
Anforderungen an Skripte

Ein Setup-Skript hat vier Einschränkungen, die Sie beachten müssen:
  • Mit Null beenden: Wenn das Skript mit einem Nicht-Null-Wert beendet wird, schlägt der Sitzungsstart fehl. Fügen Sie || true an nicht kritische Befehle an, damit ein gelegentlicher Installationsfehler die Sitzung nicht blockiert.
  • Innerhalb von fünf Minuten fertig: Halten Sie die Gesamtlaufzeit des Skripts unter etwa fünf Minuten, damit der Umgebungs-Cache erstellt werden kann. Wenn Setup länger dauert, wird die Umgebung nicht zwischengespeichert. Führen Sie unabhängige Installationen parallel mit & und wait aus, und verschieben Sie jeden einzelnen Download, der nicht passt, in einen SessionStart-Hook, der ihn im Hintergrund startet. Wenn neue Sitzungen während des Setups hängen bleiben oder zeitüberschreitung auftreten, siehe Neue Sitzungen hängen oder zeitüberschreitung während des Setups.
  • Netzwerkzugriff für Installationen: Paketinstallationen müssen Registries erreichen. Die Standard-Stufe Vertraut deckt häufige Paket-Registries ab, einschließlich npm, PyPI, RubyGems und crates.io; mit Keine Netzwerkzugriff schlagen Installationen fehl.
  • Die Variablen der Umgebung sind noch nicht gesetzt: Das Skript wird ausgeführt, bevor die Sitzung die Umgebungsvariablen der Umgebung setzt. Setzen Sie jeden Wert, den das Skript benötigt, im Skript selbst.

​
Umgebungs-Caching

Das Setup-Skript wird beim ersten Mal ausgeführt, wenn Sie eine Sitzung in einer Umgebung starten. Wenn das Setup innerhalb von etwa fünf Minuten abgeschlossen ist, erstellt Anthropic einen Snapshot des Dateisystems und verwendet diesen Snapshot als Ausgangspunkt für spätere Sitzungen. Neue Sitzungen starten mit Ihren Abhängigkeiten, Tools und Docker-Images bereits auf der Festplatte und überspringen den Setup-Skript-Schritt. Dies hält den Start schnell, auch wenn das Skript große Toolchains installiert oder Container-Images abruft. Wenn Setup länger als etwa fünf Minuten dauert, wird die Umgebung nicht zwischengespeichert. Der Cache ist ein Dateisystem-Snapshot, daher behält er, was das Setup-Skript auf die Festplatte schreibt, und verliert alles, das nur ausgeführt wurde. Pakete, die Sie installieren, Docker-Images, die Sie abrufen, und Dateien, die Sie schreiben, werden alle übertragen. Eine Datenbank, die das Skript gestartet hat, ein docker compose up-Stack oder ein anderer Hintergrundprozess nicht; starten Sie diese pro Sitzung, indem Sie Claude fragen oder einen SessionStart-Hook verwenden. Das Setup-Skript wird erneut ausgeführt, um den Cache neu zu erstellen, wenn Sie das Setup-Skript oder die zulässigen Netzwerk-Hosts der Umgebung ändern, und wenn der Cache nach etwa sieben Tagen abläuft. In einer von Anthropic gehosteten Umgebung wird das Setup-Skript nicht ausgeführt, wenn die VM einer Sitzung nach Leerlauf wiederhergestellt wird, daher erreicht eine Änderung des Skripts eine bestehende Sitzung nur, wenn ihre VM zurückgefordert und neu erstellt wurde. Um eine Änderung sofort anzuwenden, führen Sie die Befehle in der Sitzung aus oder starten Sie eine neue Sitzung. Sie müssen Caching nicht aktivieren oder Snapshots selbst verwalten.

​
Setup-Skripte vs. SessionStart-Hooks

Verwenden Sie ein Setup-Skript, um die VM selbst bereitzustellen: Toolchains und CLI-Tools, die nicht vorinstalliert sind. Verwenden Sie einen SessionStart-Hook für die Projekteinrichtung, die überall ausgeführt werden sollte, lokal und in der Cloud, wie npm install. Setup-Skripte und SessionStart-Hooks werden in einer festen Reihenfolge ausgeführt, wenn eine Cloud-Sitzung startet. Die Tabelle vergleicht, wo Sie sie konfigurieren, wann sie ausgeführt werden und wo sie ausgeführt werden. Wenn Sie SessionStart-Hooks in Ihrer Benutzer-Ebene ~/.claude/settings.json haben, erwarten Sie diese nicht in der Cloud. Benutzer-Ebene-Einstellungen bleiben auf Ihrem Computer. Welche anderen Hooks ausgeführt werden, hängt davon ab, wo die Sitzung ausgeführt wird:
  • Von Anthropic gehostete Umgebung: Claude Code führt Hooks aus den servergesteuerten Einstellungen Ihrer Organisation und, außerhalb eines Threads in einem Projekt, aus dem Repository aus. Claude Tag-Sitzungen erhalten keine servergesteuerten Einstellungen, daher werden Hooks aus servergesteuerten Einstellungen dort nicht ausgeführt.
  • Selbst gehostete Umgebung: Claude Code führt auch die Hooks aus, die der Operator aus dem ~/.claude/ des Runner-Hosts gesät hat, und die Hooks in der verwalteten Einstellungsdatei des Runner-Images, wenn diese Datei eine der verwalteten Quellen ist, die Claude Code anwendet.

​
Abhängigkeiten mit einem SessionStart-Hook installieren

Um Abhängigkeiten nur in Cloud-Sitzungen außerhalb der Threads eines Projekts zu installieren, kombinieren Sie einen SessionStart-Hook mit einem Skript, das überprüft, wo es ausgeführt wird. Fügen Sie zunächst einen SessionStart-Hook zu Ihrer .claude/settings.json des Repositorys hinzu. Diese Konfiguration weist Claude Code an, scripts/install_pkgs.sh aus Ihrem Repository auszuführen, wenn eine Sitzung startet oder fortgesetzt wird:
Der matcher begrenzt den Hook auf die startup- und resume-Ereignisse, und $CLAUDE_PROJECT_DIR wird zur Repository-Root aufgelöst, daher findet der Hook das Skript unabhängig vom Arbeitsverzeichnis der Sitzung. Erstellen Sie anschließend das Skript unter scripts/install_pkgs.sh. Es wird sofort außerhalb der Cloud beendet und installiert dann Ihre Abhängigkeiten. Es überspringt npm install, solange package.json, package-lock.json und das Skript selbst seit der letzten erfolgreichen Installation unverändert sind:
Die CLAUDE_CODE_REMOTE-Überprüfung ist das, was die Installation auf Cloud-Sitzungen beschränkt: Die Umgebung der Sitzungs-VM trägt diese Variable als true, sie ist lokal nie true, daher beendet sich das Skript auf Ihrem Laptop, bevor es etwas installiert. Um zu bestätigen, dass npm install erfolgreich war, starten Sie eine Cloud-Sitzung und bitten Sie Claude, node_modules/.install_pkgs.sha256 anzuzeigen. Die Datei listet einen Hash für jede der drei Dateien auf. Wenn die Datei fehlt, bitten Sie Claude, npm install auszuführen und den Fehler zu melden.
Wenn npm install weitere Dateien liest, etwa die package.json eines Workspace, eine .npmrc oder die Eingaben Ihres postinstall-Skripts, fügen Sie diese dem sha256sum-Befehl hinzu, der die Hashes speichert. Andernfalls behalten Sie nach einer Änderung an einer dieser Dateien die alten Pakete.

​
Einschränkungen in Cloud-Sitzungen

SessionStart-Hooks verhalten sich in der Cloud genauso wie lokal, mit diesen Vorbehalten:
  • Ein Repository pro Sitzung: In einer von Anthropic gehosteten Umgebung lädt eine Sitzung mit mehreren Repositorys keine Hooks aus der .claude/settings.json eines Repositorys, daher wird ein SessionStart-Hook, den Sie dort definieren, nicht ausgeführt. Installieren Sie Abhängigkeiten für diese Sitzungen stattdessen mit einem Setup-Skript. Für eine selbst gehostete Umgebung siehe welche Repository-Einstellungen gelten.
  • Nicht in den Cloud-Threads eines Projekts: Ein Cloud-Thread in einem Projekt führt keine Hooks aus der .claude/settings.json eines Repositorys aus, unabhängig von der Anzahl der Repositorys. Installieren Sie in einer von Anthropic gehosteten Umgebung Abhängigkeiten für Threads mit einem Setup-Skript. Verwenden Sie in einer selbst gehosteten Umgebung stattdessen einen Hook in den Einstellungen des Runner-Hosts.
  • Keine Cloud-Only-Scoping: Hooks werden in lokalen und Cloud-Sitzungen ausgeführt. Um die lokale Ausführung zu überspringen, beenden Sie früh, es sei denn, die Umgebungsvariable CLAUDE_CODE_REMOTE ist true, wie das Abhängigkeitsinstallations-Skript es tut.
  • Erfordert Netzwerkzugriff: Installationsbefehle müssen Paket-Registries erreichen. Wenn Ihre Umgebung Keine Netzwerkzugriff verwendet, schlagen diese Hooks fehl. Die Standard-Zulassungsliste unter Vertraut deckt npm, PyPI, RubyGems und crates.io ab.
  • Proxy-Kompatibilität: In von Anthropic gehosteten Umgebungen wird der gesamte ausgehende Datenverkehr durch einen Sicherheits-Proxy geleitet, und einige Paket-Manager funktionieren nicht korrekt damit; Bun ist ein bekanntes Beispiel. In einer selbst gehosteten Umgebung wird der ausgehende Datenverkehr stattdessen durch Ihre eigene Netzwerk-Grenze geleitet.
  • Fügt Startup-Latenz hinzu: Hooks werden jedes Mal ausgeführt, wenn eine Sitzung startet oder fortgesetzt wird, im Gegensatz zu Setup-Skripten, die vom Umgebungs-Caching profitieren. Halten Sie Installationsskripte schnell, indem Sie bereits erledigte Arbeit überspringen, wie es das Abhängigkeitsinstallations-Skript tut.
Um das Basis-Image anzupassen, verwenden Sie ein Setup-Skript, um das zu installieren, was Sie auf dem bereitgestellten Image benötigen, oder führen Sie Ihr eigenes Image als Container neben Claude mit docker compose aus. Das vollständige Ersetzen des Basis-Images wird noch nicht unterstützt.

​
Standard-zulässige Domänen

Mit Trusted-Netzwerkzugriff können Sitzungen standardmäßig die folgenden Domänen erreichen. Domänen, die mit * gekennzeichnet sind, zeigen Wildcard-Subdomain-Matching an, daher erlaubt *.gcr.io jede Subdomain von gcr.io.
  • api.anthropic.com
  • docs.claude.com
  • platform.claude.com
  • code.claude.com
  • claude.ai
  • claude.com
  • support.claude.com
  • anthropic.com
  • www.anthropic.com
  • github.com
  • www.github.com
  • api.github.com
  • npm.pkg.github.com
  • raw.githubusercontent.com
  • pkg-npm.githubusercontent.com
  • objects.githubusercontent.com
  • release-assets.githubusercontent.com
  • codeload.github.com
  • avatars.githubusercontent.com
  • camo.githubusercontent.com
  • gist.github.com
  • gitlab.com
  • www.gitlab.com
  • registry.gitlab.com
  • bitbucket.org
  • www.bitbucket.org
  • api.bitbucket.org
  • registry-1.docker.io
  • auth.docker.io
  • index.docker.io
  • hub.docker.com
  • www.docker.com
  • production.cloudflare.docker.com
  • production.cloudfront.docker.com
  • download.docker.com
  • gcr.io
  • *.gcr.io
  • ghcr.io
  • mcr.microsoft.com
  • *.data.mcr.microsoft.com
  • public.ecr.aws
  • cloud.google.com
  • accounts.google.com
  • gcloud.google.com
  • *.googleapis.com
  • storage.googleapis.com
  • compute.googleapis.com
  • container.googleapis.com
  • azure.com
  • portal.azure.com
  • microsoft.com
  • www.microsoft.com
  • *.microsoftonline.com
  • packages.microsoft.com
  • dotnet.microsoft.com
  • dot.net
  • visualstudio.com
  • dev.azure.com
  • *.amazonaws.com
  • *.api.aws
  • oracle.com
  • www.oracle.com
  • java.com
  • www.java.com
  • java.net
  • www.java.net
  • download.oracle.com
  • yum.oracle.com
  • *.r2.cloudflarestorage.com
  • proxy.golang.org
  • sum.golang.org
  • index.golang.org
  • golang.org
  • www.golang.org
  • goproxy.io
  • pkg.go.dev
  • maven.org
  • repo.maven.org
  • central.maven.org
  • repo1.maven.org
  • repo.maven.apache.org
  • maven.google.com
  • jcenter.bintray.com
  • gradle.org
  • www.gradle.org
  • services.gradle.org
  • plugins.gradle.org
  • plugins-artifacts.gradle.org
  • kotlinlang.org
  • www.kotlinlang.org
  • spring.io
  • repo.spring.io
  • dl.k8s.io (Kubernetes)
  • pkgs.k8s.io
  • k8s.io
  • www.k8s.io
  • releases.hashicorp.com (HashiCorp)
  • apt.releases.hashicorp.com
  • rpm.releases.hashicorp.com
  • archive.releases.hashicorp.com
  • hashicorp.com
  • www.hashicorp.com
  • repo.anaconda.com (Anaconda/Conda)
  • conda.anaconda.org
  • anaconda.org
  • www.anaconda.com
  • anaconda.com
  • continuum.io
  • apache.org (Apache)
  • www.apache.org
  • archive.apache.org
  • downloads.apache.org
  • eclipse.org (Eclipse)
  • www.eclipse.org
  • download.eclipse.org
  • nodejs.org (Node.js)
  • www.nodejs.org
  • developer.apple.com
  • developer.android.com
  • pkg.stainless.com
  • binaries.prisma.sh
  • http-intake.logs.datadoghq.com
  • *.datadoghq.com
  • *.datadoghq.eu
  • api.honeycomb.io
  • sourceforge.net
  • *.sourceforge.net
  • packagecloud.io
  • *.packagecloud.io
  • fonts.googleapis.com
  • fonts.gstatic.com
  • *.modelcontextprotocol.io