Tips & Tricks (Aktualisiert: 7.6.2026)

Claude Code starten: In 30 Minuten von der Installation zum ersten Commit

Einstieg in Claude Code für Anfänger: Installation, erster Prompt und erster Commit in 30 Minuten - plus Stolperfallen für Einsteiger.

Claude Code starten: In 30 Minuten von der Installation zum ersten Commit

Du tippst claude ins Terminal und drückst Enter.

Dass danach irgendetwas passiert, sieht man sofort. Aber als ich es zum ersten Mal gemacht habe, stand auf dem Bildschirm nur „Bitte einloggen” — und dann bin ich gut fünf Minuten lang erstarrt. Wo soll ich mich einloggen? Kostet das was? Liest das jetzt meinen gesamten Code mit? Am Ende habe ich das Terminal an jenem Tag geschlossen, ohne eine einzige Zeile geändert zu haben.

Im Rückblick war die erste Hürde weder die Installation noch das Englisch, sondern die Frage: „Was soll ich nach dem Start eigentlich verlangen?” Genau da setzen wir hier an, auf dem kürzesten Weg. Installation → Login im Browser → erster Prompt → erster Commit, und das alles in 30 Minuten. Die drei Dinge, über die ich selbst gestolpert bin (Berechtigungen freigeben, das Gespräch wird träge, die erste Zeile in der CLAUDE.md), lege ich dir vorab in den Weg, damit du nicht hinfällst.

Die Suchintention ist simpel: „Claude Code starten”, „Claude Code für Anfänger”. Genau diese Antwort schreibe ich auf, ohne Umwege.

Das Wichtigste in Kürze

  • Die Installation läuft über den offiziellen Installer. Auf macOS/Linux per curl ... | bash, auf Windows per irm ... | iex. Wer lieber Node.js nimmt: npm i -g @anthropic-ai/claude-code (Node 18 oder höher).
  • Die Anmeldung läuft über den Browser. Beim Start von claude öffnet sich der Login. Du brauchst ein Abo wie Claude Pro/Max oder einen Console-Account (der kostenlose Claude.ai-Tarif reicht nicht).
  • In den ersten 30 Minuten lässt du nichts umschreiben. Erst lesen lassen, dann erklären lassen, dann genau eine Datei reviewen — in dieser Reihenfolge gewöhnst du dich ein.
  • Das Ziel ist der erste Commit. Gewöhne dir vom ersten Tag an, das Diff mit eigenen Augen zu prüfen, bevor du committest.
  • Die drei klassischen Anfängerfehler: nicht alle Berechtigungen freigeben, bei trägem Gespräch komprimieren und in die CLAUDE.md eine Zeile schreiben, wie man die Tests startet.

Der Reihe nach. Ich zeige nur Code, der sich tatsächlich per Copy & Paste ausführen lässt.

Erst der Überblick: die Landkarte für 30 Minuten

Bevor wir in die einzelnen Schritte gehen, zeige ich dir die Landkarte bis zum Ziel. Damit verläufst du dich seltener.

ZeitAufgabeZiel
0–5 MinInstallieren + im Browser einloggenclaude startfähig machen
5–10 MinÜbungs-Branch anlegenEine Basis schaffen, zu der man zurück kann
10–20 MinLesen lassen, erklären lassenVerstehen, worauf die Antworten beruhen
20–25 MinEine kleine Änderung beauftragenDen Ablauf Bearbeiten → Diff prüfen erleben
25–30 MinDer erste CommitSich angewöhnen, bewusst selbst zu entscheiden

Der wichtigste Punkt: Am ersten Tag kein großes Refactoring. Aufträge wie „mach diese Codebasis mal sauber” haben Zeit, bis du dich eingespielt hast. Anfangs klein und im umkehrbaren Rahmen.

Schritt 1: Installieren (0–3 Min)

Bis vor Kurzem war „über npm installieren” der Standard, doch der heutige offizielle Favorit ist der dedizierte Installer. Er kümmert sich nicht darum, ob Node.js vorhanden ist.

Für macOS / Linux / WSL nimmst du das hier:

