Claude Code im Cloud: ein Feldhandbuch für Cloud-Sessions

Sie führen wahrscheinlich Claude Code im Terminal auf Ihrem Laptop aus. Diese Sitzung hängt vom Laptop auf drei Arten ab:

• Es teilt Ihren Arbeitsbaum, sodass zwei Sitzungen in einem Repository die gleichen Dateien bearbeiten und um denselben Port streiten können.
• Es läuft mit Ihren Zugangsdaten.
• Es stoppt, wenn Ihr Computer einschläft oder das WLAN versagt.

Eine Cloud-Sitzung führt Claude Code auf einer eigenen Maschine aus. Jede Aufgabe erhält eine neue virtuelle Maschine, bei der Ihr Repository auf einer neuen Branch kopiert wird und die Einrichtung Ihres Umfelds bereits vorhanden ist.

Sie können damit beginnen über claude.ai/code, die Claude-Mobile-App, die Desktop-App, Ihren Terminal und Slack. Anschließend können Sie es über den Browser, die Mobile-App oder die Desktop-App verfolgen. Wenn die Arbeit erledigt ist, bleibt sie in einer Branch, die Sie in einen Pull-Request umwandeln können.

Cloud-Sessions kommen mit Ihrem Pro-, Max-, Team- oder Enterprise-Plan kostenlos: Es gibt keine zusätzlichen Kosten für die Cloud-Maschine, und die Sessions unterliegen denselben Nutzungsbeschränkungen wie der Rest von Claude Code. Je nach Ihrem Plan muss der Organisationseigentümer zunächst Cloud-Sessions aktivieren.

Bonuskredit für Cloud-Sessions. Bestehende Einzelabonnenten von Pro und Max können einen einmaligen Bonuskredit für Cloud-Sessions erhalten, über den Grundhalt der Abonnementsgrenzen hinaus: 100 $ für Pro und 250 $ für Max. Erhalten Sie ihn bis zum 7. Oktober unter claude.ai/code/claim-credit oder mit /claim-credit in Claude Code. Der Kredit läuft am 4. November ab. Nachdem er verwendet wurde oder abläuft, gilt die reguläre Nutzung Ihres Abonnements. Er ist nicht für Projekte oder Routinen gültig. Siehe Bedingungen der Werbekreditangebote.

Für diese Anleitung führte ich vier echte Cloud-Sessions durch, die auf einem kleinen Repositorium durchgeführt wurden. Ihre Transkripte, Diffs und Zeitangaben sind überall zu finden. Der Repositorium und der Benutzer in den Screenshots sind erstellt. Die Arbeit, die Ausgabe und die Zahlen stammen aus diesen Sessions.

Einer der Hauptvorteile von Cloud-Sessions ist, dass man mehrere Aufgaben gleichzeitig ausführen kann, ohne dass sie sich gegenseitig stören. Hier sind drei Beispiele: Ich habe sie innerhalb von 16 Sekunden jeweils auf einer eigenen Maschine ausgeführt. Auf meinem Laptop hätte ich diese Aufgaben nacheinander ausführen können, oder ich hätte meine Zeit damit verbracht, sicherzustellen, dass sie sich nicht gegenseitig stören.

DREI AUFGABE, EIN REPOSITORIUM, DREI MASCHINEN

Der Beispielrepository ist tidepool, eine kleine Node-API, die die Gezeiten für drei fiktive Häfen vorhersagt. Es gab drei alltägliche Probleme: Ein Test fehlte etwa ein Viertel der Malen, die API-Dokumente beschrieben Parameter, die der Code nicht mehr liest, und der Logger erstellt seine Zeilen durch das Zusammenfügen von Strings.

Ich begann drei Cloud-Sessions innerhalb von 16 Sekunden voneinander, eine pro Problem. Ich startete sie programmgesteuert, und da „Tidepool“ nicht auf GitHub ist, erstellte jede Session zunächst den Repositorium wieder aus den Dateien in ihrem Prompt. Bei einem echten Repositorium würde man diesen Schritt überspringen, und vom Terminal gilt jede Session als ein claude --cloud-Befehl. Kurz gesagt: Die drei Prompts waren:

