Rechner und Netz pflegen

Claude Code ist für Code gebaut. Laut der Doku zur Funktionsweise (externe Seite, code.claude.com) hilft es aber bei allem, was sich auf der Kommandozeile erledigen lässt. Dazu gehört jeder Befehl, den man selbst ausführen könnte: Build-Werkzeuge, Git, Paketverwaltungen, Systemprogramme und Skripte. Damit kann es auch einen Rechner pflegen: Logs lesen, Konfigurationen prüfen, Pakete aktualisieren.

Dieses Kapitel nimmt sich Diagnose, Konfiguration und Wartung im Takt vor, dazu die Frage, wo Rechte die Grenze ziehen. Nach einer Studie des Herstellers wuchs der Anteil des Betriebs von Oktober 2025 bis April 2026 von 14 auf 21 Prozent der interaktiven Sitzungen. Welche Sitzung dazugehört, hat ein Modell eingestuft. Eingeordnet ist die Zahl in Kapitel 07.

Diagnose: erst lesen, dann ändern

Die meiste Pflege beginnt mit einer Fehlermeldung, und der kürzeste Weg führt über die Pipe. Ohne Dialog liest Claude Code die Standardeingabe und gibt die Antwort aus wie jedes andere Kom­man­do­zei­len­pro­gramm (Doku zum Lauf ohne Terminal (externe Seite, code.claude.com)). Die Best Practices (externe Seite, code.claude.com) nennen diesen Weg für eine Fehlerdatei. Etwa so:

tail -200 /var/log/app.log \
  | claude -p 'Welche Fehler stehen
  hier, und was ist die
  wahrscheinlichste Ursache?'

In einer Sitzung nennt man Claude laut der Doku zu Arbeitsabläufen (externe Seite, code.claude.com) den Befehl, der den Fehler auslöst und einen Stack Trace liefert. Dazu gehört die Angabe, ob der Fehler immer oder nur manchmal auftritt.

Wer erst verstehen und noch nichts ändern will, wählt den manuellen Modus. Dort fragt Claude Code vor Schreibzugriffen auf Dateien, vor Shell-Befehlen und vor Werkzeugen von MCP-Servern. Eine feste Liste lesender Befehle wie ls, cat, tail, grep oder du läuft in jedem Modus ohne Rückfrage (Doku zu den Rechten (externe Seite, code.claude.com)).

Eine neue Sitzung im Terminal beginnt allerdings im Auto-Modus, wenn keine Einstellung etwas anderes festlegt, laut Doku zu den Rechtemodi (externe Seite, code.claude.com) ab Version 2.1.283. Auf Pro, Max und Team galt das schon vorher. Die Versionsliste (externe Seite, code.claude.com) führt den Schritt für alle Tarife unter 2.1.284 vom 28.09.2026. Wie man den Modus wechselt, steht in Kapitel 16.

Ein Ausfall bei Anthropic

Einen bezifferten Fall nennt Anthropics Bericht über die eigenen Teams (externe Seite, claude.com) vom 24.07.2025. Als Cluster unter Kubernetes keine Pods mehr einplanten, suchte das Team für Daten­in­fra­struktur die Ursache mit Claude Code. Es gab Claude Bildschirmfotos seiner Dashboards, und Claude führte das Team Menü für Menü durch die Oberfläche von Google Cloud. Dem Cluster waren die IP-Adressen für Pods ausgegangen. Claude nannte die Befehle für einen neuen Adressbereich. Das Team gibt an, so während des Ausfalls 20 Minuten gespart zu haben.

Die Zahl hat das Team selbst genannt, erzählt vom Hersteller über die eigene Firma. Lehrreich ist die Arbeitsteilung: Claude las, ordnete ein und schlug Befehle vor. Die Menschen klickten und entschieden.

Konfiguration: Dateien, Pakete, Netz

Dateien. Startet man Claude Code direkt in ~, fragt es bei jedem Start erneut nach dem Vertrauen (Doku zur Sicherheit (externe Seite, code.claude.com)). Die Doku rät zu einem Unterordner als Projekt. Für Kon­fi­gu­ra­ti­ons­da­teien passt deshalb ein eigener Ordner unter Git. Startdateien der Shell wie .bashrc oder .zshrc sind geschützt: Im manuellen Modus fragt Claude Code vor jedem Schreiben dort, im Auto-Modus entscheidet der Klassifikator (Doku zu den Rechtemodi (externe Seite, code.claude.com)).