curl -fsSL https://claude.ai/install.sh | bash

In der Windows-PowerShell das hier:

irm https://claude.ai/install.ps1 | iex

Wer sagt „ich will das selbst über Node.js verwalten”, installiert wie gewohnt per npm. Dafür ist Node.js 18 oder höher nötig.

npm install -g @anthropic-ai/claude-code

Prüfen, ob es geklappt hat. Wenn eine Versionsnummer erscheint, passt es.

claude --version

Falls hier command not found auftaucht, sagt dir claude doctor, woran es liegt.

claude doctor

Eine Sache noch. Auch wenn ein Berechtigungsfehler kommt, tippe nicht reflexartig sudo npm install -g. Auch die offizielle Doku stellt klar: bitte vermeiden, weil das zu Rechte- und Sicherheitsproblemen führt. Ruhig bleiben und der Anweisung von claude doctor folgen ist schneller.

Schritt 2: Im Browser einloggen (3–5 Min)

Nach der Installation startest du das Programm.

claude

Beim ersten Mal landest du automatisch im Login. Der Browser öffnet sich, und du folgst einfach den Anweisungen am Bildschirm. Einmal durchlaufen, werden die Zugangsdaten gespeichert und du wirst danach nicht mehr gefragt.

Wo Anfänger hier oft hängen bleiben: „Ja, aber mit welchem Konto?” Sortiert sieht das so aus:

  • Ein Abo wie Claude Pro / Max / Team / Enterprise … für den Einstieg als Einzelperson am bequemsten (Empfehlung).
  • Anthropic Console (API mit vorausbezahltem Guthaben) … für alle, die mit API-Keys arbeiten oder Kosten zentral steuern wollen.
  • Amazon Bedrock / Google Vertex AI / Microsoft Foundry … wenn die Cloud-Strategie der Firma bereits feststeht.

Ein Hinweis, der vielen Ärger erspart: Mit dem kostenlosen Claude.ai-Tarif lässt sich Claude Code nicht nutzen. Wer das nicht weiß, grübelt lange über „ich kann mich nicht einloggen”, deshalb schreibe ich es vorab hin.

Wenn du das Konto wechseln willst, tippe in der laufenden Session /login, um dich neu zu authentifizieren.

Schritt 3: Einen Ort schaffen, an den du zurück kannst (5–10 Min)

Das wirkt unscheinbar, ist aber wichtig: Spiel nicht gleich im echten Produktiv-Repository herum. Öffne ein kleines Übungs-Repository oder ein privates Projekt, bei dem nichts kaputtgeht, wenn etwas schiefläuft.

Wenn du es an echtem Arbeitscode ausprobierst, lege unbedingt einen Arbeits-Branch an.

git status
git switch -c try-claude-code

Warum zuerst git status? Damit du keine noch nicht committeten Änderungen mit hineinziehst. Wenn der Ausgangszustand unklar ist, weißt du später nicht mehr: „Ist dieses Diff von der KI oder von mir?” Genau das habe ich am ersten Tag tatsächlich verbockt.

In diesem Ordner startest du dann Claude Code.

cd /path/to/your/project
claude

Nach dem Start siehst du oben die Version, das verwendete Modell und das Arbeitsverzeichnis. Mit /help bekommst du die Liste der Befehle.

Schritt 4: Zuerst nur „lesen lassen” (10–20 Min)

Jetzt geht es richtig los. Aber wir lassen immer noch nichts umschreiben. Anfangs nur lesen und erklären lassen. Allein damit bekommst du ein Gefühl dafür, worauf Claude Code seine Antworten stützt.

Im interaktiven Modus sprichst du einfach in natürlicher Sprache. Komplizierte Syntax brauchst du nicht.

Lies nur README.md und package.json und erkläre mir auf Deutsch, was das Ziel
dieses Projekts ist und wie man es startet.

Der Trick steckt im „nur”: den Umfang eng halten. Wenn Claude Code als Anfänger gleich Unmengen an Dateien liest, kannst du nicht mehr nachvollziehen, woher eine Antwort kommt. Das hängt direkt mit dem später erklärten Problem „das Gespräch wird träge” zusammen.