claude --cloud "npm test fails maybe one run in four. Find the flaky test, fix the root cause in the code (not the test), and prove it by running the suite at least 30 times in a row."
claude --cloud "docs/API.md is out of date with src/server.js. Rewrite it so every endpoint, parameter, default and response shape matches the code. Start the server and run each curl example to check it."
claude --cloud "Make src/logger.js emit one JSON object per line, keep LOG_LEVEL, and log method, path, status and duration_ms as fields. Add a test for the logger."

Die Sitzungen dauerten 61, 65 und 72 Sekunden, und alle drei wurden 87 Sekunden nach dem Beginn der ersten Sitzung durchgeführt. Die Wiederherstellung des Repositoriums dauerte etwa ein Drittel bis etwas mehr als die Hälfte jeder Ausführung. Hier sind die Ergebnisse.

• Der instabile Test. Claude fand eine Race in TtlCache.get. Der Cache speicherte einen Wert nur nachdem der Loader abgeschlossen war, daher rief ein zweiter get für denselben Schlüssel während einer Ladeaktion den Loader erneut auf. Claude änderte den Cache, damit er den in-flight-Versprechen speichert, entfernte die Einträge, wenn eine Ladeaktion fehlschlug, und führte npm test 40 Mal hintereinander mit keinen Fehlern aus.
• Die Dokumentationen. Claude startete den Server, führte einen curl gegen jedes Endpunkt durch und entdeckte fünf Fehler in der alten Dokumentation. Es wurden Felder aufgelistet, die die API nie zurückgibt, ein days Parameter dokumentiert, den die Code nicht ignoriert, Höhen in Fuß bei denen es Metern sind, das /next-high Endpunkt übersprungen und die Fehlerantworten weggelassen. Es wurde auch festgestellt, dass ein fehlerhaftes from= Wert eine leere Liste mit einer 200 Antwort zurückgibt, und dokumentiert wurde, dass man nicht gebeten wurde, den Servercode zu ändern, sondern es nicht verändert werden sollte.
• Der Logger. Claude schrieb den JSON-Logger, versetzte den Anfragelog zu strukturierten Feldern und fügte fünf Tests hinzu. Sein Commit enthielt einen fehlenden Test, daher wiederholte Claude den Cache-Test achtmal, stellte fest, dass er in fünf von ihnen fehlerhaft war, und konnte die Fehlerquelle auf dieselbe Problemstelle zurückführen, die bei der ersten Sitzung behoben wurde. Er schlug denselben Ersatz vor, ließ den Cache unberührt, da dies außerhalb seiner Aufgabe lag, und erklärte in seinem Zusammenfassung, dass das Set nicht sauber sei.

Der Logger-Resultat zeigt, warum Cloud-Sessions für paralleles Arbeiten geeignet sind. Jede Sitzung hatte ihre eigene Kopie des Repositoriums, ihre eigenen Prozesse und ihre eigene Branch. Die Docs-Sitzung und die Logger-Sitzung starteten jeweils den API-Server, um ihn zu testen, und beeinflussten sich nicht gegenseitig. Auf einem einzigen Laptop würden zwei Agenten, die gleichzeitig arbeiten, die gleichen Dateien bearbeiten und es zu Konflikten auf dem Port kommen würde, wenn jeder seinen eigenen Weg wähle.

Wegen dieser Isolierung hatte die Logger-Sitzung keinen Zugang zum Cache, den die erste Sitzung bearbeitet hatte. Die parallelen Aufgaben wurden entlang der Dateigrenzen geteilt, die Zweige wurden in einer sinnvollen Reihenfolge zusammengeführt, und man erwartete, dass eine Sitzung Probleme meldete, die bereits von einer anderen Sitzung behoben wurden.

UNTER DER HÜT DES CLAUDE CODE CLOUD-SESSIONS

Eine Cloud-Sitzung ist eine Claude Code-Sitzung, die auf der von Anthropic verwalteten Infrastruktur oder auf den eigenen Maschinen Ihrer Organisation mit einem selbsthostierten Umfeld läuft. Die Abbildung zeigt die einzelnen Bestandteile. Die vier Schlüsselpunkte darunter sind jene, die Ihre Arbeitsweise verändern.

