Skip to main content
Cloud-Umgebungen erfordern Claude Code im Web, das sich in der Forschungsvorschau für Pro-, Max- und Team-Benutzer sowie für Enterprise-Benutzer mit Premium-Sitzen oder Chat + Claude Code-Sitzen befindet.
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: Claude Code im Web, das Terminal mit claude --cloud, Claude Tag, Routinen, die Claude Mobile-App und die Desktop-App. 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 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: 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:
  • Im Web, in der Desktop-App und in der Mobile-App 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.
  • 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 die Umgebungsauswahl auf claude.ai/code, die Sie nach dem Web-Onboarding erreichen. Umgebungen, die Sie erstellen, sind persönlich für Ihr Konto; gemeinsame Umgebungen, die von einem Eigentümer erstellt wurden, erscheinen in derselben Auswahl. Siehe Installierte Tools für das, was ohne Konfiguration verfügbar ist.
1

Öffnen Sie die Umgebungsauswahl

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 die Auswahl.
Die Umgebungsauswahl ist über dem Nachrichtenfeld auf claude.ai/code geöffnet. Die Cloud-Schaltfläche mit dem Umgebungsnamen „Default" befindet sich in der Zeile über dem Nachrichtenfeld. Das offene Menü zeigt eine lokale Zeile mit den Bezeichnungen „Download" und „Desktop only", einen Cloud-Bereich, in dem die Umgebung „Default" mit einem Häkchen ausgewählt ist und beim Hovern ein Einstellungszahnrad anzeigt, eine Option „Add cloud environment" und einen Bereich „Remote Control" mit Setupanweisungen.
2

Fügen Sie eine Umgebung hinzu oder bearbeiten Sie eine

Wählen Sie Add cloud environment aus, 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 auf einem Pro- oder Max-Plan bearbeiten, enthält der Dialog auch API-Anmeldedaten.
Der Dialog „New cloud environment". Ein Namensfeld mit dem Platzhalter „Default", eine Netzwerkzugriff-Auswahl auf „Trusted" mit Links zur Netzwerkrichtlinie und Zugriffsstufen, ein Feld für Umgebungsvariablen mit .env-Format-Platzhaltertext und einem Hinweis, dass Werte für jeden sichtbar sind, der die Umgebung nutzt, ein Feld für das Setup-Skript, das als Bash-Skript beschrieben wird und beim Start einer neuen Sitzung ausgeführt wird, bevor Claude Code startet, sowie Schaltflächen „Cancel" und „Create environment".

​
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.
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 Hinzufügungen von Variablen auf Sitzungen aus, die Sie danach starten; Sitzungen, die bereits laufen, behalten die Werte, mit denen sie gestartet wurden. Claude Code im Web setzt auch einige Variablen selbst, wenn es eine Sitzung startet. Für CLAUDE_AUTOCOMPACT_PCT_OVERRIDE überschreibt der Wert, den Claude Code im Web 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. Auf Pro- und Max-Plänen verwenden Sie 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 Sitzungs-VM verlässt. Der Schlüssel erreicht niemals Claude, die Befehle, die er ausführt, oder die Umgebungsvariablen der Sitzung. API-Anmeldedaten sind auf Pro- und Max-Plänen verfügbar. Sie sind auf Team- oder Enterprise-Plänen noch nicht verfügbar, daher erscheint der Abschnitt API-Anmeldedaten nicht im Umgebungs-Dialog auf diesen Plänen.

​
Anforderungen

Zwei davon entscheiden, ob Sie eine Anmeldedaten hinzufügen können, und zwei entscheiden, ob der Agent-Proxy sie einmal hinzugefügt verwenden kann:
  • Rolle: eine Organisations-Admin-Rolle in Ihrer claude.ai-Organisation
    • Auf Team und Enterprise halten Eigentümer sie und Administratoren nicht
    • Auf Pro und Max halten Sie sie in Ihrer eigenen Organisation
    • Ohne sie sehen Sie stattdessen einen Hinweis auf der Anmeldedaten-Liste, auch auf Ihren eigenen Umgebungen. Bitten Sie einen Eigentümer, 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 selbstgehostete Umgebung hat keine API-Anmeldedaten
  • API-Erreichbarkeit: die API akzeptiert Verbindungen aus dem Internet, da Anfragen aus Anthropic-Netzwerk verlassen
  • 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.
1

