Claude Code einrichten: Projects Beta richtig nutzen

Wer Claude Code einrichten und Entwicklungsarbeit über mehrere Cloud-Threads koordinieren möchte, bekommt mit Claude Code Projects eine zentrale Unterhaltung: Sie bündelt den Arbeitsstrom, startet für einzelne Aufgaben separate Cloud-Threads und behält deren Fortschritt im Blick. Der eigentliche Gewinn sind nicht mehr Chatfenster. Entscheidend ist, dass Repository-Kontext nicht ständig neu erklärt, Sessions nicht von Hand verteilt und der richtige Branch oder Pull Request nicht lange gesucht werden muss.

Die überarbeitete Oberfläche wird seit dem 17. September 2026 schrittweise freigeschaltet; der Zugang bleibt vorerst ausgewählten Konten vorbehalten. Diese Anleitung zeigt, wie sich der eigene Zugang prüfen, ein entbehrliches Repository als Testprojekt einrichten, zwei voneinander unabhängige Aufgaben verteilen und die entstandene Arbeit kontrollieren lässt. Außerdem wird klar, welcher Kontext in jeden Thread übernommen wird.

Claude Code Projects koordiniert – es ist kein Ordner

Ein Claude Code Project besteht aus einer dauerhaften Unterhaltung mit Claude und den Cloud-Sessions, die daraus als Threads gestartet werden. Die Unterhaltung funktioniert wie die Werkstattleitung in einer Modellbauwerkstatt: Dort landet der Auftrag, während getrennte Arbeitsplätze die einzelnen Jobs erledigen. Jeder Arbeitsplatz hat einen eigenen Workspace, ein eigenes Kontextfenster und einen eigenen Git-Branch. Die Leitung sammelt die Berichte ein und hält die Warteschlange geordnet.

Damit unterscheidet sich die Funktion von der früheren Projects-Oberfläche in Claude Chat und Cowork. Die ältere Variante gruppiert Unterhaltungen und Referenzdateien. Die neue Claude Code Projects Beta ergänzt einen Koordinator, der Aufgaben an Cloud-Threads verteilt, ihren Status verfolgt und Projektkontext in neue Threads mitnimmt.

Jeder Thread startet mit den Repositories und Dateien des Projekts, den Anweisungen, dem Memory, der gewählten Cloud-Umgebung und den Account-Connectors. Hinzu kommen die CLAUDE.md, Skills und Plugins aus den Repositories. Tools, die ausschließlich auf dem eigenen Rechner vorhanden sind, werden nicht übernommen.

Wer bereits für einen passenden Claude-Tarif bezahlt, muss für die Software selbst kaum neu rechnen. Claude Pro kostet monatlich $20 oder umgerechnet $17 pro Monat bei einer jährlichen Zahlung von $200; Max beginnt bei $100 pro Monat. Für Projects fällt keine separate Gebühr für virtuelle Cloud-Maschinen an. Der Haken ist das Nutzungslimit: Jeder Thread ist eine vollständige Claude Code Session. Parallele Arbeit verbraucht das Kontingent desselben Tarifs daher schneller.

Zum Vergleich: Die für diese Anleitung geprüften Einzelabonnements für Coding-Agenten von GitHub Copilot und Cursor reichen von $10 bis $200 pro Monat. Wenn Claude bereits als Coding-Agent dient, ist Projects kein zusätzlicher Platz im Software-Stack. Die Koordination verändert sich – die Verantwortung für technische Entscheidungen nicht.

Zuerst prüfen: Ist die Projects Beta für das Konto verfügbar?

Eine irgendwo in Claude sichtbare Funktion namens Projects reicht noch nicht als Nachweis für den Zugang.

1. Mit einem Claude Pro- oder Max-Konto anmelden.
2. claude.ai/code oder den Tab Code in der Desktop-App öffnen.
3. In der linken Seitenleiste nach Projects suchen.
4. Fehlt der Eintrag, hat die Freischaltung das Konto noch nicht erreicht. In diesem Fall bleibt nur, sich in Anthropics Warteliste einzutragen und vorerst gewöhnliche Cloud-Sessions zu verwenden.

