Der Nighthog erklärt den Einstieg: Installation, das Berechtigungsmodell, was Claude Code im Dateisystem darf, wie CLAUDE.md das Projektgedächtnis bildet — und wo die Grenzen liegen, die ein IT-Verantwortlicher kennen sollte.

Claude Code für Admins — der Einstieg

Nach meiner ersten Testnacht mit Claude Code haben mich Kollegen gefragt: „Wie fängt man an? Was darf das Ding eigentlich anfassen?”

Das sind die richtigen Fragen. Wer ein Werkzeug in den Serverraum lässt, sollte wissen, wo es hinlangt. Diese Notiz ist die Antwort, die ich mir am Anfang selbst gewünscht hätte.

Installation und erster Start

Claude Code ist ein Node-Paket. Voraussetzung ist ein aktuelles Node (≥ 22):

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

Im Projektverzeichnis starten:

cd ~/projekte/kundenwebsite
claude

Beim ersten Start verlangt das Werkzeug einen Login — entweder per claude.ai-Account oder per API-Key. Ich nehme im Werkstatt-Alltag den Account-Login: weniger Schlüsselverwaltung, automatische Abrechnung, und der Status ist im Browser sichtbar.

Damit steht der Igel am Terminal und wartet auf Anweisungen.

Wo Claude Code wohnt — und wo nicht

Drei Orte, die man kennen sollte:

~/.claude/                 # globale Konfiguration und Skills für alle Projekte
~/.claude/CLAUDE.md        # globales Gedächtnis (Vorlieben, Konventionen)

./.claude/                 # projektspezifische Konfiguration im Repo-Wurzel
./.claude/settings.json    # geteilte Projekt-Einstellungen (committen)
./.claude/settings.local.json  # persönliche Overrides (gitignoren)

./CLAUDE.md                # Projekt-Gedächtnis im Repo (immer mitlesen)

Wichtig: Claude Code arbeitet im aktuellen Projektverzeichnis. Alles unterhalb von pwd ist potentiell sichtbar; alles darüber bleibt ihm verborgen, solange er nicht ausdrücklich dorthin geschickt wird. Wer also claude in ~ startet, hat eine andere Reichweite als wer claude in einem konkreten Projektordner startet. Letzteres ist die richtige Variante.

Was Claude lesen darf

Innerhalb des Projektbaums liest Claude Dateien ohne Rückfrage — das Read-Tool ist die langweilige Selbstverständlichkeit, ohne die kein Pair-Programmer funktioniert. Was er sieht:

Quellcode, Konfigurationsdateien, Markdown, Daten-Files im Projekt
git-Status und git-History (über git-Befehle)
Was du in den Chat tippst oder per Drag-and-Drop reinwirfst

Was er nicht sieht:

Dateien außerhalb des Projektordners — ~/.ssh/, /etc/, Nachbarprojekte
System-Logs, sofern nicht ausdrücklich geöffnet
Andere Sessions oder andere Anwender
Inhalte von HTTP-/SSH-Verbindungen, die du nicht selbst initiierst

Die Faustregel: Claude liest, was du auch liest, wenn du im Projektordner ls und cat aufrufst. Nicht mehr, nicht weniger.

Was Claude ausführen darf

Hier wird es interessant — und hier sitzt das Sicherheitsmodell.

Jede Bash-Ausführung wird per Default abgefragt. Der Igel sieht: „Soll ich npm run build ausführen? [j/n/a]” Drei Buchstaben:

j — nur dieses eine Mal
n — abgelehnt
a — diesen Befehl in Zukunft erlauben (in settings.local.json gespeichert)

Dasselbe gilt für Edit (Datei ändern) und Write (neue Datei schreiben). Beim ersten Start ist alles auf fragen gestellt — nichts geht ohne explizites Ja.

Wer das auf Dauer mühsam findet, hinterlegt eine Allowlist. Eine vernünftige Konfiguration für ein Webprojekt sieht etwa so aus:

// .claude/settings.local.json
{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(npm run build)",
      "Bash(npm run lint)",
      "Bash(ls:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(curl:*)"
    ]
  }
}

Die Logik: lesende und harmlose Operationen pauschal freigeben, alles potentiell Destruktive bleibt auf fragen stehen — oder steht explizit auf deny. Das :* am Ende ist ein Wildcard-Suffix für Argumente.

CLAUDE.md — das Projektgedächtnis