Pakete und Netz. Im Auto-Modus entscheidet ein Klassifikator über Befehle, die keine Regel freigibt. Abhängigkeiten aus Lockfile oder Manifest lässt er installieren. Code herunterladen und gleich ausführen, etwa mit curl | bash, sperrt er ab Werk. Ebenso sperrt er eine Installation, die an einem internen Paketspiegel vorbei aus einer öffentlichen Quelle holt, sofern Claude von dem Spiegel weiß. Gesperrt sind auch Änderungen an Einträgen im DNS und an TLS-Zertifikaten sowie ein Tunnel, der einen lokalen Dienst aus dem Internet erreichbar macht.

Sandbox. In der Sandbox für Bash scheitern gerade die Werkzeuge der Netzpflege: ssh, die meisten Datenbank-Clients und Werkzeuge mit UDP (Sandbox-Doku (externe Seite, code.claude.com)). Docker läuft dort gar nicht. Wie man solche Befehle herausnimmt, zeigt die zweite Ebene.

Der Rückweg. Eine Datei, die nur ein Shell-Befehl geändert hat, hält Claude Code in keinem Checkpoint fest (Doku zu Checkpoints (externe Seite, code.claude.com)). Den Rückweg sichert man also vorher selbst, mit Git oder einer Kopie.

Wo die Wartung läuft

Wartung im Takt muss den Rechner erreichen, den sie pflegt. Für unbeaufsichtigte Läufe nennt die Doku zu geplanten Aufgaben (externe Seite, code.claude.com) drei Wege: Routines in der Cloud, GitHub Actions und geplante Aufgaben der Desktop-App. Dazu kommt /loop in einer offenen Sitzung. Den vierten Weg leitet dieses Kapitel ab: ein Skript mit claude -p, das der Zeitplaner des Systems startet, etwa cron. Die Doku beschreibt den Lauf ohne Terminal für Skripte und CI/CD.

/loop feuert nur, solange Claude Code läuft und gerade nichts zu tun hat. Eine wiederkehrende Aufgabe endet sieben Tage nach dem Anlegen. Die geplante Aufgabe der Desktop-App greift direkt auf Dateien und Werkzeuge zu, aber nur bei offener App und wachem Rechner (Doku zur Desktop-App (externe Seite, code.claude.com)).

Eine Routine läuft auf Infrastruktur von Anthropic, auch bei zugeklapptem Laptop (Doku zu Routines (externe Seite, code.claude.com)). Es gibt sie in Pro, Max, Team und Enterprise, als Research Preview. Jeder Lauf beginnt mit einem frischen Klon. Selbst betriebene Umgebungen gibt es in Team und Enterprise als öffentliche Beta, ab Werk ausgeschaltet (Doku zu selbst betriebenen Umgebungen (externe Seite, code.claude.com)). Ihre Sitzungen erreichen interne Dienste aus dem eigenen Netz heraus. Wie man die Wege einrichtet, zeigt Kapitel 28, GitHub Actions und Skripte Kapitel 29.

Wo Rechte die Grenze ziehen