Öffnen Sie die API-Anmeldedaten der Umgebung

Öffnen Sie die Umgebung zur Bearbeitung auf claude.ai/code. Im Dialog Update cloud environment finden Sie API-Anmeldedaten unter Umgebungsvariablen. Sie sehen die Anmeldedaten, die bereits in der Umgebung vorhanden sind, jeweils mit den Hosts, auf die sie sich beziehen.
2

Fügen Sie die Anmeldedaten hinzu

Wählen Sie Add credential und füllen Sie das Formular aus. Behalten Sie den Standard Credential type, Bearer, für einen API-Schlüssel, der in einem Request-Header verläuft, und füllen Sie diese Felder aus:
  • Name: ein Label für die Anmeldedaten, wie Internal billing API
  • Allowed websites: die Hosts der API, wie api.example.com. Ein führendes *. passt zu jeder Subdomain
  • Custom headers: eine Zeile für den Header, der den Schlüssel trägt. Die Zeile beginnt mit Authorization als Name des Headers und Bearer als Prefix; fügen Sie den Schlüssel selbst als Value ein. Für einen Header wie X-Api-Key, der den bloßen Wert nimmt, ändern Sie den Namen und löschen Sie das Prefix
Für eine API, die sich anders authentifiziert, wählen Sie einen anderen Credential type. Die Liste ist die gleiche, die Claude Tag, die Slack-Integration für Team- und Enterprise-Pläne, für Verbindungen anbietet.
3

Speichern Sie die Anmeldedaten

Wählen Sie Connect. Die Anmeldedaten erscheinen in der Liste mit ihren Hosts, gespeichert ohne die Schaltfläche Save changes des Dialogs. Sie können den Wert nach dem Speichern nicht erneut anzeigen.
Um zu bestätigen, dass die Anmeldedaten funktioniert, starten Sie eine Sitzung in der Umgebung und bitten Sie Claude, die API aufzurufen, zum Beispiel mit curl. Die API antwortet, als ob der Schlüssel in der Anfrage wäre, und der Schlüssel erscheint nicht in den Umgebungsvariablen der Sitzung oder in einer Datei. Wenn die Liste eine Anmeldedaten als Not sent markiert, sagt der Hinweis darunter, warum und was zu tun ist. Zwei Anmeldedaten, deren Hosts sich überlappen, ohne genau zu passen, erhalten keinen Marker, und der Agent-Proxy sendet nur eine von ihnen.

​
Welche Anfragen erhalten die Anmeldedaten

Der Agent-Proxy fügt eine Anmeldedaten an eine Anfrage an, wenn der Host der Anfrage einem passt, 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 der Agent-Proxy überspringt. Die Anmeldedaten gelten in jeder Sitzung, die in der Umgebung läuft, wer sie auch immer 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 Anfragen an GitHub stattdessen, daher benötigen Sie keine API-Anmeldedaten dafür
  • Die Anthropic-API und öffentliche Paketregistrierungen: Anfragen an api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io und proxy.golang.org gehen nicht durch den Agent-Proxy
  • Setup-Skript-Anfragen: Claude Code verbindet sich mit dem Agent-Proxy, wenn es startet, nachdem das Setup-Skript ausgeführt wurde

​
Wählen Sie eine Umgebung aus der CLI aus

Führen Sie /remote-env in Ihrem Terminal aus, um die Standardumgebung für Cloud-Sitzungen auszuwählen, die Sie über die CLI erstellen, wie claude --cloud. Der Befehl öffnet eine Auswahl Ihrer vorhandenen Umgebungen und speichert Ihre Wahl im Schlüssel remote.defaultEnvironmentId in Ihren Benutzereinstellungen, sodass sie in jedem Projekt auf Ihrem Computer gilt, bis Sie sie ändern, es sei denn, derselbe Schlüssel ist auf einer höheren Prioritäts-Einstellungsebene gesetzt, wie in den Projekteinstellungen eines Repositorys. Eine selbstgehostete 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 diese auf claude.ai/code.

​
Archivieren Sie eine Umgebung

Um eine Umgebung zu archivieren, öffnen Sie sie zur Bearbeitung und wählen Sie Archive aus. 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 der Auswahl und aus /remote-env, sodass Sie sie nicht für neue Sitzungen auswählen können.
  • 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 andernfalls 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. Verweisen Sie es auf eine andere Umgebung.