Eine Datei CLAUDE.md im Projekt-Wurzelverzeichnis wird bei jedem Start automatisch gelesen. Hier landet alles, was Claude über das Projekt wissen muss, ohne dass man es jedes Mal neu erklärt:

# Projekt-Leitfaden

## Tech-Stack
- Astro 6, Tailwind 4, TypeScript 5
- Node ≥ 22

## Konventionen
- Sprache: Deutsch (UI und Code-Kommentare)
- Bilder als .webp, Preload für Hero-Images
- Kein Cookie-Banner — wir setzen keine

## Was nicht zu ändern ist
- Layout.astro hat globale Schema.org-Daten
- /danke wird aus der Sitemap gefiltert

CLAUDE.md bootstrappen kann man auch direkt im Werkzeug:

> /init

Das lässt Claude die Codebasis durchsehen und einen ersten Entwurf schreiben, den man danach von Hand schärft.

Slash-Commands, die im Alltag zählen

Im Chat-Prompt funktionieren Befehle, die mit / beginnen. Die wichtigsten:

/init      # CLAUDE.md aus dem aktuellen Repo generieren
/help      # Hilfe-Übersicht
/clear     # Konversations-Kontext leeren (wenn Claude sich verirrt)
/config    # Theme, Modell, Notification-Einstellungen
/cost      # Token-Verbrauch der aktuellen Session
/login     # Account oder API-Key wechseln

Es gibt mehr, aber das ist die Hand voll, die man wirklich braucht.

Was Claude bewusst nicht tut

Damit klar ist, was nicht passiert:

Keine heimlichen Netzwerk-Anrufe. Wenn Claude eine URL fetcht oder googelt, sieht man das im Verlauf. Kein stiller Datenabfluss.
Kein Training auf deinem Code. API-Calls aus Claude Code werden gemäß Anthropics Enterprise-Defaults nicht zum Training genutzt. Wer das schwarz auf weiß braucht, findet die Geschäftsbedingungen verlinkt.
Kein Lesen von Secrets, die nicht im Projekt liegen. Wenn aber .env mit API-Keys im Repo steht, sieht Claude sie. Das ist kein Tool-Problem, das ist ein generelles Hygiene-Thema. Ergänzt euer .gitignore, bevor ihr Claude einsetzt.
Keine destruktive Aktion ohne Freigabe (sofern nicht versehentlich in der Allowlist).

Wo ich es einsetze, wo nicht

Ja, ich nutze Claude Code mittlerweile regelmäßig. Aber nicht für alles:

Wofür Claude Code in meiner Werkstatt taugt:

Wiederkehrendes Boilerplate (Bash-Skripte, Astro-Komponenten nach Vorlage)
Dokumentation einer fremden Codebasis lesbar machen
Refactoring mit klarem Zielbild
Erkundung: „zeig mir, wo in diesem Repo die API-Endpunkte liegen”
Fehlerlogs entziffern
Pair-Programming für Code, den ich danach selbst verstehe

Wofür ich es nicht einsetze:

Kritische Production-Deployments ohne menschlichen Review
Domain-Logik, die spezifisches Kundenwissen voraussetzt — der Igel weiß nicht, welcher Server beim Kunden besonders sensibel ist
Code, den ich am Ende nicht selbst lesen und verteidigen kann

Die goldene Regel: Ich bleibe verantwortlich. Claude Code ist ein Werkzeug, kein Mitarbeiter. Wenn etwas im Produktiv-System schiefgeht, sitze ich am Terminal — nicht der Igel, nicht Anthropic.

Was übrig bleibt

Wer einsteigen will, braucht keine Schulung — npm install, claude, ein paar Stunden ehrlicher Arbeit. Wer es seriös einsetzt, sollte:

Eine klare CLAUDE.md im Repo pflegen
settings.local.json mit einer maßvollen Allowlist anlegen
Sensitive Dateien (.env, Secrets, private Keys) niemals im Projekt vergessen
Anfangs immer alles abfragen lassen — die Allowlist wächst mit der Erfahrung

Mehr braucht es nicht. Nicht für den Anfang, nicht für den Alltag.

Und falls jemand fragt, warum der alte Igel seinen Pair-Programmer auf einem Werkzeugkasten-Eintrag hat: weil er nach drei Monaten ehrlicher Arbeit nicht mehr aus der Werkstatt rausgeht.

Claude Code für Admins — wie man anfängt und was es anfasst