Claude Code arbeitet mit den Rechten seines Nutzers. Ein Shell-Befehl, den man freigibt, kann überall schreiben, wo das eigene Konto schreiben darf (Doku zur Sicherheit (externe Seite, code.claude.com)). Für sudo gelten zwei Regeln. Mit --dangerously-skip-permissions startet Claude Code unter Linux und macOS nicht als root und nicht unter sudo, außer in einer erkannten Sandbox (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Und seit Version 2.1.113 vom 17.04.2026 greift ein Verbot für Bash auch hinter sudo (Versionsliste (externe Seite, code.claude.com)). Eine Regel Bash(rm *) unter deny sperrt also auch sudo rm.

Beim Löschen gibt es eine feste Sicherung. Das Wurzelverzeichnis, das Home-Verzeichnis und das Arbeits­ver­zeichnis gehören zu den kritischen Pfaden (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Erkennt Claude Code das Ziel eines rm als kritischen Pfad, gibt weder eine Erlaubnis noch ein Hook den Befehl frei, auch in Modi, die sonst nicht fragen. Einen Befehl, den diese Prüfung übersieht, behandelt Claude Code wie jeden anderen. Im Auto-Modus ohne Terminal, etwa mit -p, lehnt Claude Code ihn ab Version 2.1.281 sofort ab. Claude soll dann melden, was es löschen wollte, und das Löschen dem Menschen überlassen.

Eine Regel prüft dabei nur den Text eines Befehls und zieht laut Doku zu den Rechten (externe Seite, code.claude.com) keine Sicherheitsgrenze um das Programm. Wie Regeln, Modus, Klassifikator und Sandbox zusammenspielen, zeigt Kapitel 16, einen festen Riegel per Hook Kapitel 18.

Für Einstellungen, die es nur in einer grafischen Oberfläche gibt, bietet die Kommandozeile Computer Use, als Research Preview für macOS mit Pro oder Max (Doku zu Computer Use (externe Seite, code.claude.com), mehr in Kapitel 04). Es braucht eine interaktive Sitzung und fehlt deshalb in jedem Wartungslauf mit -p.

Eine Bauform für Wartung im Takt

Daraus ergibt sich eine Bauform mit vier Teilen:

• Ein Lauf ohne Dialog: claude -p mit genau der Aufgabe, die ansteht.
• Ein fester Takt: ein Zeitplaner auf dem Rechner, der gepflegt wird.
• Enge Rechte: Erlaubt ist nur, was die Aufgabe braucht. Im Modus dontAsk lehnt Claude Code jeden Aufruf ab, der sonst eine Rückfrage auslösen würde. Einen Teil davon kann ein installierter Mod trotzdem freigeben.
• Eine Meldung nur bei Befund: Das Skript wertet Ausgabe und Rückgabewert aus.

Ihre Schwäche liegt im vierten Teil: Ein Lauf, der still ausfällt, sieht aus wie ein Lauf ohne Befund. Was daraus folgt, steht auf der dritten Ebene.

Wann sich das lohnt

• Eine unverstandene Fehlermeldung: Claude liest Log, Stack Trace und Dokumentation zusammen und schlägt eine Ursache vor. Ausführen entscheidet der Mensch.
• Ein Takt am eigenen Rechner: die Desktop-App oder ein Skript mit claude -p.
• Ein Takt an Repository oder Dienst im Netz: eine Routine.

Ein Schritt, der jedes Mal gleich abläuft, gehört in ein gewöhnliches Skript. Es ist billiger und liefert jedes Mal dasselbe. Claude Code lohnt sich, wo ein Befund gelesen und eingeordnet werden muss.

Hier geht es um das Vorgehen: Prompts für die Diagnose, Regeln für Wartungsarbeit, die Sandbox im Betrieb und ein Skript für den Zeitplaner des Systems. Die Mechanik dahinter erklären die Kapitel, auf die jeder Abschnitt verweist.

Ein Log über die Pipe

Was über die Pipe hereinkommt, darf höchstens 10 MB groß sein (Doku zum Lauf ohne Terminal (externe Seite, code.claude.com)). Man schneidet deshalb vorher zu, mit tail, grep oder einem Zeitfenster. Das spart auch Kontext. Ein Prompt für die Diagnose fragt nach der wahr­schein­lichsten Ursache, dem Beleg im Log und einem nächsten Schritt, der nur liest.

grep -i error /var/log/app.log \
  | tail -100 \
  | claude -p 'Nenne die wahrscheinlichste
  Ursache, die Zeilen, die dafür
  sprechen, und einen Befehl, der
  nur liest und sie bestätigt.'

Ein Log enthält oft Text von außen, etwa Anfragen an einen Webserver mit frei gewählten Feldern. Die Doku zur Sicherheit (externe Seite, code.claude.com) rät davon ab, nicht vertrauenswürdige Inhalte direkt an Claude zu leiten. Für einen Lauf über die Pipe heißt das: keine Werkzeuge, die etwas verändern, und ein Mensch, der die vorgeschlagenen Befehle liest. Warum Eingaben von außen als Daten gelten, steht in Kapitel 28 auf der dritten Ebene.

Vom Alarm in die Sitzung

Ein Deep Link ist eine Adresse der Form claude-cli://, die Claude Code in einem neuen Terminalfenster öffnet, auf Wunsch mit Arbeits­ver­zeichnis und vorbereitetem Prompt (Doku zu Deep Links (externe Seite, code.claude.com)). Als Orte nennt die Doku unter anderem einen Schritt im Handbuch für Störungen, der das Repository des betroffenen Dienstes mit einem Prompt zur Diagnose öffnet, und einen Alarm der Überwachung.

Ein Deep Link führt selbst nichts aus. Der Prompt geht erst mit Enter an das Modell. Die Sitzung öffnet sich immer auf dem Rechner, auf dem jemand klickt. Regeln, CLAUDE.md und die Frage nach dem Vertrauen gelten dort wie in jeder anderen Sitzung. Die Desktop-App hat eine eigene Form, claude://code/new, die auch eine SSH-Verbindung und einen Ordner auf dem Server nennen kann. Die Doku schlägt solche Links für Handbücher, Dashboards und Wikis vor (Doku zur Desktop-App (externe Seite, code.claude.com)). SSH-Links setzen die Desktop-App ab Version 2.110.0 voraus.

Auf einem Server arbeiten

Die Desktop-App kann Claude Code per SSH auf einem Server starten und bleibt selbst die Oberfläche. Claude Code läuft dann auf dem Server, und seine Anfragen ins Netz gehen von dort aus. Die Einrichtung steht in Kapitel 30. Im Terminal meldet man sich per ssh an und startet dort claude. In beiden Fällen arbeitet Claude mit den Rechten des Kontos, mit dem man sich anmeldet. Ein eigenes Konto mit wenigen Rechten ist deshalb die einfachste Grenze auf einem Server.

Regeln für Wartungsarbeit

Für Wartung lohnen sich drei Listen: lesende Befehle frei, verändernde mit Rückfrage, zerstörende verboten. Ein Beispiel für einen Rechner, auf dem Dienste mit Docker Compose laufen:

{
  "permissions": {
    "allow": [
      "Bash(df *)",
      "Bash(docker logs *)"
    ],
    "ask": [
      "Bash(docker compose pull *)",
      "Bash(docker compose restart *)"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(docker system prune *)"
    ]
  }
}

Ein Stern am Ende mit Leerzeichen davor deckt auch den Befehl ohne Argumente ab, Bash(df *) erlaubt also df und df -h (Doku zu den Rechten (externe Seite, code.claude.com)). Der Stern steht für jeden Text an seiner Stelle. Ein Befehl, der mit einer zusätzlichen Option auch löschen oder schreiben kann, gehört deshalb unter ask. Verkettete Befehle prüft Claude Code einzeln. Eine Erlaubnis muss auf jeden Teil passen, ein Verbot greift schon bei einem.

Eine Umleitung mit > prüft Claude Code gegen die Regeln für Dateien, als schriebe es die Datei selbst. Ab Version 2.1.269 gilt das auch für die Dateien, in die tee schreibt. Im Auto-Modus bleiben Verbote und Rückfrageregeln wirksam (Doku zur Sicherheit (externe Seite, code.claude.com)). Ein Neustart unter ask hält also auch dort an. Wie Muster in Bash-Regeln greifen, zeigt Kapitel 16.

Die Sandbox im Betrieb

Die Sandbox für Bash grenzt Dateien und Netz auf Ebene des Betriebssystems ein. Jede Verbindung geht über einen Proxy, der den Host gegen eine Liste erlaubter Domains prüft, und diese Liste ist zu Beginn leer (Sandbox-Doku (externe Seite, code.claude.com)). Ein Werkzeug, das seine eigene Verbindung aufbaut, scheitert deshalb. Für Wartung trifft das die üblichen Werkzeuge:

• ssh, scp und rsync über SSH erreichen ihr Ziel nicht.
• Git über SSH scheitert unter macOS auch bei erlaubtem Host.
• Die meisten Datenbank-Clients und Werkzeuge mit UDP kommen nicht hinaus.
• Dienste auf dem eigenen Rechner, etwa eine Datenbank in einem Container, erreicht ein Befehl ab Werk nicht direkt.
• Docker verträgt sich gar nicht mit der Sandbox.

Der Ausweg heißt excludedCommands. Ein Befehl, der dort passt, läuft außerhalb der Sandbox, mit dem vollen Zugang des Nutzers. Die Doku beschränkt das auf Werkzeuge, denen man diesen Zugang zutraut. Ihr Beispiel nimmt docker compose heraus:

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["docker compose *"]
  }
}