• Jede Aufgabe hat ihre eigene Maschine. Eine neue VM mit Ihrem Repositorium wird auf einer neuen Branch kopiert, sodass die Sitzungen keine Dateien oder Ports der anderen berühren können. Siehe was installiert ist.
• Dein GitHub-Token gelangt nie in die VM. Ein Proxy hält ihn fest, und die Sitzung erhält eine kurzlebige Zugriffskarte, die nur auf den eigenen Arbeitsschnittpunkt zugreifen kann. Siehe den GitHub-Proxy.
• Die Claude-Konfiguration des Repositories ist verfügbar. Deine persönliche nicht. CLAUDE.md, Regeln, Fähigkeiten, Agenten und Befehle gelangen mit dem Repo, und dein ~/.claude bleibt auf deinem Laptop. Siehe Einstellungen in Cloud-Sessions.
• Idle VMs werden zurückgeholt. Öffnen Sie die Sitzung erneut, und Sie erhalten eine neue VM mit der wiederhergestellten Konversation – so können Sie die Arbeit bearbeiten, die Ihnen wichtig ist. Siehe Umgebungsvorlaufzeit.

Für Spezifikationen, Permissionsmodi und Netzwerklevel, siehe die Cloud-Environments-Dokumentation.

Lokale oder Cloud?

Cloudsessions ersetzen keine lokalen Sessions, und die meisten Menschen verwenden beides. Die Tabelle zeigt die Unterschiede an, und die folgenden Absätze beschreiben, wann jede Art von Session verwendet wird.

Bleiben Sie lokal, wenn die Aufgabe etwas erfordert, das nur Ihr Gerät hat. Das umfasst eine Datenbank mit echten lokalen Daten, einen Service, den man über eine VPN erreicht, eine GPU, einen Telefonsimulator oder Hardware auf Ihrem Schreibtisch. Bleiben Sie auch lokal, wenn es um enggefasste visuelle Schleifen geht, bei denen Sie jede Veränderung innerhalb von Sekunden in Ihrem eigenen Browser sehen möchten, und wenn Ihre Organisation mit Zero Data Retention arbeitet, das die Cloud-Sessions ausschaltet.

Zwei Funktionen liegen zwischen den Optionen. Remote Control hält die Sitzung auf Ihrem Gerät und ermöglicht es Ihnen, sie von Ihrem Telefon oder Browser aus zu steuern. Self-hosted Environments, in Beta für Team und Enterprise, führen Cloud-Sitzungen auf der eigenen Infrastruktur Ihres Unternehmens durch, sodass sie private Netzwerke erreichen können.

Wenn das nichts davon trifft, ist die Aufgabe ein guter Kandidat für die Cloud. Der nächste Abschnitt behandelt die Workflows, in denen das am meisten von Vorteil ist.

SIEBEN ARBEITSTREFFEN, DIE CLOUD-SESSIONEN EINFÜGEN

Diese Workflows nutzen die Unterschiede in der Tabelle: eine separate Maschine für jede Aufgabe, Sitzungen, die während Ihrer Abwesenheit weiterlaufen, und eine Abzweigung am Ende, um Sie zu überprüfen.

1. Entferne eine Überlastung gleichzeitig

Sagen wir, Sie haben fünf kleine, unabhängige Reparaturen. Lokal würden Sie sie nacheinander durchführen oder fünf Worktrees einrichten und deren Ports sowie Installationen getrennt halten. Im Cloud würden Sie fünf Sitzungen starten und fünf Branchs überprüfen.

claude --cloud "Fix the flaky test in auth.spec.ts"
claude --cloud "Update the API documentation"
claude --cloud "Refactor the logger to use structured output"

claude --cloud kopiert Ihren GitHub-Remote auf der aktuellen Branch, daher müssen Sie zuerst Ihre lokalen Commits hochladen. Während die VM startet, zeigt die CLI eine aktive Liste mit Einrichtungsschritten und wartet auf alles, was Sie eingeben.