​
Gemeinsame Umgebungen der Organisation

Auf Team- und Enterprise-Plänen kann ein Eigentümer Cloud-Umgebungen erstellen, die mit jedem Mitglied der Organisation geteilt werden. Die gleiche Rolle verwaltet alles andere auf der Seite Cloud environments in den Admin-Einstellungen, einschließlich selbstgehosteter 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 in der Umgebungsauswahl jedes Mitglieds neben ihren persönlichen, sodass ein Team sich auf eine Konfiguration einigen kann, anstatt dass jedes Mitglied sie neu erstellt. Erstellen, bearbeiten und archivieren Sie gemeinsame Umgebungen auf der Seite Cloud environments in den Admin-Einstellungen. Eine gemeinsame Umgebung öffnet sich auch aus der Umgebungsauswahl auf claude.ai/code: Ein Eigentümer kann sie dort bearbeiten. Andere Mitglieder sehen sie schreibgeschützt. Jede gemeinsame Umgebung hat einen Namen, eine Netzwerkzugriffsstufe, Umgebungsvariablen im .env-Format und ein Setup-Skript. Eigentümer wählen die Standardumgebung der Organisation separat auf claude.ai/admin-settings/claude-code aus. Jedes Mitglied liest die Variablen einer gemeinsamen Umgebung in seinen Sitzungen, daher fügen Sie keine Geheimnisse darin ein. API-Anmeldedaten, die Sitzungen einen Schlüssel geben, den sie nicht lesen können, sind auf 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 gemeinsame Identität Ihrer Organisation, nicht als ein Mitglied, daher verwenden Kanalsitzungen nur Umgebungen auf Organisationsebene, entweder gemeinsame Umgebungen oder selbstgehostete Umgebungen. Um einem Kanal eine Toolchain zu geben, die nicht vorinstalliert ist, wie .NET, kann ein Eigentümer eine gemeinsame Umgebung aus der Seite Cloud environments in den Admin-Einstellungen mit einem Setup-Skript erstellen, das sie installiert. Verweisen Sie den Kanal auf eine Umgebung auf eine von zwei Arten:

​
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. 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.
MCP-Konnektoren, die Sie auf einer Sitzung oder Routine aktivieren, funktionieren, ohne ihre Hosts zu Allowed domains hinzuzufügen, da der Konnektoren-Verkehr über Anthropic-Server verläuft, anstatt über das Netzwerk der Sitzung. Sie konfigurieren Konnektoren pro Sitzung oder pro Routine; entfernen Sie alle, die Sie nicht benötigen, um zu begrenzen, welche Tools Claude erreichen kann. Dies beruht auf dem gleichen Anthropic-gebundenen Kanal, der unter Security and isolation erwähnt wird.

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

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

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

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 Slash-Befehl; 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. 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. Dies erfordert v2.1.179 oder später. Um den Trailer und den PR-Body-Link zu weglassen, setzen Sie attribution.sessionUrl auf false. Die Einstellung erfordert v2.1.182 oder später. 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:

​
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:
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 startet. Verwenden Sie Setup-Skripte, um Abhängigkeiten zu installieren, Tools zu konfigurieren oder alles zu abrufen, das die Sitzung benötigt, das nicht vorinstalliert ist. Skripte werden als Root auf Ubuntu 24.04 ausgeführt, daher funktionieren apt install und die meisten Sprach-Paketmanager. Um ein Setup-Skript hinzuzufügen, öffnen Sie den Umgebungseinstellungs-Dialog und geben Sie Ihr Skript in das Feld Setup script ein. Dieses Beispiel installiert ShellCheck, das nicht vorinstalliert ist.

​
Skript-Anforderungen

Ein Setup-Skript hat drei Einschränkungen, um die herum zu schreiben:
  • Exit zero: Wenn das Skript mit Non-Zero beendet wird, schlägt die Sitzung fehl zu starten. Hängen Sie || true an nicht-kritische Befehle an, damit ein gelegentlicher Installationsfehler die Sitzung nicht blockiert.
  • Beenden Sie innerhalb von fünf Minuten: Halten Sie die Gesamtlaufzeit des Skripts unter ungefähr 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: Paket-Installationen müssen Registrierungen erreichen. Die Standard-Trusted-Stufe deckt gängige Paketregistrierungen ab, einschließlich npm, PyPI, RubyGems und crates.io; mit None Netzwerkzugriff schlagen Installationen fehl.