Die erste Freischaltungswelle bevorzugt Pro- und Max-Konten, die bereits Cloud-Sessions genutzt haben und noch keine älteren Projects in Claude Chat oder Cowork besitzen. Team- und Enterprise-Konten erhalten diese neu gestaltete Beta noch nicht. Vorhandene ältere Projects funktionieren weiter, während Anthropic die Oberfläche migriert.

Falls Claude Code noch installiert, authentifiziert und über eine CLAUDE.md auf Repository-Ebene mit Kontext versorgt werden muss, hilft zuerst die allgemeine Einrichtungsanleitung für Claude Code. Projects baut auf diesen Repository-Praktiken auf und ersetzt sie nicht.

Claude Code einrichten: das erste Project mit einem Test-Repository

Für den Einstieg eignet sich ein kleines GitHub-Repository, das sich ohne Folgen verwerfen lässt. Im ersten Durchlauf geht es darum, Routing, Kontext, Branches und Nutzung zu untersuchen – nicht darum, einem Beta-Koordinator eine Produktivmigration anzuvertrauen.

1. Vor dem Project den GitHub-Zugriff klären

Für Codearbeiten muss das Repository auf github.com liegen. Das verbundene GitHub-Konto benötigt Push-Zugriff, und die Claude GitHub App muss für dieses Repository installiert sein. Ein über /web-setup erzeugtes Token kann einer gewöhnlichen Cloud-Session zwar das Klonen eines Repositorys ermöglichen, reicht für einen Project-Thread aber nicht aus.

GitHub Enterprise Server, GitLab und Bitbucket werden in dieser Beta nicht als Code-Repositories für Projects unterstützt. Gehört das Repository einer Organisation, muss möglicherweise ein Organisationsinhaber die Installation der GitHub App und die SSO-Autorisierung genehmigen.

2. Ein eng abgegrenztes Project anlegen

Unter Projects den Befehl New project wählen und Folgendes hinzufügen:

• Name: eine eindeutig vorläufige Bezeichnung wie Parser Project Test.
• Goal: einen Satz wie Improve parser coverage and documentation without changing behavior.
• Context: ausschließlich das entbehrliche Repository hinzufügen.

Pflichtfeld ist nur der Name. Ein eng gefasstes Ziel setzt dem Koordinator eine brauchbare Grenze, und ein einziges Repository vermeidet die unterschiedlichen Einstellungen, die bei Projekten mit mehreren Repositories ins Spiel kommen.

3. Eine dauerhafte Anweisung hinzufügen

Unter Project settings > Memory > Project instructions erhalten alle Threads dieselbe Definition of Done und dieselbe Grenze für Freigaben. Zum Beispiel:

Vom Standard-Branch ausgehen. Pro Thread einen eigenen Branch verwenden. Vor der Fertigmeldung die relevanten Tests ausführen. Ohne Rückfrage im Thread weder mergen noch CI ändern oder Abhängigkeiten hinzufügen. Bei fehlendem Zugriff das konkret fehlende Element nennen und anhalten.

Project instructions dürfen bis zu 16,000 Zeichen umfassen, sollten beim ersten Test aber kurz bleiben. Repository-spezifische Build-Befehle gehören weiterhin in die CLAUDE.md des jeweiligen Repositorys. Anforderungen, Entscheidungen und Fallstricke, die sich im Verlauf des Projekts ergeben, gehören ins Project Memory.

4. Die Cloud-Umgebung kontrollieren

Unter Project settings > Environment ist die Umgebung hinterlegt, die jeder neue Thread verwendet. Sie bestimmt den Netzwerkzugriff, Umgebungsvariablen, API-Zugangsdaten und die über ein Setup-Skript installierten Tools.

Die von Anthropic bereitgestellte Standardumgebung erreicht eine Positivliste gängiger Dienste und enthält vorinstallierte Tools. Auf die lokale Datenbank, das VPN, einen Geräteemulator, die Shell-Konfiguration oder Zugangsdaten, die nur auf dem Laptop liegen, greift sie nicht automatisch zu. Bevor eine Aufgabe von solchen Ressourcen abhängt, muss die Umgebung entsprechend eingerichtet sein.