Schreibe jede Aufgabe als selbstständiges Ticket, das angibt, was falsch ist, wie es erledigt aussehen sollte und wie man dies beweisen kann. Der flaky-test-Prompt nannte seine Beweisführung: Das Set mindestens 30 Mal hintereinander ausführen. Die Sitzung führte es 40 Mal aus.

Wenn die Aufgaben zu einem größeren Projekt gehören, führt ein Projekt (öffentliche Beta-Version für Pro und Max) eine Koordinatorkonversation durch, die die Cloud-Sessions startet und verfolgt. Anschließend wird es nach Zustand gruppiert: in Bearbeitung, auf Ihre Antwort wartend und bereit für die Überprüfung.

2. Lassen Sie es die Lösung beweisen

Ein instabiler Test ist das klarere Beispiel für Arbeit, die wiederholte Überprüfung erfordert: Man muss den Testzyklus immer wieder ausführen, und man möchte nicht, dass dieser Loop die Maschine blockiert, auf der man arbeitet. Im Cloud-Bereich hat Claude den Cache repariert und den gesamten Testzyklus 40 Mal mit einer einzigen Anweisung ausgeführt.

Die VM hat keine Rechenkosten und ihre CPU gehört nicht dir, also verlangen Sie eine gründliche Beweis. Führen Sie die Suite 200 Mal aus, teilen Sie eine Regression über 50 Commits auf, führen Sie den langsamen Integrationstier aus, oder starten Sie die App und nutzen Sie curl, wie in der Dokumentationssitzung gemacht wurde.

Jeder von Claudes Schritten zählt weiterhin zu Ihrem Plan, aber eine lange Testausführung innerhalb einer einzigen Anweisung kostet wenig. Vordergrundkommandos gehen nach 2 Minuten standardmäßig aus (maximal 10), und dann laufen sie weiterhin im Hintergrund bis zu 30 weitere Minuten. Sie können die Standardwerte mit BASH_DEFAULT_TIMEOUT_MS und BASH_MAX_TIMEOUT_MS in den Umgebungsvariablen erhöhen.

3. Planen am Schreibtisch, erstellen im Cloud, abschließen im Terminal

Für eine größere Änderung: Vereinbaren Sie zunächst den Ansatz, bei dem die Kommunikation kostengünstig ist. Stellen Sie Claude in Planmodus ein, entwickeln Sie gemeinsam den Plan, veröffentlichen Sie den Plan und pushen Sie ihn.

claude --permission-mode plan
# ...agree on the plan, save it to docs/migration-plan.md, commit and push...
claude --cloud "Execute the migration plan in docs/migration-plan.md"

Während die Cloud-Sitzung erstellt wird, ist Ihr Terminal frei für andere Arbeiten. Wenn die Sitzung fertig ist, ziehen Sie die Sitzung herunter, um sie manuell abzuschließen.

claude --teleport            # pick a cloud session
claude --teleport <session-id>

Teleport überprüft, dass Sie im selben Repository sind, holt den Branch der Sitzung ab, zieht ihn heraus und lädt die gesamte Konversation in Ihren Terminal ein. Sie benötigen einen sauberen Arbeitsbaum (er bietet das Speichern an), und der Branch muss gepusht werden. Von inside Claude Code aus… /teleport oder /tp) öffnet denselbenPicker, und /tasks dann t funktioniert auch. Die Desktop-App geht in die entgegengesetzte Richtung, und ihr Öffnen in Das Menü sendet eine lokale Sitzung an den Cloud.

4. Melden Sie sich über Ihr Telefon an

Die „Code“-Taste in der Claude-App verbindet sich mit denselben Sitzungen. Von Ihrem Telefon können Sie eine Aufgabe starten, sie verfolgen, sie steuern, auf eine Frage von Claude antworten oder Claude befehlen, einen Pull-Request zu überwachen.

Ein Telefon eignet sich dafür, Fragen zu klären, die man sonst vergessen würde, bevor man den Tastenbrett erreicht. In der vierten Sitzung stellte ich eine Frage, die man auf einer einzigen Taste eingeben könnte: Wie kann ein Tidepool die Gezeiten vorhersagen, und wie könnte es am Rand eines Zeitfensters falsch funktionieren? Das Programm prüfte seine Antwort und entdeckte einen echten Fehler. Der Loop untersucht nie das erste oder letzte Beispiel, sodass die API eine hohe Gezeiten nicht erkennt, die genau am Anfang des Fensters stattfindet.

