Cloud-Umgebungen konfigurieren

Konfigurieren Sie Cloud-Umgebungen für Claude Code Cloud-Sitzungen: Netzwerkzugriffsstufen, Umgebungsvariablen, Setup-Skripte und Umgebungs-Caching.

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, auf Pro- und Max-Plänen API-Anmeldedaten 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: die Desktop-App, die Claude Mobile-App, Ihr Browser unter claude.ai/code, das Terminal mit claude --cloud, Routinen und Claude Tag. 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.

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 Web-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:

• Vertrauenswürdiger Netzwerkzugriff: Sitzungen erreichen Paketregistrierungen und andere auf die Whitelist gesetzte Domänen und sonst nichts über das Netzwerk der Sitzung.
• Keine andere Konfiguration: Standard definiert keine Umgebungsvariablen oder Setup-Skripte, daher starten Sitzungen nur mit den vorinstallierten Tools.

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

Erstellen, bearbeiten und archivieren Sie Umgebungen über den Umgebungswähler, den Sie unter claude.ai/code nach dem Web-Onboarding oder über das Eingabefeld in der Desktop-App erreichen. 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.

1

Öffnen Sie den Umgebungswähler

Wählen Sie auf claude.ai/code das Cloud-Symbol aus, das den Namen der aktuellen Umgebung anzeigt, in der Zeile über dem Nachrichtenfeld. Es gibt keine Einstellungsseite oder direkte URL für den Wähler.

2

Fügen Sie eine Umgebung hinzu oder bearbeiten Sie sie

Wählen Sie Cloud-Umgebung hinzufügen oder bewegen Sie den Mauszeiger über eine vorhandene Umgebung und wählen Sie das Einstellungssymbol aus, das auf der rechten Seite angezeigt wird. Der Dialog enthält den Namen, die Netzwerkzugriffsstufe, Umgebungsvariablen und ein Setup-Skript. Wenn Sie eine vorhandene Cloud-Umgebung in einem Pro- oder Max-Plan bearbeiten, enthält der Dialog auch API-Anmeldedaten.

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.

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

Jede Sitzung kopiert die Werte der Umgebung einmal beim Start in gewöhnliche Umgebungsvariablen, die jeder Befehl, den Claude ausführt, lesen kann. Da laufende Sitzungen die Konfiguration nicht erneut lesen, wirken sich Änderungen oder das Hinzufügen von Variablen auf Sitzungen aus, die Sie danach starten; Sitzungen, die bereits laufen, behalten die Werte, mit denen sie gestartet wurden.

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 Pro- und Max-Plänen stattdessen eine API-Anmeldedaten für einen Schlüssel, den der Agent-Proxy an eine Anfrage anhängen kann. Die Anfragen, die niemals eine Anmeldedaten erhalten, sind dort aufgelistet.

Fügen Sie API-Anmeldedaten hinzu

Eine API-Anmeldedaten 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. Der Schlüssel erreicht niemals Claude, die Befehle, die er ausführt, oder die Umgebungsvariablen der Sitzung.

API-Anmeldedaten sind in Pro- und Max-Plänen verfügbar. Sie sind in Team- oder Enterprise-Plänen noch nicht verfügbar, daher erscheint der Bereich API-Anmeldedaten im Umgebungsdialog in diesen Plänen nicht.

Anforderungen

Zwei davon entscheiden, ob Sie eine Anmeldedaten hinzufügen können, und zwei entscheiden, ob der Agent-Proxy sie nach dem Hinzufügen verwenden kann:

• Rolle: eine Organisationsadministrator-Rolle in Ihrer claude.ai-Organisation
  • In Team und Enterprise halten sie Owner und Admins nicht
  • In Pro und Max halten Sie sie in Ihrer eigenen Organisation
  • Ohne sie sehen Sie einen Hinweis statt der Anmeldedatenliste, auch in Ihren eigenen Umgebungen. Bitten Sie einen Owner, die Anmeldedaten zu einer gemeinsamen Umgebung hinzuzufügen und Ihre Sitzungen dort auszuführen
• Umgebungstyp: eine von Anthropic gehostete Cloud-Umgebung, die bereits existiert. Eine selbst gehostete Umgebung hat keine API-Anmeldedaten
• 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 Anmeldedaten speichern

Fügen Sie eine Anmeldedaten hinzu

Sie fügen Anmeldedaten einzeln aus dem Editor einer Umgebung hinzu, die bereits existiert. Der Dialog für eine neue Umgebung bietet sie nicht an. Es gibt auch keine Bearbeitung. Um die Hosts oder den Wert einer Anmeldedaten zu ändern, löschen Sie sie und fügen Sie sie erneut hinzu.