​
Umgebungs-Caching

Das Setup-Skript wird das erste 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 laufen war. 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 Hintergrund-Prozess nicht; starten Sie diese pro Sitzung, indem Sie Claude bitten oder mit einem SessionStart Hook. 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 seine Ablaufzeit nach ungefähr sieben Tagen erreicht. Das Fortsetzen einer vorhandenen Sitzung führt das Setup-Skript niemals 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 Projekt-Setup, das überall laufen sollte, Cloud und lokal, 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-Level ~/.claude/settings.json haben, erwarten Sie sie nicht in der Cloud: Benutzer-Level-Einstellungen bleiben auf Ihrem Computer. Welche anderen Hooks ausgeführt werden, hängt davon ab, wo die Sitzung läuft:

​
Installieren Sie Abhängigkeiten mit einem SessionStart Hook

Um Abhängigkeiten nur in Cloud-Sitzungen zu installieren, kombinieren Sie einen SessionStart Hook mit einem Skript, das überprüft, wo es läuft. Fügen Sie zunächst einen SessionStart Hook zur .claude/settings.json Ihres Repos hinzu. Diese Konfiguration teilt Claude Code mit, 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-Events, und $CLAUDE_PROJECT_DIR wird zum Repository-Root aufgelöst, daher findet der Hook das Skript unabhängig vom Arbeitsverzeichnis der Sitzung. Erstellen Sie als Nächstes das Skript unter scripts/install_pkgs.sh. Es beendet sich sofort außerhalb der Cloud, dann installiert Ihre Abhängigkeiten:
Die CLAUDE_CODE_REMOTE-Überprüfung ist das, was die Installation auf Cloud-Sitzungen begrenzt: Die Umgebung der Sitzungs-VM trägt diese Variable als true, sie ist niemals true lokal, daher beendet sich das Skript auf Ihrem Laptop, bevor es etwas installiert. Zusammen geben die beiden Dateien jeder Cloud-Sitzung einen frischen npm install und pip install beim Start, während lokale Sitzungen unberührt bleiben.

​
Einschränkungen in Cloud-Sitzungen

SessionStart Hooks verhalten sich in der Cloud gleich wie lokal, mit diesen Vorbehalten:
  • Keine Cloud-only-Scoping: Hooks werden in lokalen und Cloud-Sitzungen ausgeführt. Um lokale Ausführung zu überspringen, überprüfen Sie die Umgebungsvariable CLAUDE_CODE_REMOTE, wie oben gezeigt.
  • Erfordert Netzwerkzugriff: Installationsbefehle müssen Paketregistrierungen erreichen. Wenn Ihre Umgebung None Netzwerkzugriff nutzt, schlagen diese Hooks fehl. Die Standard-Whitelist unter Trusted deckt npm, PyPI, RubyGems und crates.io ab.
  • Proxy-Kompatibilität: In von Anthropic gehosteten Umgebungen verläuft der gesamte ausgehende Verkehr durch einen Sicherheits-Proxy, und einige Paketmanager funktionieren nicht korrekt damit; Bun ist ein bekanntes Beispiel. In einer selbstgehosteten Umgebung verläuft ausgehender Verkehr stattdessen durch Ihre eigene Netzwerk-Grenze.
  • Fügt Startup-Latenz hinzu: Hooks werden jedes Mal ausgeführt, wenn eine Sitzung startet oder fortgesetzt wird, anders als Setup-Skripte, die vom Umgebungs-Caching profitieren. Halten Sie Installationsskripte schnell, indem Sie überprüfen, ob Abhängigkeiten bereits vorhanden sind, bevor Sie neu installieren.
Um das Basis-Image anzupassen, verwenden Sie ein Setup-Skript, um 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
  • statsig.anthropic.com
  • docs.claude.com
  • platform.claude.com
  • code.claude.com
  • claude.ai
  • 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
  • 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
  • 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
  • jcenter.bintray.com
  • gradle.org
  • www.gradle.org
  • services.gradle.org
  • plugins.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
  • statsig.com
  • www.statsig.com
  • api.statsig.com
  • sentry.io
  • *.sentry.io
  • downloads.sentry-cdn.com
  • http-intake.logs.datadoghq.com
  • browser-intake-us5-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
  • Claude Code im Web: Starten, verwalten und teilen Sie Cloud-Sitzungen
  • Web-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