5. Senden Sie die CI-Fehler und die Überprüfungskommentare an Claude

Mit der Claude-GitHub-App installiert auf einem Repository kann eine Cloud-Sitzung einen Pull-Request beobachten und darauf reagieren. In einer Sitzung unter claude.ai/code öffnen Sie das Auto-fix. Sie können auch /autofix-pr auf dem PR-Branch in Ihrem Terminal ausführen, die mobile App bitten, den PR zu beobachten, oder den PR-URL in eine Sitzung eintragen.

Claude gibt klare Lösungen für fehlende Prüfungen und Überprüfungskommentare an und erklärt, was verändert wurde. Er fragt dich nach allem, was unklar oder architektonisch ist. Die Antworten in den Überprüfungsthemen werden unter deinem GitHub-Accountnamen als Claude Code veröffentlicht. Claude wird nicht benachrichtigt, wenn es zu Merge-Konflikten mit der Basissparte kommt, also frag ihn, ob er einen Rebase durchführen soll. Seine Kommentare können auch eine automatisierte Verarbeitung wie Atlantis auslösen.

6. Beginnen Sie die Arbeit ohne selbst anzufangen

Eine Routine ( Forschungsvorstellung ) ist mehrere gespeicherte Ressourcen, die dazu dienen, eine Aufgabe zu erledigen – wie z. B. ein Prompt, Repositories, Verbindungen und eine Umgebung. Jede Ausführung ist eine Cloud-Sitzung, die durch einen Trigger initiiert wird. Die Trigger können ein Zeitplan (am häufigsten alle Stunden) sein, eine HTTP-Anfrage an den eigenen Endpunkt der Routine oder ein GitHub-Ereignis wie ein Pull-Request-Open oder eine Veröffentlichung. Eine Routine erstellen Sie unter claude.ai/code/routines im Desktop-App oder mit /schedule in der CLI. Routinen werden ohne Genehmigungsanfragen ausgeführt und setzen standardmäßig die claude/-Suffix-basierte Branchs frei.

Zwei kleinere Tools helfen hier. Sie können eine Nachfolgeaufgabe in eine laufende Sitzung über jedes Gerät einrichten, auf dem Sie eingeloggt sind – einschließlich eines CI-Jobs.

claude -p "The integration tier is green now; rebase on main and push" --cloud <session-id>

Sie können auch eine vorgefüllte Sitzung markieren. Eine URL wie claude.ai/code?prompt=Triage+the+newest+issues&repositories=acme-labs/tidepool Öffne claude.ai/code mit dem vorgefüllten Prompt und Repository.

7. Führen Sie den Code aus, dem Sie nicht vollständig vertrauen

Ein Pull-Request eines Mitwirkers, ein Installationsskript für eine neue Abhängigkeit oder ein Repository, das Sie vor fünf Minuten geklont haben, können alle Code ausführen, den Sie noch nicht gelesen haben. Auf Ihrem Laptop läuft dieser Code neben Ihren SSH-Schlüsseln, Ihren Cloud-CLI-Sessions und Ihrem Browserprofil. In einer Cloud-Session läuft er in einer einmaligen VM ohne diese Dinge, ohne Session-spezifische GitHub-Credentials und ohne ein Netzwerk, das Sie einschränken können.

Stellen Sie den Netzwerkzugang der Umgebung auf None für die strengste Einstellung ein, oder behalten Sie Trusted, was die Verwendung von Paketregisträrn, GitHub und den wichtigsten Cloud-SDK-Hosten ermöglicht. Selbst bei None sendet Claude Code weiterhin Anfragen an die Anthropic API, sodass Daten von der VM ausgehen können und die Sitzung noch auf ihre eigene Branch gesendet werden kann. Der gesamte Outbound-Verkehr durchläuft einen Proxy, der die Hostnamen protokolliert.

Verbinden von GITHUB ohne festzustecken