Wenn du dich sicherer fühlst, lässt du eine einzelne Datei reviewen.

Lies nur src/utils/date.ts und nenne mir höchstens drei Stellen, die zu Bugs
führen könnten. Ändere noch nichts.

Das „ändere noch nichts” sorgt dafür, dass sich Review und Umsetzung nicht vermischen. Erst das Lesen der Vorschläge üben, Hand anlegen kommt im nächsten Schritt.

Übrigens: Wenn du eine Recherche oder Routineaufgabe nur einmal schnell durchziehen willst, ist statt des interaktiven Modus der One-Shot praktisch. Mit -p gibt das Tool ein Ergebnis zurück und beendet sich.

claude -p "Führe git log --oneline -10 aus und fasse die Änderungen auf Deutsch zusammen."

Meine Aufteilung ist simpel: iteratives Implementieren im interaktiven Modus, Nachschlagen und Zusammenfassen als One-Shot. Anfangs reichen diese beiden völlig aus.

Schritt 5: Die erste kleine Änderung (20–25 Min)

Wenn du das Lesen geübt hast, lässt du endlich etwas umschreiben. Zu Beginn in der Einheit „eine Datei, eine Funktion”.

Im interaktiven Modus formulierst du das so:

Füge der Funktion getUserById in src/api/users.ts genau einen Unit-Test hinzu.
Halte dich an den Stil der bestehenden Tests.

Und jetzt fragt Claude Code zwingend nach: „Darf ich diese Änderung anwenden?” Es schreibt Dateien nie eigenmächtig um. Du siehst dir das vorgeschlagene Diff an und gibst es frei, wenn du überzeugt bist. Das ist die voreingestellte Sicherung.

Hier lauert die erste Falle. Weil mir das Bestätigen bei jedem Schritt zu lästig war, habe ich früh den „alles erlauben”-Modus angeschaltet. Prompt wurden Dateien „gleich mit aufgeräumt”, um die ich nie gebeten hatte — mir wurde ganz anders. Die Lehre: Anfangs jeden Schritt einzeln freigeben ist am Ende der schnellste Weg. Wenn du die Berechtigungen feiner einstellen willst, lies den weiter unten verlinkten Spezialartikel.

Sobald du die Änderung angenommen hast, prüfst du das Diff unbedingt mit eigenen Augen.

git diff
npm test

„Sieht aus, als würde es laufen” und „es ist genau das beabsichtigte Diff” sind zwei verschiedene Dinge. Mach Diff und Test zum festen Paar.

Schritt 6: Der erste Commit (25–30 Min)

Das Diff ist geprüft, die Tests sind grün. Bis hierher gekommen, ist das Ziel zum Greifen nah.

Auch den Commit kannst du in natürlicher Sprache verlangen.

Prüfe die Änderungen und committe sie mit einer verständlichen Commit-Nachricht.

Claude Code liest das git diff, überlegt sich eine Nachricht und holt vor dem Commit noch einmal deine Bestätigung ein. Natürlich kannst du es auch von Hand tippen.

git add src/api/users.ts
git commit -m "test: Unit-Test für getUserById ergänzt"

Damit ist die Runde „Installation → Login → lesen lassen → klein ändern → Diff prüfen und committen” einmal durch. In 30 Minuten hast du die kleinste sinnvolle Schleife von Claude Code mit eigenen Händen gedreht. Für den ersten Tag reicht das. Schließ das Terminal mit erhobenem Kopf.

Per Copy & Paste lauffähig: die 30 Minuten als ein Startskript

Weil es mich nervt, mir jedes Mal die Befehle zu merken, lege ich mir ein Shell-Skript zurecht, das „eine Übungssession sicher beginnt”. Es legt einen Branch an und schickt gleich den Auftrag zum Lesen hinterher. Node.js ist nicht nötig, es läuft mit purem bash.

#!/usr/bin/env bash
# start-claude-practice.sh — Claude Code sicher zum Üben starten
set -euo pipefail