5. Zwei Aufgaben senden, die sich nicht überschneiden können

Beide Aufgaben gehören in dieselbe Nachricht. So wird sichtbar, wie der Koordinator unabhängige Arbeit aufteilt. Die Änderungen sollten in unterschiedlichen Dateien stattfinden. Ein Beispiel:

Ohne Rückfrage sofort beginnen. Einen Thread erstellen, der Unit-Tests für fehlerhafte Parser-Eingaben ergänzt. Einen zweiten Thread erstellen, der veraltete Beispiele in der API-Anleitung korrigiert. Das Produktionsverhalten des Parsers nicht ändern und keinen der beiden Branches mergen.

Laut Anthropic werden mehrere voneinander unabhängige Aufgaben aus einer Nachricht in separate Threads überführt. Sofern nichts anderes vorgegeben ist, legt jeder Code-Thread vom Standard-Branch des Repositorys einen eigenen Branch an. Getrennte Dateien sind wichtig, weil auch separate Branches kollidieren können, sobald zwei Threads denselben Code ändern.

6. Die Threads prüfen, nicht nur die Zusammenfassung des Koordinators

Jede Thread-Karte öffnen und Folgendes festhalten:

Overview gruppiert die Arbeit in Ready for review, Waiting on you, Working, Landing, Idle und Resolved. Die weiteren Tabs sammeln Projektdateien, Pull Requests und Routinen. Der Koordinator sieht die Berichte der Threads, aber nicht jeden einzelnen Arbeitsschritt. Für eine Prüfung bleibt deshalb das Thread-Transkript maßgeblich.

7. Prüfen, ob spätere Arbeit den gespeicherten Kontext kennt

Wenn beide Threads fertig sind, soll sich der Koordinator eine harmlose Regel merken, etwa Documentation changes must preserve every runnable example. Anschließend wird ein neuer, kleiner Dokumentations-Thread gestartet, der vor seiner ersten Änderung die Branch-Regel und die Dokumentationsregel des Projekts nennen soll.

Damit werden zwei getrennte Kontextpfade geprüft. Project instructions sollten jeden neuen Thread als feste Vorgabe erreichen. Project Memory sollte die gespeicherte Entscheidung über MEMORY.md weitergeben. Die CLAUDE.md eines Repositorys bildet eine dritte, eigenständige Ebene für Regeln, die zum Codebestand selbst gehören.

Was ein Thread übernimmt – und was zurückbleibt

Projects wird am schnellsten missverstanden, wenn ein Cloud-Thread als entfernte Kopie des eigenen Laptops gilt. Das ist er nicht. Er ist eine neue Cloud-Session, deren Kontext aus Projekt, Repository, Konto und Umgebung zusammengesetzt wird.

Bei mehreren Repositories gibt es einen wichtigen Fallstrick. Zwar werden sämtliche CLAUDE.md-Dateien, Skills und Plugins dieser Repositories geladen, nicht jedoch ihre Berechtigungsregeln, Hooks und env-Einstellungen. Repository-übergreifende Regeln gehören in die Project instructions, Umgebungsvariablen in die Cloud-Umgebung.

Parallele Threads sind nicht unbegrenzt verfügbar

Anthropic nennt keine feste Zahl gleichzeitig ausführbarer Threads. Der Koordinator kann angewiesen werden, jeweils zwei parallel zu starten; das ist jedoch eine Präferenz und kein erzwungenes Kontingent. Die getrennte, harte Obergrenze liegt bei 200 neuen Threads pro Tag über alle Projects hinweg.

Laufende Threads verbrauchen das Tarifkontingent. Auch der Koordinator greift darauf zurück, während er Berichte liest und den nächsten Schritt entscheidet. Beobachtet ein Thread einen Pull Request, wird er erneut aktiv und nutzt den Tarif, sobald CI fehlschlägt oder ein Review-Kommentar eingeht. Ein inaktives Project ohne laufende Threads, beobachtete Pull Requests oder neue Nachrichten verbraucht im Ruhezustand nichts.