Um zu bestätigen, dass die Anmeldedaten funktionieren, 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 eine Anmeldedaten stattdessen als Nicht gesendet markiert, sagt der Hinweis darunter, warum und was zu tun ist. Zwei Anmeldedaten, deren Hosts sich überlappen, ohne genau übereinzustimmen, erhalten keine Markierung, und der Agent-Proxy sendet nur eine davon.

Welche Anfragen erhalten die Anmeldedaten

Der Agent-Proxy fügt eine Anmeldedaten an eine Anfrage an, wenn der Host der Anfrage mit einem übereinstimmt, den Sie auf dieser Anmeldedaten 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 die Anmeldedaten erhalten. Die Anmeldedaten gelten in jeder Sitzung, die in der Umgebung ausgeführt wird, wer sie auch gestartet hat, bis Sie sie löschen.

Anfragen, die niemals die Anmeldedaten erhalten

Der Agent-Proxy fügt niemals eine Anmeldedaten, die Sie hinzufügen, zu diesen Anfragen hinzu:

• GitHub: der GitHub-Proxy authentifiziert stattdessen Anfragen an GitHub, daher benötigen Sie keine API-Anmeldedaten 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

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 und wählen Sie Archivieren. Ein Owner archiviert eine gemeinsame Umgebung von der Seite Cloud-Umgebungen in den Admin-Einstellungen. Sie können eine Umgebung nicht löschen, nur archivieren.

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.
• API-Anmeldedaten 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. 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, und ansonsten in der ersten Umgebung in Ihrer Liste, die keine Remote Control-Bridge-Umgebung ist. Alles, das explizit mit der Umgebung konfiguriert ist, wie eine Routine, kann keine neuen Sitzungen darin starten. Zeigen Sie es auf eine andere Umgebung.

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 Routinen, 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.

Die Sitzungen jedes Mitglieds in einer gemeinsamen Umgebung lesen ihre Variablen, daher fügen Sie keine Geheimnisse darin ein. API-Anmeldedaten, die Sitzungen einen Schlüssel geben, den sie nicht lesen können, sind in Team- oder Enterprise-Plänen noch nicht verfügbar.

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:

• Legen Sie eine gemeinsame oder selbst gehostete Umgebung als die Standardumgebung der Organisation unter claude.ai/admin-settings/claude-code fest.
• Heften Sie eine an einen Kanal in den Claude Tag-Admin-Einstellungen.

Netzwerkzugriff

Jede Umgebung setzt eine Netzwerkzugriffsstufe, die die ausgehenden Verbindungen steuert, die ihre Sitzungen herstellen können. Die Standard-Stufe, Trusted, erlaubt Paketregistrierungen und andere auf die Whitelist gesetzte Domänen; Custom nimmt Ihre eigene Domänenliste.

Um die Netzwerkzugriffsstufe einer Umgebung zu ändern, öffnen Sie sie zur Bearbeitung und verwenden Sie den Network access-Selector im Dialog. Eine gemeinsame Umgebung öffnet sich dort schreibgeschützt, daher ändert ein Owner seinen Netzwerkzugriff stattdessen von der Seite Cloud environments in den Admin-Einstellungen. Das Cloud-Symbol, das den Selector öffnet, erscheint auf den App-Oberflächen, die unter Die Standard-Umgebung aufgelistet sind, und im Routine-Editor; persönliche Umgebungen haben keine separate Seite in Ihren claude.ai-Kontoeinstellungen.

Zugriffsstufen

Das Feld Network access im Umgebungs-Dialog nimmt eine von vier Stufen:

Welche Stufe Sie auch wählen, Sitzungen können diese immer noch erreichen, da jede einen Pfad nimmt, der nicht durch die Netzwerk-Whitelist der Sitzung geht:

• GitHub, durch seinen separaten Proxy
• MCP-Konnektoren, die Sie aktivieren, deren Verkehr über Anthropic-Server verläuft
• Die Hosts, die Sie auf den API-Anmeldedaten der Umgebung aufgelistet haben, außer den Hosts, die der Agent-Proxy überspringt
• Die Anthropic-API, für Claude Code-eigene Anfragen, auch bei None, wie unter Security and isolation erwähnt

Erlauben Sie bestimmte Domänen

Um Domänen zu erlauben, die nicht in der Trusted-Liste sind, wählen Sie Custom in den Netzwerkzugriff-Einstellungen der Umgebung, dann listen Sie eine Domäne pro Zeile im Feld Allowed domains auf. Dieses Beispiel erlaubt drei Hosts, die ein internes Projekt benötigen könnte.

api.example.com
*.internal.example.com
registry.example.com