Wenn Ihre erste Cloud-Sitzung fehlschlägt, ist GitHub die wahrscheinlichste Ursache. Die meisten Probleme entstehen dadurch, dass die Cloud-Sitzungen zwei separaten GitHub-Rechte erfordern.

• Anmeldung bei GitHub teilt Claude mit, wer Sie sind.
• Installation der Claude-GitHub-App auf einer Account oder Organisation definiert die privaten Repositories, die Claude sehen kann.

Öffentliche Repositories arbeiten nur mit dem ersten Element. Private Repositories benötigen das zweite Element, je nachdem, welche Kontoe oder Organisation sie besitzt. Wenn Sie GitHub verknüpft haben und ein privates Repository fehlt, ist die App normalerweise nicht auf dem Kontoe oder der Organisation installiert, die es besitzt.

Pfad A: verbinden im Browser (empfohlen)

Verbinden Sie Ihr GitHub-Konto bei claude.ai/connect-github, dann installieren Sie die Claude-GitHub-App auf dem Konto oder der Organisation, die Ihren Repositorium besitzt. Bei einer Organisation muss der Besitzer normalerweise die Installation genehmigen. Der Quickstart führt Sie durch jede Schritt.

Wenn GitHub Sie nicht zurück zu Claude.ai/code sendet, kann die Verbindungsseite claude.ai/connect-github eine kurze Liste der häufigen Ursachen anzeigen. Eine davon ist der einzelne Sign-on-Schritt, durch den die Repositories einer Organisation verdeckt werden, wenn man ihn überspringt.

Die Auto-Fix-, GitHub-ausgelösten Routinen und Projekte hängen ebenfalls von der App ab, daher installieren Sie sie, auch wenn Sie sie auf andere Weise verbinden.

Pfad B: verbinden Sie sich über den Terminal mit /web-setup

Wenn Sie bereits die gh CLI verwenden, führen Sie /web-setup innerhalb von Claude Code aus, um Ihr gh-Token in Ihr Claude-Konto zu senden. Anschließend können Sitzungen jedes Repositoriums erreichen, auf das das Token zugreifen kann – mit oder ohne die App. Für eine Schritt-für-Schritt-Anleitung siehe Connect from your terminal. Bei den Team- und Enterprise-Paketen muss der Besitzer zunächst Quick setup aktivieren.

Pfad C: vermeiden GitHub für eine einzelne Anwendung

Führen Sie claude --cloud in einem Repository aus, das kein GitHub-Remote hat oder wo die App nicht installiert ist – dann lädt Claude Code einen Bundle Ihres Repositories hoch anstatt ihn zu klonen. Die Sitzung kann nur dann versendet werden, wenn Ihr GitHub-Konto Zugriff auf den Push-Back haben. In den Dokumenten steht aufgelistet, was im Bundle enthalten und was nicht.

Wenn Sie Team oder Enterprise ausführen

Ein Eigentümer hat eine kurze Checkliste: Aktivieren Sie den GitHub-Connector unter claude.ai/admin-settings/connectors, erlauben Sie Cloud-Sessions in den Claude Code-Administrationssettings, installieren Sie die Claude GitHub App in den Repositories der Organisation (oder genehmigen Sie die Anfragen der Mitglieder), und entscheiden Sie, ob Quick Setup aktiviert werden soll. Organisationen mit IP-Auflistungen oder GitHub Enterprise Server haben einen zusätzlichen Schritt. Siehe die Dokumentation zu IP-Auflistungen und GitHub Enterprise Server.

Wenn es immer noch nicht funktioniert

Für weitere Anliegen, siehe Troubleshooting in den Dokumenten, einschließlich keine Repositories erscheinen nach dem Verbinden mit GitHub. Um die Verbindung zu GitHub vollständig abzubrechen, verwenden Sie claude.ai/customize/connectors.

Gib den Teilnehmern die Dinge, die sie für die Überprüfung ihres eigenen Werks benötigen

Eine Sitzung, die Ihre Tests ausführt, überprüft ihre eigene Arbeit, bevor sie die Arbeit zurückgibt. Ohne das können Sie Änderungen überprüfen, die noch nicht ausgeführt wurden. Der größte Wert der Demos in diesem Guide kam von Claude: die Suite wurde 40 Mal ausgeführt, der Server und seine Curls, die Strömungsberechnung am Rand des Fensters. Zehn Minuten Umgebungssetup geben Claude die Möglichkeit, diese Überprüfungen durchzuführen.