# 1) Prüfen, ob noch nicht committete Änderungen herumliegen (verhindert Kollateralschäden)
if [ -n "$(git status --porcelain)" ]; then
  echo "Achtung: Es gibt nicht committete Änderungen. Bitte vorher committen oder stashen."
  git status --short
  exit 1
fi

# 2) Übungs-Branch anlegen (mit Datum; falls vorhanden, nur wechseln)
BRANCH="try-claude-$(date +%Y%m%d)"
git switch -c "$BRANCH" 2>/dev/null || git switch "$BRANCH"
echo "OK: Es wird im Branch $BRANCH gearbeitet."

# 3) Zuerst den Auftrag "nur lesen" als One-Shot ausfuehren
claude -p "Lies die README, falls vorhanden, sonst die wichtigsten Dateien, und
erklaere mir Ziel, Startweg und die als Naechstes zu lesende Datei dieses Projekts
in drei Zeilen auf Deutsch. Aendere absolut nichts."

So benutzt du es:

chmod +x start-claude-practice.sh
./start-claude-practice.sh

Beim Ausführen stoppt das Skript, falls es nicht committete Änderungen gibt, und legt sonst einen Übungs-Branch an und gibt eine Zusammenfassung des Projekts aus. Es bündelt „Kollateralschäden vermeiden”, „einen Ort zum Zurückkehren schaffen” und „erst mal lesen lassen” in einem Skript. Das hätte ich mir an meinem ersten Tag gewünscht.

Die drei Dinge, über die ich anfangs gestolpert bin

Ab hier kommt das, was selten in Anleitungen steht, dich aber am ersten Tag am meisten quält, wenn du hineingerätst.

1. Von Anfang an alle Berechtigungen freigeben

Wie schon gesagt: Wenn dir das Bestätigen lästig wird und du auf „alles OK” stellst, baust du Unfälle. Anfangs ist es am sichersten, mit der Einstellung „Schreiben und Committen jedes Mal bestätigen, Löschen und Force-Push verbieten” zu arbeiten. In der .claude/settings.json legst du das so fest:

{
  "permissions": {
    "allow": ["Read(**)", "Grep(**)", "Bash(npm test*)", "Bash(git status*)", "Bash(git diff*)"],
    "ask": ["Write(**)", "Edit(**)", "Bash(git commit*)", "Bash(git push*)"],
    "deny": ["Bash(rm -rf*)", "Bash(git push --force*)"]
  }
}

„Lesen und Tests automatisch, Schreiben und Committen mit Rückfrage, gefährliches Löschen verboten.” Allein diese dreistufige Aufstellung verhindert fast alle Unfälle. Operationen, die du als sicher kennengelernt hast, befördest du später in allow hoch. Die feinere Ausgestaltung habe ich im Leitfaden zu den Claude-Code-Berechtigungen zusammengefasst — wer es ernsthaft durchplanen will, schaut dort hinein.

2. Das Gespräch wird träge (Kontext läuft voll)

Während du arbeitest, wird es ab einem bestimmten Punkt plötzlich zäh. Das ist kein Defekt, sondern ein Zeichen dafür, dass das Gespräch lang geworden ist und der „Kontext”, den Claude Code mitschleppt, zu sehr angeschwollen ist. Wie die Arbeitsfläche beim Kochen, die sich nach und nach mit benutztem Geschirr füllt.

Zwei Gegenmittel: Wenn ein Abschnitt abgeschlossen ist, komprimierst du das Gespräch oder setzt es ganz auf null.

/compact
/clear

/compact komprimiert und behält die Kernpunkte, /clear setzt komplett zurück. Wenn du das Gefühl hast „eben lief es noch flüssig”, greif ohne Zögern zu einem von beiden. Auch der eingangs erwähnte Tipp „den Lesebereich eng halten” wirkt hier: Je weniger überflüssige Dateien du lesen lässt, desto weniger vermüllt die Arbeitsfläche. Wie man die Ursache der Trägheit eingrenzt, steht ausführlich im Leitfaden zur Geschwindigkeitsoptimierung von Claude Code.