Sitzungen in dieser Umgebung können jetzt api.example.com, jede Subdomain von internal.example.com und registry.example.com erreichen, und keine anderen Domänen über das Netzwerk der Sitzung. GitHub-Verkehr, MCP-Konnektoren-Verkehr und Anfragen an die Hosts der API-Anmeldedaten der Umgebung, außer den Hosts, die der Agent-Proxy überspringt, gehen nicht durch diese Whitelist. Ein führendes *. passt zu jeder Subdomain. Um die Trusted-Domänen auch zu behalten, aktivieren Sie Also include default list of common package managers; lassen Sie es deaktiviert, um nur das zu erlauben, was Sie auflisten.

Wenn Ihre Organisation Artifacts verwendet, benötigen Sie *.frame.claudeusercontent.com nicht in der Liste, damit Sitzungen sie lesen können. Wenn die Liste diesen Host auslässt, liest Claude Code Artifact-Inhalte stattdessen über die Verbindung der Sitzung zu Anthropic. Behalten Sie den Host in einer Whitelist in zwei Situationen:

• Sitzungen in dieser Umgebung öffnen öffentliche Artifacts einer anderen Organisation: Claude Code ruft diese direkt vom Host ab, daher fügen Sie ihn zu dieser Liste hinzu.
• Sie konfigurieren die lokale CLI oder einen selbstgehosteten Runner: behalten Sie den Host in dieser Whitelist. Siehe Netzwerkzugriff-Anforderungen und die selbstgehosteten Netzwerk-Anforderungen.

Jede Umgebung hat ihre eigene Whitelist für zulässige Domänen; es gibt keine Organisations-Whitelist, die Administratoren an die Umgebungen jedes Mitglieds pushen können. Server-verwaltete Einstellungen gelten immer noch in Cloud-Sitzungen, aber keine von ihnen fügt Domänen zur Netzwerk-Whitelist der Umgebung hinzu. Um einem Team eine Standard-Liste zu geben, kann ein Owner eine organisationsweite gemeinsame Umgebung mit Custom-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 Sitzungs-VM hält, unabhängig von der Zugriffsstufe der Umgebung. Sitzungen in einer selbstgehosteten Umgebung authentifizieren Git-Operationen mit Anmeldedaten, die Ihre Bereitstellung bereitstellt; Configure git behandelt die Optionen, einschließlich pro-Sitzung geprägter Anmeldedaten und eines 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 Ihren echten 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-Schutz: git push funktioniert nur gegen den aktuellen Arbeitszweig der Sitzung; Klonen, Abrufen und PR-Operationen funktionieren normal.
• Repository-Bereich: GitHub-API und Release-Asset-Anfragen erreichen nur Repositories, die an die Sitzung angehängt sind, daher erhält ein Setup-Skript, das Release-Assets aus einem nicht angehängten Repository herunterlädt, einen 403.
• GraphQL-Einschränkungen: der Proxy bedient nur einen angehefteten Satz von GraphQL-Operationen für Pull-Request-Workflows. Der Proxy lehnt alles andere auf dem GraphQL-Endpunkt mit einem 403 ab, der sagt This GraphQL query is not enabled for this session und nennt den REST-Fallback, gh api repos/{owner}/{repo}/.... 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, den Sie setzen, den gleichen 403. Claude kann GitHub-APIs, die nur in GraphQL existieren, wie Projects v2, nicht durch den Proxy erreichen.

Committed-Dateien aus öffentlichen Repositories kommen über raw.githubusercontent.com an, das der Sicherheits-Proxy stattdessen handhabt. Diese Domäne ist in der Standard-Trusted-Liste, daher bleiben diese Dateien erreichbar, es sei denn, die Zugriffsstufe der Umgebung schließt sie aus.

Sicherheits-Proxy

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 Verkehr stattdessen durch Ihre eigene Netzwerk-Grenze. Der gesamte ausgehende Internet-Verkehr aus einer von Anthropic gehosteten Sitzung verläuft durch diesen Proxy, der Folgendes bietet:

• Schutz vor böswilligen Anfragen
• Ratenbegrenzung und Missbrauchsprävention
• Inhaltsfilterung für erhöhte Sicherheit
• Ein DNS-Audit-Trail der angeforderten Hostnamen

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 und die Ressourcenlimits, die jede VM erhält.

Was wird von Ihrem Setup übernommen

Cloud-Sitzungen starten aus einem frischen Klon Ihres Repositories. 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 Setup-Skripte lesen. Der Hinweis des Dialogs unter Umgebungsvariablen sagt dies und warnt vor dem Hinzufügen von Geheimnissen. Auf Pro- und Max-Plänen speichern Sie einen Schlüssel, den der Agent-Proxy anhängen kann, als API-Anmeldedaten stattdessen.

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, zu PATH voranstellen.