• Beginnen Sie mit der Standardumgebung. Sie verwendet den vertrauenswürdigen Netzwerkzugriff, keine Variablen und keinen Einrichtungsskript, was für die meisten JavaScript-, Python-, Go- und Rust-Repositories ausreicht.
• Verwenden Sie einen Setup-Script für die Maschine. Er läuft als Root vor dem Start von Claude Code, sodass apt install funktioniert. Die Anwendung muss mit 0 ausgehen, sonst startet die Sitzung nicht, und sie sollte innerhalb von etwa fünf Minuten abgeschlossen werden, damit die Umgebung gespeichert wird. Danach beginnen neue Sitzungen mit einem Snapshot, in dem Ihre Tools auf der Festplatte sind. Die Cache wird neu erstellt, wenn Sie den Script oder die zulässigen Hosts ändern – und etwa alle sieben Tage.
• Verwenden Sie den Hook „SessionStart“ für das Projekt. Legen Sie Schritte wie npm install in einen Hook im .claude/settings.json des Repositoriums, sodass sie sowohl lokal als auch im Cloud-Ökosystem auf dieselbe Weise ausgeführt werden. Prüfen Sie CLAUDE_CODE_REMOTE, wenn ein Schritt nur im Cloud ausgeführt werden soll. Die Repository-Hooks laufen in Single-Repositorium-Sessions.
• Starten der Dienste pro Sitzung. Die Cache speichert Dateien. Die laufenden Prozesse überleben das nicht. Fragen Sie Claude, ob er service postgresql start ausführen soll, oder führen Sie es in einem SessionStart-Hook aus.
• Wählen Sie das engste funktionierende Netzwerk-Level. Trusted umfasst die gängigen Registrierungen. Verwenden Sie Custom, um ein privates Register zu hinzufügen, und Full nur, wenn die Aufgabe den offenen Internetzugang erfordert. Die Änderungen treten innerhalb von etwa einer Minute in den laufenden Sitzungen in Kraft.
• Halten Sie Geheimnisse nicht in gemeinsam genutzten Variablen fest. Umgebungsvariablen sind für jeden zugänglich, der die Umgebung verwendet. Auf Pro und Max binden die API-Kennungen einer Umgebung eine Schlüsselung an Anfragen für die von Ihnen benannten Hosts außerhalb der VM, sodass der Schlüssel nie in einer Variablen gespeichert wird.
• Legen Sie die Befehle in CLAUDE.md ab. Ihr persönlicher ~/.claude erreicht die Cloud-VM nicht. Wenn Claude wissen muss, wie die Integrationstests ausgeführt werden, muss das Repository dies angeben.

Gewohnheiten, die sich auszahlen

• Eine Aufgabe, eine Sitzung. Kleine, getrennte Sitzungen sind einfacher zu überprüfen und kostengünstiger zu vernichten.
• Bitte fordern Sie Beweise an. Nennen Sie den Befehl, der beweist, dass die Aufgabe erledigt ist, und lesen Sie Clodes Zusammenfassung vor dem Diff.
• Pusht vor claude --cloud. Die VM kopiert aus GitHub, daher erreichen unpushte Commits sie nicht.
• Kommentieren Sie während der langen Aufgaben gerade im Gehen. Leere VMs können wieder genutzt werden.
• Überprüfung im Diff-Bildschirm. Die Inline-Kommentare werden in Ihrem nächsten Nachricht eingebettet, und Create PR kann eine vollständige PR, einen Entwurf oder die compose-Seite von GitHub öffnen.
• Steuern Sie, während Claude arbeitet. Die Nachrichten, die Sie während der Arbeit von Claude senden, werden in eine Warteschlange gelegt, und Sie können eine in der Warteschlange stehende Nachricht zurücknehmen.
• Teilen Sie die Sitzung. Auf Team und Enterprise setzen Sie die Sichtbarkeit einer Sitzung auf „Team“, damit ein Revisor sehen kann, wie der Wechsel vorgenommen wurde. Commits von Cloud-Sessions enthalten einen Claude-Session-Trailer, der auf die Transkription verweist.
• Beobachten Sie Ihre Grenzen. Parallel-Sitzungen nutzen die Grenzen Ihres Plans parallel – daher verbrauchen fünf Sitzungen etwa fünfmal so schnell wie eine einzelne. Die Routinen haben ihre eigenen Stundenbegrenzungen, und Projekte können bis zu 200 neue Threads pro Tag starten.