Neue Projects verwenden standardmäßig Opus mit high effort für Threads und low effort für den Koordinator. Vor einem großen Aufgabenpaket sollte unter Project settings > General für jeden Job das günstigste geeignete Modell samt passender Effort-Stufe gewählt werden. Anschließend empfiehlt sich eine kleine Zahl gleichzeitiger Threads. Entscheidend ist nicht, wie viele Threads Projects starten kann, sondern wie viele Ergebnisse sich prüfen lassen, bevor aus der Warteschlange bloßes Rauschen wird.

Die sieben sinnvollsten Einsatzszenarien

1. Plattformverantwortliche koordinieren eine Migration über mehrere Repositories

Server-, Web- und Mobile-Repository werden verbunden und erhalten ein gemeinsames Ziel: einen veralteten Endpunkt stillzulegen. Separate Threads können jeden Aufrufer auf einem eigenen Branch aktualisieren, während der Koordinator Reihenfolge und Blockaden verfolgt. Statt drei manuell synchronisierter Agenten-Sessions entsteht eine einzige Review-Warteschlange. Das ist der stärkste Anwendungsfall, weil das Ziel länger als eine Session besteht und sich die Arbeit sauber nach Repository teilen lässt.

2. Maintainer bearbeiten die Fehlerwarteschlange eines Dienstes

Neue Fehlerberichte und Stacktraces können fortlaufend in dasselbe Project eingefügt werden. Der Koordinator weist eine Regression entweder dem Thread zu, der diesen Bereich bereits untersucht, oder startet mit den gespeicherten Fallstricken des Projekts einen neuen. Wiederholte Einweisungen entfallen, und es bleibt nachvollziehbar, welcher Fehler auf Zugriff, Review oder eine Entscheidung wartet.

3. Release-Verantwortliche führen unabhängige Freigabeprüfungen aus

Testsuite, Dokumentationslinks, Abhängigkeitsprüfung und Entwurf der Release Notes gehen an getrennte Threads. Bis zur Prüfung der Ergebnisse bleiben alle Aufgaben schreibgeschützt. Der Koordinator kann bestandene Kontrollen und offene Fragen sichtbar machen, ohne die Belege in einem riesigen Transkript zu vermischen. So verkürzt sich der Weg von der Checkliste zur Entscheidung, während die letzte Freigabe bei der verantwortlichen Person bleibt.

4. Refactoring-Verantwortliche teilen große Änderungen nach Grenzen auf

Ist eine Migration größer als ein Kontextfenster, lassen sich unabhängige Module oder Pakete getrennten Threads zuweisen; die unveränderliche Vorgabe steht in den Project instructions. Jeder Thread validiert seinen eigenen Branch und meldet das Ergebnis zurück. Das ermöglicht parallelen Fortschritt mit einer gemeinsamen Definition of Done. Überschneiden sich die Architekturgrenzen, bleibt jedoch das übliche Risiko: Zwei Branches, die dieselbe gemeinsame Abstraktion ändern, können weiterhin Merge-Konflikte erzeugen.

5. Agenturentwickler betreuen eine Kundenanwendung

Für Repository, Anweisungen und Umgebung eines Kunden wird ein eigenes privates Project angelegt. Während der Zusammenarbeit nimmt es kleine Korrekturen, Review-Aufträge und Dokumentationsarbeit auf. Der Kontext bleibt erhalten, ohne Kundendaten zu vermischen. Da Projects während der Beta einer einzelnen Person gehören und nicht geteilt werden können, ist dies eine persönliche Auslieferungszentrale – kein Portal für die Zusammenarbeit mit dem Kunden.

6. Support-Engineering-Leads untersuchen wiederkehrende Integrationsfehler

Projects setzt kein Repository voraus. Ein Export von Support-Tickets und die Integrationsdokumentation können hochgeladen werden; anschließend klassifizieren Threads die Fehler, prüfen Beispiele und entwerfen eine Problemlösungsübersicht. Die Ausgabedateien landen in Library. Der Nutzen liegt in einem wiederverwendbaren Project-Kontext und getrennten Beweisspuren für Analyse und Textarbeit.

7. Solo-Gründer arbeiten einen gemischten Backlog ab

