Claude Code auf einem Projekt gut zum Laufen zu bringen, erfordert etwa zehn Minuten Einrichtung. Der Lohn ist, dass Claude deine Konventionen ab der ersten Nachricht versteht, die richtigen Berechtigungen für nützliche Arbeit hat und sich für alle im Team konsistent verhält. Dieses Modul führt der Reihe nach durch die Einrichtungsschritte.
Projekt-Memory initialisieren
Beginne mit /init. Claude durchsucht deine Codebasis — liest package.json, vorhandene Dokumentation, Verzeichnisstruktur — und erzeugt eine CLAUDE.md , die deinen Tech-Stack, die wichtigsten Befehle und die anfänglichen Konventionen erfasst. Committe diese Datei sofort in git, damit Teamkollegen denselben Kontext erhalten.
Eine gute CLAUDE.md ist prägnant und spezifisch. Ziel sind unter 200 Zeilen pro Datei. Jede Zeile sollte für nahezu jede Session relevant sein — wenn etwas nur für ein Feature zählt, gehört es stattdessen in eine pfadbezogene Regeldatei. Die wertvollsten Abschnitte sind: Tech-Stack und Versionen, Entwicklungsbefehle (install, test, build, lint), nicht offensichtliche Namenskonventionen und bekannte Fallstricke, über die ein neuer Entwickler stolpern würde.
# Project: Payment Service
## Stack
- Node.js 20, TypeScript 5, PostgreSQL 15
- Express for API, Prisma for ORM, Jest for tests
## Commands
- `npm run dev` — start with hot reload
- `npm test` — run test suite
- `npm run migrate` — apply pending migrations
- `npm run lint` — ESLint + Prettier check
## Conventions
- All monetary values stored as integers (cents)
- Use `Result<T, E>` pattern for error handling, never throw in service layer
- Database columns: snake_case; TypeScript: camelCaseBerechtigungen konfigurieren
Claude Code arbeitet innerhalb eines Berechtigungssystems, das steuert, welche Tools es ohne Nachfrage verwenden kann. Der Standardmodus erfordert eine Freigabe für die meisten Dateischreibvorgänge und alle bash-Befehle. Für die aktive Entwicklung solltest du gängige Operationen vorab freigeben.
Öffne den Berechtigungsmanager mit /permissions. Füge Muster für die Befehle hinzu, die Claude wiederholt verwenden wird. Verwende Bash(git *) , um alle git-Befehle zu erlauben, Bash(npm *) für npm oder Bash(npx jest *) für ein bestimmtes Tool. Dateioperationen können auf bestimmte Pfade begrenzt werden.
Settings-Dateien steuern Berechtigungen auf Projekt- und Benutzerebene. .claude/settings.json wird für das Team in git committet. .claude/settings.local.json wird von git ignoriert für persönliche Overrides:
{
"permissions": {
"allow": [
"Bash(git *)",
"Bash(npm *)",
"Bash(npx *)",
"Read(**/*)",
"Write(src/**/*)",
"Edit(src/**/*)"
]
}
}Bei sensiblen Operationen wie Produktions-Deploys belässt du sie bei erforderlicher Freigabe oder verwendest disable-model-invocation: true bei Skills, damit Claude sie niemals automatisch auslösen kann.
Wenn eine Aufgabe Dateien außerhalb des Projekt-Roots benötigt — eine benachbarte Bibliothek, ein gemeinsames Types-Paket, ein generiertes Bundle — verwende --add-dir beim Start (oder /add-dir während der Session), um Claudes Arbeitsverzeichnisse für diese Session zu erweitern. Jeder Pfad muss als Verzeichnis existieren, und das Flag gewährt nur Dateizugriff, nicht den Rest der .claude/ -Konfiguration in diesem Baum:
# Start a session with read/edit access in two sibling directories
claude --add-dir ../shared-types --add-dir ../design-tokensUm diese Verzeichnisse über jede Session im Projekt hinweg beizubehalten, anstatt sie jedes Mal einzugeben, setze permissions.additionalDirectories in .claude/settings.json. --add-dir ist die temporäre, sessionbezogene Form derselben Berechtigung.
Sicherheit — Marketplace-Einschränkungen
Nutze blockedMarketplaces , um einzuschränken, welche Plugin-Marketplaces verwendet werden können. Einträge unterstützen hostPattern , um nach Domain zu blockieren (z. B. "*.example.com") und pathPattern , um nach Repository-Pfad zu blockieren (z. B. "acme/corp-plugins"):
{
"blockedMarketplaces": [
{ "hostPattern": "*.untrusted-domain.io" },
{ "pathPattern": "acme/corp-plugins" }
]
}Dies wird auf Policy-Ebene erzwungen — Benutzer können es nicht mit lokalen Einstellungen überschreiben. In der Managed Policy für Enterprise-Deployments verfügbar.
Beachte beim Schreiben von Plugin-Manifesten für dein Projekt, dass monitors und themes experimentell sind und unter experimental: {} deklariert werden sollten statt auf oberster Ebene von plugin.json. Deklarationen auf oberster Ebene funktionieren weiterhin, aber claude plugin validate gibt eine Warnung aus, und ein zukünftiges Release wird die verschachtelte Form erfordern.
Einstellungen und Umgebung
Einstellungen folgen dieser Rangfolge von der höchsten zur niedrigsten: (1) Managed Settings (können durch nichts überschrieben werden, auch nicht durch Kommandozeilenargumente), (2) Kommandozeilenargumente, (3) Local (.claude/settings.local.json) — das Projekt- und Benutzereinstellungen überschreibt, (4) Project (.claude/settings.json), (5) User (~/.claude/settings.json). Lokale Einstellungen überschreiben Projekteinstellungen, nicht umgekehrt. Die Managed-Bereitstellung kann Plattform-Policy-Dateien oder Managed-Konfigurationsverzeichnisse verwenden, aber das sind Implementierungsdetails der obersten Managed-Ebene und keine separaten alltäglichen Scopes.
Der native Installer aktualisiert sich standardmäßig im Hintergrund automatisch. Homebrew- und WinGet-Installationen aktualisieren sich standardmäßig nicht automatisch — um dies zu aktivieren, setze CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1. Claude Code führt dann das Upgrade über den Paketmanager im Hintergrund aus, wenn eine neue Version verfügbar ist, und fordert dich bei Erfolg zum Neustart auf. Um stattdessen manuell zu aktualisieren, führe brew upgrade claude-code (oder brew upgrade claude-code@latest) oder winget upgrade Anthropic.ClaudeCodeaus. Du kannst den Release-Kanal mit der Einstellung autoUpdatesChannel steuern — "latest" (Standard) erhält neue Funktionen sofort, während "stable" eine etwa eine Woche alte Version verwendet, die Releases mit größeren Regressionen überspringt. Um Auto-Updates vollständig zu deaktivieren, setze DISABLE_UPDATES zu "1" in deinem Settings- env Block — das blockiert alle Update-Pfade, einschließlich des manuellen claude update. Für eine weniger strikte Option unterdrückt DISABLE_AUTOUPDATER nur die Update-Benachrichtigungen des Paketmanagers.
Über Berechtigungen hinaus gehören zu den nützlichen Einstellungen env für Umgebungsvariablen, die in jeder Session vorhanden sein sollten, agent , um einen benutzerdefinierten Standard-Agent festzulegen, und claudeMdExcludes , um irrelevante Memory-Dateien in Monorepos herauszufiltern. Du kannst außerdem das Standardmodell und das Effort-Level festlegen:
{
"model": "claude-sonnet-4-6",
"env": {
"NODE_ENV": "development",
"LOG_LEVEL": "debug"
}
}Füge .claude/settings.local.json zu deiner .gitignore hinzu, damit persönliche Overrides persönlich bleiben. Teile .claude/settings.json, CLAUDE.md, .claude/rules/, .claude/skills/und optional .claude/agents/ über git mit dem Team. Das gibt Teamkollegen dieselben gemeinsamen Projektanweisungen und projektbezogenen Erweiterungen, während persönliche Einstellungen und das Auto-Memory lokal auf jedem Rechner bleiben.