Häufige Fragen

Wer kann Cloud-Sessions verwenden? Die Pro-, Max- und Team-Pakete sowie Enterprise-Benutzer mit einem Premium-Sitz oder einem Chat + Claude Code-Sitz, die mit einem claude.ai-Konto angemeldet sind, können Cloud-Sessions nutzen. Das ist nicht möglich mit einer Console-API-Kennung oder einem Drittanbieter-Anbieter. Siehe die Cloud-Sessions-Dokumentation.

Wohin gehen meine Daten? Anthropic speichert das Sitzungsprotokoll, und wie lange diese gespeichert werden, hängt von Ihrem Plan und den Einstellungen für die Modellverbesserung ab. VMs werden nach einer Zeit der Inaktivität wieder freigegeben, und das Löschen einer Sitzung entfernt ihre Daten. Siehe Datenverwendung und Sicherheit.

Wird Claude auf den Daten meiner Cloud-Sitzungen trainiert? Die Cloud-Sitzungen folgen derselben Politik wie der Rest von Claude Code. Bei Team, Enterprise und der API trainiert Anthropic keine Modelle auf Ihrem Code oder Prompts, es sei denn, Ihre Organisation stimmt dazu. Bei Free, Pro und Max hängt das von Ihrer Modellverbesserungs Einstellung ab. Siehe Datenverwendung.

Wird es mein großes Repository bewältigen? Die VM verfügt über etwa 4 vCPUs, 16 GB RAM und 30 GB Festplattenspeicher. Leichte Installationen sollten in einen Setup-Skript gelegt werden, damit sie einmal ausgeführt werden und in den gespeicherten Snapshot gelangen.

Was ist mit GitLab oder Bitbucket? claude --cloud kann ein Bundle aus jedem git-Repositorium hochladen, aber die Sitzung kann nicht zu diesen Hosts gepusht werden. GitHub Enterprise Server wird auf Team und Enterprise unterstützt. Siehe die Plattformbeschränkungen.

Was passiert, wenn parallele Zweige im Konflikt geraten? Die Sitzungen kennen sich nicht miteinander. Vereine eine Branch zusammen, dann Senden Sie die nächste Sitzung als Nachricht wie zum Beispiel claude -p "rebase on main and fix any conflicts" --cloud <session-id>.

Werde ich meine lokalen Tools verlieren? Die Benutzer-Ebene-Konfiguration geht nicht mit, also verschieben Sie das, was das Team benötigt, ins Repository: Committen Sie Fähigkeiten und Befehle unter .claude/, fügen Sie projektbezogene MCP-Server hinzu unter .mcp.json und dokumentieren Sie Testbefehle in CLAUDE.md. Die Einstellungen in Cloud-Sessions listet, was jede Session liest.

Beginnen Sie in fünf Minuten

Die Einrichtung dauert etwa fünf Minuten. Danach kann man eine Aufgabe übergeben, den Laptop schließen und zu einer Branch zurückkehren, die bereit für die Überprüfung ist.

1. Öffnen Sie claude.ai/code, oder führen Sie den /login Befehl in Claude Code mit Ihrem claude.ai-Konto aus.
2. Verbinden Sie GitHub und installieren Sie die Claude GitHub-App, in der Ihr Repositorium liegt.
3. Wählen Sie den Repositorium und die Standardumgebung aus.
4. Geben Sie Claude eine Aufgabe aus Ihrem Backlog, mit einer Anweisung, die zeigt, dass sie erledigt ist.
5. Schließen Sie die Tabe. Kontaktieren Sie später aus Ihrem Telefon, dann prüfen Sie den Diff und erstellen Sie den Pull-Request unter claude.ai/code.