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

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, Status im Browser sichtbar.

Damit steht der Igel am Terminal und wartet auf Anweisungen.

Wo Claude Code wohnt

Es gibt eine Handvoll Orte, an denen Claude Code lebt. Manche global im Homeverzeichnis, manche projektbezogen im Repo:

~/.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 ist das Arbeitsverzeichnis. Claude Code arbeitet in pwd. Alles unterhalb ist potentiell sichtbar, alles darüber bleibt ihm verborgen, solange er nicht ausdrücklich dorthin geschickt wird. Wer claude in ~ startet, hat eine andere Reichweite als wer im 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. Quellcode, Konfigurationsdateien, Markdown, Daten-Files, git status und git log über die entsprechenden Kommandos, dazu alles, was man selbst in den Chat tippt oder per Drag-and-Drop reinwirft.

Außerhalb des Projektordners ist Schluss. ~/.ssh/ bleibt unsichtbar. /etc/ ebenso. Nachbarprojekte sind tabu, solange man Claude nicht explizit dort hinschickt. System-Logs liest er nur, wenn man sie ihm öffnet. Andere Sessions oder andere Anwender sind außer Reichweite. HTTP- oder SSH-Verbindungen sieht er nur, wenn er sie selbst initiiert.

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 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 für einmalig, n für abgelehnt, a um diesen Befehl in Zukunft zu erlauben (gespeichert in settings.local.json).

Dasselbe gilt für Edit und für Write. 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 dahinter ist alt wie Unix. 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. Die Handarbeit hinterher ist der wichtigere Teil.

Slash-Commands

Im Chat-Prompt funktionieren Befehle, die mit / beginnen. Die Hand voll, die man wirklich braucht:

/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. Das hier reicht für den Alltag.

Was Claude bewusst nicht tut

Damit klar ist, was nicht passiert.

Es gibt keine heimlichen Netzwerk-Anrufe. Wenn Claude eine URL fetcht oder googelt, sieht man das im Verlauf. Kein stiller Datenabfluss.

Es gibt kein Training auf dem eigenen 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.

Es gibt kein Lesen von Secrets, die nicht im Projekt liegen. Wenn allerdings .env mit API-Keys im Repo steht, sieht Claude sie. Das ist kein Tool-Problem, das ist Hygiene. Ergänzt euer .gitignore, bevor ihr Claude einsetzt.

Und es gibt keine destruktive Aktion ohne Freigabe. Sofern man sie nicht versehentlich selbst in die Allowlist geschrieben hat.

Wo ich es einsetze, wo nicht

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

Brauchbar finde ich es für wiederkehrendes Boilerplate. Bash-Skripte, Astro-Komponenten nach Vorlage, der Kleinkram, den ich zwar kann, aber nicht jedes Mal neu tippen will. Brauchbar ist es auch beim Lesbar-Machen fremder Codebasen, beim Refactoring mit klarem Zielbild, beim Entziffern kryptischer Fehlerlogs. Und bei der Erkundung: „zeig mir, wo in diesem Repo die API-Endpunkte liegen” — da spart er mir die halbe Stunde mit grep -r. Pair-Programming für Code, den ich danach selbst verstehe, geht damit ganz gut.

Was ich ihm nicht überlasse, sind die Stellen, an denen Verantwortung sitzt. 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 könnte.

Die goldene Regel ist die alte: 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, pflegt eine klare CLAUDE.md im Repo. Legt eine settings.local.json mit einer maßvollen Allowlist an. Vergisst sensitive Dateien wie .env, Secrets oder private Keys niemals im Projekt. Und lässt anfangs alles abfragen. Die Allowlist wächst mit der Erfahrung, nicht andersherum.

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.

— der Nighthog, zweite Nacht, gleicher Kaffee

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