3. Die erste Zeile der CLAUDE.md nicht schreiben

Das gehört in die Kategorie „bin froh, dass ich es gemacht habe”. Claude Code liest automatisch die CLAUDE.md direkt im Projektstamm. Wenn du dort Projektinfos hinterlegst, musst du sie nicht jedes Mal aufs Neue erklären.

Was ich bereue: dass ich sie anfangs nicht geschrieben habe. So musste ich jedes Mal erklären „dieses Projekt ist TypeScript, getestet wird mit npm test”. Die eine einzige Zeile, die du als Erstes schreiben solltest, ist diese:

## Häufig genutzte Befehle
- Tests: npm test
- Dev-Server: npm run dev

Steht erst einmal drin, wie man die Tests startet, versucht Claude Code nach einer Änderung von selbst, die Tests laufen zu lassen. Umgekehrt: Wenn du von Anfang an eine riesige CLAUDE.md schreibst, werden die Vorgaben schlechter befolgt. Wo die Grenze zwischen „aufschreiben” und „weglassen” verläuft, habe ich gesondert in den CLAUDE.md-Best-Practices festgehalten.

Der nächste Schritt: vom Einzelauftrag zum „Übergeben”

Wenn dir die 30-Minuten-Schleife in Fleisch und Blut übergegangen ist, folgt die Stufe vom „Einzelbefehl” hin zu „eine zusammenhängende Aufgabe übergeben”. Aber selbst dann schalten wir nicht plötzlich auf Vollautomatik.

Die Reihenfolge ist immer dieselbe: ① den Lesebereich eng festlegen → ② das Ziel (das Ergebnis) klar machen → ③ Überprüfungen möglichst an Befehle delegieren → ④ gefährliche Operationen anfangs allesamt „den Menschen fragen” lassen. Diese Denkweise, der KI ein ordentliches „Gerüst” zu bauen, habe ich ausführlich im Leitfaden zum Bau eines Gerüsts (Harness) für Claude Code zusammengetragen. Wenn du ihn direkt nach diesem Einstieg liest, ändert sich die Aussicht schlagartig.

Auch die Art, Anweisungen zu geben, verändert das Ergebnis, sobald du dich eingespielt hast. Es gibt nur drei Kniffe:

  1. Dateinamen (möglichst mit Zeilennummer) angeben — das spart Suchaufwand.
  2. Das erwartete Verhalten konkret beschreiben — „mach es schön” versteht niemand.
  3. Einschränkungen mitgeben — „halte dich ans bestehende Muster”, „rühre keine anderen Dateien an”.
Füge der Funktion login in src/api/auth.ts eine Behandlung hinzu, die bei leerem
Passwort 400 zurückgibt. Halte dich beim Fehlertext an das Muster in
src/utils/errors.ts. Rühre keine anderen Dateien an.

Häufige Fragen

F. Kann ich es kostenlos nutzen? A. Claude Code selbst lässt sich mit dem kostenlosen Claude.ai-Tarif nicht nutzen. Du brauchst ein Abo wie Claude Pro / Max oder einen Console-Account mit vorausbezahltem Guthaben. Wer auf die Kosten achten will, findet im Leitfaden zum Verwalten der Claude-Code-/API-Kosten, wie man ein Budget festlegt.

F. Läuft es unter Windows genauso wie auf dem Mac? A. Ja. Nur die Installation ändert sich zu irm https://claude.ai/install.ps1 | iex (PowerShell); Start und Bedienung sind identisch. Wenn du Git Bash installierst, läuft ein Teil der Befehlsausführung geschmeidiger.

F. Brauche ich einen API-Key? A. Für den Einstieg als Einzelperson nicht. Am bequemsten ist es, claude zu starten und sich im Browser einzuloggen. Eine Konfiguration, die API-Keys über Umgebungsvariablen verwaltet, hat Zeit, bis die Authentifizierungsstrategie deines Teams oder die Cloud-Umgebung feststeht.