Ein kleines Paket kann eine Testaufgabe, eine Dokumentationsaufgabe und ein Repository-Audit enthalten. Der Koordinator erhält die Vorgabe, nur zwei Threads gleichzeitig auszuführen und jede destruktive Änderung zuerst vorzuschlagen. Statt jede Session zu beaufsichtigen, müssen nur die fertigen Branches geprüft werden. Ungeeignet ist dieses Vorgehen, wenn jede Aufgabe dieselbe Datei oder einen Dienst benötigt, der ausschließlich vom Laptop des Gründers erreichbar ist.

Drei sinnvolle Begleitprodukte

Für die Beta ist keine dokumentierte Projects API verfügbar. Kurzfristig aussichtsreich sind deshalb Produkte, die neben diesem Workflow arbeiten: Sie bereiten Kontext vor, untersuchen den GitHub-Status oder unterstützen Menschen bei der Prüfung der Ergebnisse.

1. Project Readiness Auditor: die stärkste Chance

Eine schreibgeschützte GitHub App könnte prüfen, ob ein Repository für Coding-Agenten in der Cloud vorbereitet ist. Untersucht würden Repository-Anweisungen, Testbefehle, Branch-Schutzregeln, die Abdeckung durch die GitHub App, erforderliche Secrets und Netzwerkabhängigkeiten. Das Ergebnis wären ein Entwurf für Project instructions und eine Checkliste für die Cloud-Umgebung.

Die Nachfrage nach dieser Aufgabe ist bereits sichtbar: „ai powered coding agent“ erreicht in den USA 8,100 Suchanfragen pro Monat und hat kommerziellen Search Intent. Die für diese Anleitung geprüften offiziellen Einzelabonnements für Coding-Agenten kosten zwischen $10 und $200 pro Monat. Ein bezahlter Zugang allein macht ein Repository dennoch nicht sicher für parallele Cloud-Arbeit.

Die kleinste verkaufbare Version scannt ein GitHub-Repository, stellt sechs Fragen zur Umgebung und exportiert eine direkt einsetzbare Vorgabe. Das Risiko liegt bei den Plattformen: Anthropic oder GitHub könnten solche Einrichtungsprüfungen schnell selbst integrieren. Das Produkt braucht deshalb Unterstützung für mehrere Agenten und einen nützlichen Audit-Verlauf statt nur einer Claude-spezifischen Vorlage.

2. KI-Board für den Delivery Lifecycle

Ein GitHub-basiertes Board könnte Branches, Pull Requests, CI-Status, Review-Kommentare und menschliche Freigaben nach Auslieferungsziel gruppieren. Es richtet sich an technische Leads, die mehrere Coding-Agenten einsetzen und eine neutrale Review-Oberfläche benötigen.

„AI software development life cycle“ erreicht in den USA 720 Suchanfragen pro Monat, hat eine Keyword Difficulty von 4 und einen CPC von $18.13. Die kleinste Version liest GitHub-Ereignisse und ordnet sie vier Zuständen zu: in Arbeit, blockiert, prüfbereit und ausgeliefert. Privater Zugriff auf das Transkript eines Claude Project ist dafür nicht erforderlich.

Die Schwierigkeit ist die Abgrenzung. GitHub und die Anbieter von Agenten zeigen bereits einen großen Teil dieses Status. Erfolg hat das Produkt nur, wenn es Arbeit anbieterübergreifend verbindet, Freigaben nachweisbar festhält und erklärt, weshalb eine Änderung blockiert ist, statt lediglich eine hübschere Warteschlange zu zeichnen.

3. Automatischer Router für Review-Richtlinien

Eine GitHub App könnte Repository-spezifische Review-Vorgaben auf Pull Requests anwenden, die von Agenten erstellt wurden. Bei Parser-Änderungen könnte sie ein Testartefakt verlangen, Billing-Änderungen an eine bestimmte prüfende Person leiten und verhindern, dass Auto-Fix-Kommentare privilegierte Automatisierungen auslösen.

„Automated code review“ erreicht in den USA 210 Suchanfragen pro Monat und hat einen CPC von $63.33. Das ist ein starkes Signal für eine kleinere Zielgruppe mit hoher Zahlungsbereitschaft. Für das MVP genügen eine Richtliniendatei, eine Pull-Request-Prüfung und eine knappe Erklärung der fehlenden Nachweise.

