Claude Code für ein Projekt einrichten

Eine knappe Viertelstunde Einrichtung entscheidet darüber, wie brauchbar Claude Code in einem Projekt ist. Danach kennt es deine Konventionen, darf die Befehle ausführen, die es wirklich braucht, und verhält sich bei allen im Team gleich. Dieses Modul geht die Schritte in der Reihenfolge durch, in der sie sinnvoll sind.

Mit dem Projekt-Memory anfangen

Den Anfang macht /init . Claude sieht sich die Codebase an — Paketmanifest, vorhandene Dokumentation, Verzeichnisschnitt — und legt eine CLAUDE.md an, in der Stack, die wichtigsten Befehle und die erkannten Konventionen stehen. Existiert die Datei schon, schlägt /init Verbesserungen vor, statt sie zu überschreiben. Committe sie danach, damit alle im Team denselben Ausgangspunkt haben.

Kurz und konkret schlägt lang und vollständig. Unter 200 Zeilen je Datei ist der Richtwert; längere Dateien kosten mehr Kontext und werden schlechter befolgt. Jede Zeile sollte in fast jeder Sitzung etwas wert sein — was nur für eine Ecke des Projekts gilt, gehört in eine pfad-gebundene Regel unter .claude/rules/ . Am meisten tragen: Stack samt Versionen, die Befehle für Installieren, Testen, Bauen und Linten, Namenskonventionen, die niemand errät, und die Fallstricke, über die ein neuer Kollege garantiert stolpert.

# 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: camelCase

Berechtigungen setzen

Claude Code fragt standardmäßig nach, bevor es Dateien schreibt oder Shell-Befehle ausführt. Für die tägliche Arbeit gibst du die Operationen vorab frei, die ohnehin ständig vorkommen — der Rest bleibt bei der Rückfrage.

Den Berechtigungsmanager öffnest du mit /permissions ; er zeigt die Regeln nach Ebene und lässt dich Allow-, Ask- und Deny-Regeln anlegen. Muster wie Bash(git *) geben eine ganze Befehlsfamilie frei, Bash(npx jest *) nur ein einzelnes Werkzeug. Dateizugriffe lassen sich genauso auf Pfade eingrenzen.

Wo die Regeln stehen, entscheidet, für wen sie gelten: .claude/settings.json wandert ins Repository und gilt fürs Team, .claude/settings.local.json bleibt per .gitignore bei dir:

{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(npm *)",
      "Bash(npx *)",
      "Read(**/*)",
      "Write(src/**/*)",
      "Edit(src/**/*)"
    ]
  }
}

Was gefährlich werden kann — ein Deploy in die Produktion etwa — lässt du bei der Rückfrage. Skills, die Claude nie von sich aus starten soll, bekommen disable-model-invocation: true ; dann bleiben sie ausschließlich deinem Aufruf vorbehalten.

Braucht eine Aufgabe Dateien ausserhalb des Projekt-Roots — eine Nachbar-Bibliothek, ein gemeinsames Typen-Paket —, erweiterst du die Arbeitsverzeichnisse mit --add-dir beim Start oder /add-dir mitten in der Sitzung. Jeder Pfad muss als Verzeichnis existieren, und die Freigabe umfasst nur den Dateizugriff: die .claude/ -Konfiguration aus dem fremden Baum wird nicht mitgeladen.

# Start a session with read/edit access in two sibling directories
claude --add-dir ../shared-types --add-dir ../design-tokens

Soll die Erweiterung dauerhaft gelten statt nur für eine Sitzung, trägst du die Pfade als permissions.additionalDirectories in .claude/settings.json ein. --add-dir ist genau dieselbe Freigabe, nur befristet.

Sicherheit — Marketplaces einschränken

Womit sich Plugins beziehen lassen, begrenzt blockedMarketplaces . Ein Eintrag sperrt entweder eine Domain über hostPattern oder einen Repository-Pfad über pathPattern :

{
  "blockedMarketplaces": [
    { "hostPattern": "*.untrusted-domain.io" },
    { "pathPattern": "acme/corp-plugins" }
  ]
}

Durchgesetzt wird das auf der Policy-Ebene: lokale Einstellungen können es nicht aushebeln. Für Unternehmens-Rollouts steht es in den Managed Settings, zusammen mit verwandten Schaltern wie strictKnownMarketplaces und disableSideloadFlags .

Wer selbst ein Plugin-Manifest schreibt, deklariert monitors und themes inzwischen unter experimental statt auf oberster Ebene der plugin.json . Die alte Form funktioniert noch, claude plugin validate warnt aber bereits — ein künftiges Release wird die verschachtelte Schreibweise verlangen.

Einstellungen, Ebenen und Updates

Fünf Ebenen, von oben nach unten: Managed steht ganz oben und lässt sich durch nichts überschreiben, auch nicht durch Kommandozeilen-Argumente; darunter kommen die Kommandozeilen-Argumente selbst, dann Local ( .claude/settings.local.json ), dann Project ( .claude/settings.json ) und zuletzt User ( ~/.claude/settings.json ). Die lokale Datei schlägt also die des Projekts, nicht umgekehrt — genau deshalb eignet sie sich für persönliche Ausnahmen.

Wie sich Claude Code aktualisiert, hängt am Installationsweg. Der native Installer zieht im Hintergrund von selbst nach; Installationen über Homebrew oder WinGet tun das erst, wenn du CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE setzt — dann läuft das Upgrade im Hintergrund und du wirst zum Neustart aufgefordert. Welchen Kanal es zieht, bestimmt autoUpdatesChannel : "latest" ist der Standard, "stable" bleibt bewusst etwas zurück. Ganz abschalten lässt es sich mit DISABLE_UPDATES — das blockiert wirklich jeden Weg, auch claude update von Hand; das mildere DISABLE_AUTOUPDATER unterdrückt nur die Hinweise.

Jenseits der Berechtigungen lohnen sich vor allem env für Variablen, die in jeder Sitzung stehen sollen, agent für einen abweichenden Standard-Agenten und claudeMdExcludes , um in einem Monorepo die Memory-Dateien fremder Teams draußen zu lassen. Auch Modell und Denktiefe legst du hier fest:

{
  "model": "claude-sonnet-4-6",
  "env": {
    "NODE_ENV": "development",
    "LOG_LEVEL": "debug"
  }
}

Zum Schluss die Aufteilung: .claude/settings.local.json gehört in die .gitignore , alles Gemeinsame ins Repository — CLAUDE.md , .claude/settings.json , .claude/rules/ , .claude/skills/ und, wenn ihr damit arbeitet, .claude/agents/ . So bekommt jeder dieselben Projektanweisungen, während persönliche Einstellungen und das Auto-Memory auf dem jeweiligen Rechner bleiben.