F. Wird nicht mein gesamter Code hochgeladen? A. Claude Code liest jeweils nur die Dateien, die es braucht. Du musst nichts manuell komplett übergeben, und .env, Produktiv-Keys oder Kundendaten gehören grundsätzlich nicht hineinkopiert. Die Mindestlinie in Sachen Sicherheit habe ich in den Sicherheits-Best-Practices für Claude Code zusammengefasst.

F. Das Standardmodell kommt mir träge und teuer vor. A. Für einfache Aufgaben kannst du mitten in der Session auf ein leichteres Modell umschalten. Mit /model wählst du das Modell aus — also leichtes Modell zum Nachschlagen, leistungsstarkes Modell für die schwierige Umsetzung. So arbeitest du angenehm.

Fazit: in 30 Minuten einmal die „kleinste Schleife” drehen

Der Einstieg in Claude Code ist, auf den Punkt gebracht, eine einzige Linie: Installation → Login im Browser → lesen lassen → klein ändern → Diff prüfen und committen. Wenn du diese 30-Minuten-Schleife einmal mit eigenen Händen gedreht hast, verschwindet das „ich weiß nicht, womit ich anfangen soll”.

Am ersten Tag baut man typischerweise nur drei Fehler: alle Berechtigungen freigeben, bei trägem Gespräch nicht komprimieren und keine Zeile zum Starten der Tests in die CLAUDE.md schreiben. Wer das vermeidet, dem fällt die erste Erfahrung deutlich leichter.

Diese Website (claudecode-lab.com) lasse ich täglich komplett mit Claude Code laufen — die Generierung der Artikel, die Übersetzung und das Deployment. Und das ausgerechnet ich, der anfangs zweifelte „kann das wirklich funktionieren?”. Nimm dir heute zuerst 30 Minuten. Tippe claude und geh den Weg bis zum ersten Commit.

Wenn du als Nächstes hängenbleibst, kannst du nach Art des Problems wählen, wohin es weitergeht. Willst du Befehle und sichere Formulierungen griffbereit haben, hilft der kostenlose Claude-Code-Spickzettel; willst du Konfiguration und Betrieb in einem Rutsch ordnen, ist die Lernmaterial-Übersicht der kürzeste Weg.

Die jeweils aktuellen Schritte findest du auch im offiziellen Claude Code Quickstart (Englisch). Installation und Authentifizierung ändern sich gelegentlich, schau im Zweifel also in die Primärquelle.

Was dabei herauskam, als ich das Beschriebene wirklich ausprobiert habe

Ich habe diese 30-Minuten-Schleife von einer befreundeten Frontend-Entwicklerin (jemand, der die Kommandozeile nicht gewohnt ist) neben mir durchspielen lassen. Am stärksten wirkte „anfangs nichts umschreiben lassen”. Überspringt man die Phase aus Lesen- und Erklärenlassen, erstarrt man vor dem ersten Änderungsvorschlag. Wer dagegen Erklärung → Review einer Datei dazwischenschob, erreichte den ersten Commit tatsächlich in knapp 30 Minuten.

Noch etwas wurde mir handgreiflich klar: die Wirkung der „einen Testzeile” in der CLAUDE.md. Steht sie drin, lässt Claude Code nach einer Änderung von sich aus npm test laufen, bemerkt selbst den Fehlschlag und beginnt zu reparieren. Steht sie nicht drin, muss man jedes Mal selbst „teste das” sagen. Der Unterschied von gerade einmal zwei Zeilen senkte die Zahl der Hin-und-her-Runden danach spürbar. Bevor man das schlauere Modell sucht, lieber ein Stück Gerüst in Ordnung bringen — auch beim Einstieg wirkt am Ende genau das am meisten.

#Claude Code #Einstieg #Anfänger #Tutorial #Installation
Kostenlos

Kostenloses PDF: Claude-Code-Cheatsheet

E-Mail eintragen und eine Seite mit Befehlen, Review-Gewohnheiten und sicheren Workflows herunterladen.

Wir schützen Ihre Daten und senden keinen Spam.

Masa

Über den Autor

Masa

Engineer für praktische Claude-Code-Workflows und Team-Einführung.