Toolchains außerhalb dieser Liste, wie das .NET SDK, sind nicht vorinstalliert, auch wenn ihre Paketregistrierungen auf der Standard-Whitelist 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 betritt Ihr Token niemals 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 einen Token setzen, wird er unverändert an den Container übergeben, daher verwenden Ihre Skripte und GitHub's gh CLI ihn direkt.
• Wenn Sie keinen 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 funktioniert ohne einen Token von Ihnen, aber ein Skript, das GITHUB_TOKEN direkt liest, erhält den Platzhalter, nicht einen verwendbaren Token.

Ein Token, den Sie setzen, ist eine gewöhnliche Umgebungsvariable, daher kann jeder, der die Umgebung nutzt, ihn lesen; der Proxy-Pfad hält die Anmeldedaten aus der Umgebungskonfiguration und der Sitzungs-VM.

Um zu überprüfen, welcher Fall auf Ihre Sitzung zutrifft, bitten Sie Claude, echo $GH_TOKEN auszuführen.

GitHub's gh CLI ist vorinstalliert. Wenn Sie einen gh-Befehl benötigen, den die integrierten Tools nicht abdecken, wie gh release oder gh workflow run, bitten Sie Claude, ihn auszuführen. gh liest GH_TOKEN automatisch, daher müssen Sie gh auth login nicht ausführen.

Verknüpfen Sie die Ausgabe zurück zur Sitzung

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 ihrer eigenen Zeile. Um den Trailer und den PR-Body-Link zu weglassen, setzen Sie attribution.sessionUrl auf false.

Um den Sitzungs-Link in etwas anderem als einem Commit oder PR einzuschließen, wie eine Slack-Nachricht, die Claude postet, oder eine Berichtsdatei, die sie 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:

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID/#cse_/session_}"

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, installiert sich mit Ihren Abhängigkeiten.

Starten Sie Services

PostgreSQL und Redis sind vorinstalliert, aber nicht standardmäßig laufen. Bitten Sie Claude, diejenigen zu starten, die Sie benötigen; die Befehle, die es ausführt, sind:

service postgresql start

service redis-server start

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 immer noch jede Sitzung.

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 mid-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.

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.

Um ein Setup-Skript hinzuzufügen, öffnen Sie den Dialog für Umgebungseinstellungen und geben Sie Ihr Skript in das Feld Setup-Skript ein.

Dieses Beispiel installiert ShellCheck, das nicht vorinstalliert ist.

#!/bin/bash
apt update && apt install -y shellcheck

Anforderungen an Skripte

Ein Setup-Skript hat drei 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. 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.
• 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.

Umgebungs-Caching

Das Setup-Skript wird beim ersten Mal ausgeführt, wenn Sie eine Sitzung in einer Umgebung starten. Nach Abschluss 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.

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. Das Fortsetzen einer bestehenden Sitzung führt das Setup-Skript nie erneut aus.

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 dem Repository und aus den servergesteuerten Einstellungen Ihrer Organisation aus.
• 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 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:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/install_pkgs.sh"
          }
        ]
      }
    ]
  }
}

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:

#!/bin/bash

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

npm install
pip install -r requirements.txt
exit 0

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.

Zusammen geben die beiden Dateien jeder Cloud-Sitzung beim Start ein frisches npm install und pip install, während lokale Sitzungen unberührt bleiben.

Einschränkungen in Cloud-Sitzungen

SessionStart-Hooks verhalten sich in der Cloud genauso wie lokal, mit diesen Vorbehalten:

• Ein Repository pro Sitzung: Eine Sitzung mit mehreren Repositorys lädt 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.
• 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 überprüfen, ob Abhängigkeiten bereits vorhanden sind, bevor Sie sie neu installieren.

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.

Verwandte Ressourcen

• Cloud-Sitzungen-Referenz: Starten, verwalten und teilen Sie Cloud-Sitzungen
• Cloud-Sitzungen-Schnellstart: Verbinden Sie GitHub und starten Sie Ihre erste Cloud-Sitzung
• Claude Tag: Sitzungen, die Claude aus Slack startet, werden in den gleichen Umgebungen ausgeführt
• Routinen: Geplante Läufe verwenden die gleichen Umgebungen und Netzwerkzugriffsstufen
• Remote Control: Führen Sie Sitzungen auf dem Netzwerk und den Dateien Ihres eigenen Computers aus
• Selbstgehostete Umgebungen: Führen Sie Cloud-Sitzungen auf der eigenen Infrastruktur Ihrer Organisation aus
• SessionStart Hooks: Repo-committed Setup, das in lokalen und Cloud-Sitzungen ausgeführt wird
• Server-verwaltete Einstellungen: Organisations-Richtlinie, die Cloud-Sitzungen erreicht