Für einen so herausgenommenen Befehl gelten Regeln und Rechtemodus wie für jeden anderen. Wer stattdessen den Zugriff auf /var/run/docker.sock in der Sandbox erlaubt, gibt Zugang zum ganzen Rechner. Was die Sandbox sonst begrenzt, steht in Vibe-Coding / Agentic Engineering, Kapitel 09.

Aufräumen ohne Schaden

Beim Aufräumen sind neben Wurzel, Home- und Arbeits­ver­zeichnis alle Ordner direkt unter der Wurzel kritisch, etwa /usr oder /etc (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Dazu zählen Formen, die erst beim Ausführen ein Ziel bekommen. Ein rm -rf "$DIR"/* wird zum Löschen ab der Wurzel, wenn die Variable leer ist. Die Doku rät, jede solche Variable so abzusichern, dass die Shell bei leerem Wert mit einem Fehler abbricht, etwa mit ${DIR:?}. Eine Variable, die derselbe Befehl aus $(pwd) oder $(git rev-parse --show-toplevel) füllt, zählt ebenfalls als kritisch, weil sie das Arbeits­ver­zeichnis oder die Wurzel des Repositorys nennen kann. Die Absicherung bringt einen solchen Befehl nicht durch die Prüfung, denn die Variable ist ja gefüllt. Die Doku rät dort zu einem ausgeschriebenen Pfad.

Im Auto-Modus und in bypassPermissions zeigt das Terminal für ein solches Löschen eine Rückfrage mit zwei Minuten Countdown. Läuft er ab, lehnt Claude Code den Befehl ab, und die Sitzung arbeitet weiter. Der Klassifikator sperrt außerdem zwei Formen, die beim Aufräumen naheliegen: das endgültige Löschen von Dateien, die es schon vor der Sitzung gab, und das Löschen in /tmp oder einem Cache über Muster oder Alter statt über einen benannten Pfad. Ein Prompt, der zuerst eine Liste verlangt, passt zu diesen Regeln:

Finde in ~/Library/Caches die zehn größten
Ordner. Zeige Pfad und Größe und lösche
nichts. Ich entscheide danach je Ordner.

Wartung als geplante Aufgabe der Desktop-App

Jede geplante Aufgabe der Desktop-App hat einen eigenen Rechtemodus (Doku zur Desktop-App (externe Seite, code.claude.com)). Die Erlaubnisse aus ~/.claude/settings.json gelten dort ebenfalls, die Regeln von oben wirken also auch im Takt. Im manuellen Modus hält ein Lauf an jeder offenen Rückfrage an, bis jemand antwortet. Verschläft der Rechner den Termin, fällt der Lauf zu dieser Zeit aus. Beim Aufwachen holt die App den jüngsten versäumten Lauf nach, ein Lauf für 9 Uhr kann so erst um 23 Uhr kommen. Wo es auf die Zeit ankommt, gehört eine Bedingung in den Prompt selbst.

Prüfe mit brew outdated, welche Pakete
veraltet sind. Aktualisiere nichts. Gib
eine Liste mit alter und neuer Fassung
aus. Ist nichts veraltet, antworte nur
mit OK.

brew outdated steht nicht in der Liste lesender Befehle, die die Doku nennt. Damit der Lauf nicht anhält, gehört Bash(brew outdated *) unter allow. Wie man eine Aufgabe anlegt, zeigt Kapitel 28.

Ein Skript für den Zeitplaner des Systems

Wer unabhängig von der Desktop-App bleiben will, startet claude -p aus dem Zeitplaner des Systems. Das Skript setzt die Bauform der ersten Ebene um: enge Rechte, eine feste Form für den Befund und eine Meldung bei Ausfall.

#!/bin/sh
ergebnis=$(claude -p 'Prüfe mit df den
  freien Platz. Ist eine Platte über
  90 Prozent voll, beginne mit BEFUND.' \
  --permission-mode dontAsk \
  --allowedTools 'Bash(df *)') \
  || { echo "Lauf gescheitert"; exit 1; }
case "$ergebnis" in
  BEFUND*) echo "$ergebnis" ;;
esac

dontAsk lehnt jeden Aufruf ab, der sonst eine Rückfrage auslösen würde (Doku zum Lauf ohne Terminal (externe Seite, code.claude.com)). Einen Teil davon kann ein installierter Mod trotzdem freigeben. Laufen dürfen damit df und, was ohnehin keine Freigabe braucht, etwa das Lesen im Arbeits­ver­zeichnis und die eingebauten lesenden Befehle. Scheitert der Lauf, endet er mit einem Rückgabewert ungleich null. Dann meldet das Skript den Ausfall, ohne Befund bleibt es still. Welche Anmeldung ein Lauf ohne Browser braucht, steht in Kapitel 29.

Routines für Alarme und Deploys

Die Doku zu Routines (externe Seite, code.claude.com) beschreibt zwei Fälle aus dem Betrieb. Im ersten ruft die Überwachung die Routine auf, sobald eine Fehlerschwelle überschritten ist, und gibt den Text des Alarms mit. Claude holt den Stack Trace, gleicht ihn mit den letzten Commits ab und öffnet einen Entwurf für einen Pull Request mit einer Korrektur. Wer Bereitschaft hat, prüft dann zuerst diesen Pull Request.

Im zweiten ruft die Pipeline sie nach jedem Deploy in Produktion auf. Die Routine prüft die neue Fassung, sucht in den Logs nach Rückschritten und meldet vor Ende des Zeitfensters ein Ja oder Nein in den Kanal für Releases.

Was eine Routine im Netz erreicht, legt ihre Cloud-Umgebung fest. Die Vorgabe lässt nur eine Liste üblicher Ziele zu. Den mitgegebenen Text des Alarms bekommt Claude als nicht vertrauenswürdige Daten gekennzeichnet. Der gespeicherte Prompt muss deshalb ausdrücklich sagen, dass Claude ihn auswerten soll. Da eine Routine im Auto-Modus meist ohne Rückfrage arbeitet, gehört in sie nur der Zugang, den der Fall braucht. Wie man Auslöser und Connectors einrichtet, steht in Kapitel 28.

Fast alle Belege dieses Kapitels stammen aus der Doku des Herstellers, dazu kommen ein Bericht und eine Studie von Anthropic über die eigene Arbeit und ein Werkstattbericht dieser Seite. Diese Ebene ordnet die Zahlen ein und zeigt, wo Schutzmechanismen und Wartung einander im Weg stehen.

Was der Fall aus dem Teams-Bericht hergibt

Den Bericht über die eigenen Teams (externe Seite, claude.com) hat Anthropic aus Gesprächen mit Beschäftigten zusammengestellt. Die 20 Minuten aus dem Fall mit Kubernetes sind eine Angabe des Teams. Wie lange die Suche ohne Claude gedauert hätte, steht nicht im Bericht. Er fasst allgemein zusammen, Claude Code beschleunige in vielen Teams Diagnose und Behebung, weil es Stack Traces, Dokumentation und das Verhalten des Systems auswertet. Eine Zählung dazu enthält er nicht. Seine zweite Zahl zur Fehlersuche ordnet Kapitel 08 auf der dritten Ebene ein.

Der Bericht erschien am 24.07.2025. Einen Browser bedient Claude Code erst seit Dezember 2025, den Bildschirm seit März 2026, siehe Kapitel 04. Das Team gab Claude Bildschirmfotos, und die Menschen klickten selbst. Wer die genannten Befehle ausgeführt hat, sagt der Bericht nicht ausdrücklich. Diese Arbeitsteilung ist heute noch die vorsichtigste Form: Claude liest und schlägt vor, der Mensch handelt im System.

Was die Studie unter Betrieb versteht

Die Studie zu Claude Code (externe Seite, anthropic.com) wertet interaktive Sitzungen von rund 235.000 Menschen aus, erhoben von Oktober 2025 bis April 2026. Jede Sitzung ordnet ein Modell anhand ihres Verlaufs einer Art von Arbeit zu. Läufe ohne Dialog schließt die Studie aus, obwohl sie nach eigener Angabe einen erheblichen Teil der Nutzung ausmachen. Ein Wartungslauf mit claude -p steckt also in keiner ihrer Zahlen.

Zum Betrieb zählt sie Ausliefern, Konfigurieren, Abläufe starten und Systeme überwachen. Die Pflege des eigenen Rechners weist sie nicht gesondert aus. Der Anteil von 21 Prozent im April 2026 zählt, wie oft Betrieb vorkam. Wie gut er gelang, steht in dieser Zahl nicht.

Die Studie schätzt außerdem, was eine Sitzung als Auftrag für Freiberufler kosten würde. Danach wurden Aufgaben im Betrieb von Oktober 2025 bis April 2026 um etwa 34 Prozent wertvoller, Neues bauen um 43 und Reparieren um 32 Prozent. Anthropic nennt diese Schätzungen selbst grob und die Befunde insgesamt vorläufig. Was die Studie über Sachkenntnis und Erfolg sagt, steht in Kapitel 07.

Was die Doku zu sudo und root sagt

In den Seiten zu Rechten, Rechtemodi, Sandbox, Sicherheit, Fehlersuche und Fehlermeldungen kommt sudo vor allem in Befehlen zur Installation vor. Zum Verhalten von Claude Code steht dort eine Regel: Mit --dangerously-skip-permissions startet es unter Linux und macOS nicht als root und nicht unter sudo, außer in einer erkannten Sandbox (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Dazu kommt ein Eintrag der Versionsliste (externe Seite, code.claude.com): Verbote greifen seit Version 2.1.113 auch hinter sudo. Wie Claude Code mit der Passwortabfrage von sudo umgeht, beschreibt keine dieser Seiten.

Daraus folgt eine einfache Regel für die Praxis. Was Systemrechte braucht, führt der Mensch selbst aus, oder es läuft unter einem Konto mit eng gefassten Rechten.

Für Läufe ohne Rückfrage verweist die Doku auf abgeschottete Umgebungen. Den Modus bypassPermissions empfiehlt sie nur in Containern, virtuellen Maschinen oder Dev-Containern ohne Zugang zum Internet. Gegen Prompt Injection und ungewollte Aktionen schützt er nicht. Im Dev-Container läuft Claude Code als Nutzer ohne root. Für Wartung ergibt das einen Widerspruch. Sie findet am echten System statt, an seinen Paketen, Diensten und Einstellungen, und die empfohlene Abschottung nimmt genau diesen Zugang weg. Ein Wartungslauf ohne Rückfrage braucht deshalb enge Regeln, die genau seine Befehle erlauben.

Sandbox und Wartung im Widerspruch

Dieselbe Spannung zeigt die Sandbox. Wartung braucht ssh, Docker und Kon­fi­gu­ra­ti­ons­da­teien. Wer diese Befehle mit excludedCommands herausnimmt, gibt ihnen den vollen eigenen Zugang zurück. Laut Doku senkt die Sandbox das Risiko, ihre Isolation ist aber unvollständig (Sandbox-Doku (externe Seite, code.claude.com)). Bei Wartung bleibt von ihr oft nur ein Teil übrig.

Was dann noch schützt, sind Regeln, Klassifikator und Rückfrage. Eine Regel vergleicht den Text eines Befehls. Laut der Doku zu den Rechten (externe Seite, code.claude.com) stoppt Bash(rm *) unter deny die Schreibweise rm -rf build/. Über /bin/rm oder in bash -c geschrieben läuft derselbe Befehl durch. Die Prüfung der kritischen Pfade sieht auch in verschachtelte Befehle und in Skripte, die eine Shell mit -c bekommt (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Ein bash -c 'rm -rf ~' fängt sie also ab.

Den Klassifikator im Auto-Modus beschreibt die Doku als Mittel gegen Rückfragen, das Sicherheit nicht garantiert. Was er laut Messungen übersieht, steht in Vibe-Coding / Agentic Engineering, Kapitel 08. Für Wartung bleibt damit der manuelle Modus die verlässlichste Grenze. Dort braucht jeder Befehl, auf den keine Regel passt, eine Freigabe (Doku zur Sicherheit (externe Seite, code.claude.com)). Auch eine andere Schreibweise desselben Befehls landet so beim Menschen. Ohne Menschen lehnt dontAsk ab, was sonst eine Rückfrage auslösen würde. Einen Teil davon kann ein installierter Mod trotzdem freigeben.

Zwei Arten von Pflege

Ruft man /loop ohne Prompt auf, arbeitet Claude einen eingebauten Wartungsprompt ab (Doku zu geplanten Aufgaben (externe Seite, code.claude.com)). Gemeint ist die Pflege der laufenden Arbeit: Liegengebliebenes fortsetzen, sich um den Pull Request des Branches kümmern, aufräumen. Seine Grenze taugt als Vorbild für Wartung am Rechner. Claude beginnt dabei nichts Neues, und Unumkehrbares wie Pushen oder Löschen geschieht nur, wenn es etwas fortsetzt, das der Verlauf schon erlaubt hat. Ein eigener Wartungsprompt nennt ebenso, was der Lauf darf. Alles andere bleibt Vorschlag.

Was ein Lauf ohne Befund kostet

Auch ein Wartungslauf ohne Befund verbraucht Token. Routines zehren vom Kontingent des Abos wie eine Sitzung, die man selbst führt (Doku zu Routines (externe Seite, code.claude.com)). Ein Lauf mit claude -p und --output-format json gibt seine Kosten mit aus. Die Zahl ist eine Schätzung auf dem eigenen Rechner und kann von der Rechnung abweichen.

Daraus ergibt sich eine sparsame Abwandlung der Bauform. Ein gewöhnliches Skript prüft die harte Bedingung, etwa ob eine Platte über 90 Prozent voll ist. Erst wenn sie zutrifft, liest Claude den Fall und schlägt einen Schritt vor. Der Werkstattbericht zum Meldungsautomaten kommt aus anderer Richtung zur selben Regel: Harte Bedingungen gehören in Code, weil ein Zeichenvergleich verlässlicher prüft als ein zweiter Aufruf des Modells.

Stille ist kein Befund

Die Bauform der ersten Ebene meldet sich nur bei einem Befund. Ihr Schwachpunkt ist der Lauf, der gar nicht stattfindet oder unbemerkt scheitert. Derselbe Werkstattbericht beschreibt so einen Fall. Vom 02. bis zum 05.08.2026 bewertete der Automat nichts, unter anderem wegen eines erschöpften Wochenkontingents und eines fehlenden Programms nach einem Update. Die Läufe endeten trotzdem ohne Fehlercode, und die Überwachung sah saubere Läufe. Der Bericht zieht daraus die Regel, dass ein Ausfall sich selbst melden muss.

Die Doku kennt dasselbe Problem an drei Stellen:

• Routines: Ein grüner Status heißt nur, dass die Sitzung ohne Fehler der Infrastruktur endete. Ob die Aufgabe gelang, zeigt erst der Verlauf (Doku zu Routines (externe Seite, code.claude.com)).
• Lauf ohne Terminal: Ein Fehler wie eine fehlende Anmeldung steht als Ergebnis in der Standardausgabe, also dort, wo ein Skript den Befund erwartet (Doku zum Lauf ohne Terminal (externe Seite, code.claude.com)).
• Desktop-App: Die Liste vergangener Läufe zeigt auch die ausgefallenen (Doku zur Desktop-App (externe Seite, code.claude.com)). Ansehen muss sie allerdings jemand.

Für einen Wartungslauf folgt daraus ein zweiter Kanal. Fehlt der letzte Lauf oder endet er mit einem Fehler, ist das selbst ein Befund. Ein Zeichen, dass der Lauf stattfand, gehört deshalb zur Bauform, etwa ein Zeitstempel, den ein zweiter Prüfer liest.

Was offen bleibt

• Eine unabhängige Messung. Für den Nutzen bei Diagnose und Wartung gibt es nur Angaben des Herstellers über die eigene Arbeit und Einstufungen eines Modells, und die Studie lässt Läufe ohne Dialog aus.
• Rechte über sudo. Wie ein Lauf ohne Dialog mit einer Passwortabfrage umgeht, beschreiben die Seiten zu Rechten, Sandbox und Sicherheit nicht.
• Einstellungen in grafischen Oberflächen. Computer Use ist in der Kommandozeile eine Research Preview für macOS mit Pro oder Max und braucht eine interaktive Sitzung. Berichte darüber, wie verlässlich es Sys­tem­ein­stel­lungen ändert, fehlen in den Quellen dieses Kapitels.
• Wartung aus der Cloud im eigenen Netz. Routines sind eine Research Preview, selbst betriebene Umgebungen eine Beta für Team und Enterprise. In Pro und Max bleibt Wartung am eigenen Rechner deshalb an einen Lauf auf diesem Rechner gebunden.