Auch hier drohen Überschneidungen. Claude-Threads beobachten bereits Pull Requests und reagieren auf fehlgeschlagene CI-Läufe sowie Review-Kommentare. Ein neues Produkt muss Risiken über Agenten und Repositories hinweg steuern, statt lediglich einen weiteren Reviewer-Bot nachzubauen.

Welche Probleme Claude Code Projects nicht löst

Projects eignet sich am besten für teilbare Arbeit, deren notwendiger Kontext in GitHub, hochgeladenen Dateien, Connectors oder einer Cloud-Umgebung verfügbar ist. Für eine einmalige Korrektur, die in eine Session passt, für Aufgaben an einem lokalen Gerät oder VPN und für Teams, in denen mehrere Personen dasselbe Project steuern müssen, ist es das falsche Tool.

Auch die üblichen Auslieferungsrisiken bleiben bestehen:

• Separate Threads können Merge-Konflikte erzeugen, wenn sich ihre Branches überschneiden.
• Eine Vorgabe zur Parallelität ist eine Anweisung an den Koordinator, keine harte Budgetkontrolle.
• Parallele Threads können das Pro-Kontingent schnell aufbrauchen.
• Wird eine pausierte Sandbox aus einem frischen Klon fortgesetzt, können nicht committete Änderungen verloren gehen.
• Die Beta ist persönlich und bietet weder Project Sharing noch Kontrollen auf Organisationsebene.
• Ein Thread lässt sich später nicht in ein anderes Project verschieben.

Das nüchterne Fazit: Projects sollte teilbare Arbeit koordinieren, nicht Architekturentscheidungen oder Freigaben auslagern. Am Anfang stehen zwei Aufgaben und die Prüfung beider Transkripte. Erst wenn Branches und Nutzung berechenbar wirken, lohnt sich mehr Parallelität.

Häufig gestellte Fragen

Hat Claude Code Zugriff auf Projects?

Ausgewählte Claude Pro- und Max-Konten können die neu gestaltete Projects Beta unter claude.ai/code, im Desktop-Tab Code und in den mobilen Apps von Claude verwenden. Fehlt Projects in der Code-Seitenleiste, hat die Freischaltung das betreffende Konto noch nicht erreicht. Der Terminal-Befehl claude project verwaltet einen davon unabhängigen lokalen Verzeichnisstatus.

Wie lassen sich Projects in Claude Code nutzen?

In Claude Code ein Project anlegen, ein Ziel und nur die wirklich benötigten Repositories oder Dateien hinzufügen, eine kurze dauerhafte Anweisung formulieren und die Cloud-Umgebung wählen. Danach gehen eine oder mehrere Aufgaben an die Koordinator-Unterhaltung. Vor jedem Merge sollten in Overview für jeden Thread Branch, Transkript, Validierung und Nutzung geprüft werden.

Kann Claude Code an einem bestehenden Projekt arbeiten?

Ja. Ein Project kann um ein vorhandenes Repository auf github.com angelegt oder aus einer vorhandenen Cloud-Session über Continue as a project fortgesetzt werden. Code-Repositories benötigen Push-Zugriff über das verbundene GitHub-Konto, außerdem muss die Claude GitHub App für sie installiert sein.

Was unterscheidet Claude Projects von Claude Code?

Claude Code ist der Coding-Agent, der in einer lokalen oder einer Cloud-Session läuft. Ein neu gestaltetes Claude Code Project bildet die Koordinationsebene: Eine Unterhaltung startet und verfolgt mehrere Claude Code Cloud-Sessions, gibt ihnen gemeinsamen Project-Kontext und sammelt ihren Status. Die älteren Projects in Claude Chat und Cowork bleiben bis zu ihrer Migration das bekannte Workspace-Modell für Dateien und Unterhaltungen.

Wenn ein einsatzbereiter Agenten-Workflow rund um Repositories, Freigaben und Cloud-Umgebung gefragt ist, helfen KI-Produktionssysteme weiter.