claudeBenutzer09
9

Erweiterte Funktionen

Die Funktionen für den ernsten Fall: erst planen und dann ausführen, Autonomie mit Leitplanken, Isolation auf Betriebssystemebene, Läufe ganz ohne Terminal — und die Schalter, die eine Organisation zentral setzt.

Profi 1,5 Stunden

Die Funktionen in diesem Modul haben eines gemeinsam: Sie greifen dort, wo eine Aufgabe groß, riskant oder unbeaufsichtigt ist. Ein Plan vor der ersten Änderung, ein Ersatzmodell, wenn das erste ausfällt, ein Klassifikator, der entscheidet, wobei noch nachgefragt wird, eine Sandbox um Dateisystem und Netzwerk, ein Lauf ganz ohne Terminal — und eine Reihe Schalter, die eine Organisation zentral vorgibt.

Erst planen, dann tippen — und wie tief Claude nachdenkt

Der Plan-Modus zieht eine Linie zwischen Recherche und Änderung. Claude darf lesen und suchen, aber nichts schreiben und keine Befehle absetzen; am Ende steht ein Vorschlag, den du liest, ergänzt oder verwirfst. Erst deine Freigabe schaltet das Schreiben frei. Der Gewinn liegt weniger im Plan selbst als in der Reihenfolge: Was falsch verstanden wurde, fällt auf, bevor die erste Datei angefasst ist.

In den Modus kommst du auf drei Wegen: /plan — wahlweise samt Aufgabe, etwa /plan fix the auth bug —, das Flag --permission-mode plan beim Start oder Shift+Tab, das durch die Berechtigungsmodi blättert. Ctrl+G öffnet den aktuellen Plan in dem Editor, den $VISUAL oder $EDITOR nennt, sodass du längere Änderungen dort schreibst statt im Prompt. Wer beim Denken Opus, beim Umsetzen aber Sonnet will, nimmt den Alias opusplan: Er löst im Plan-Modus zu Opus auf und bei der Ausführung zu Sonnet — jeder Moduswechsel ist damit auch ein Modellwechsel und beginnt einen frischen Prompt-Cache: 

claude --model opusplan "redesign the database schema for multi-tenancy"

Wie lange Claude vor der Antwort nachdenkt, steuerst du getrennt davon. Option+T (macOS) oder Alt+T schaltet Extended Thinking für die Session um. /effort nimmt low, medium, high, xhigh, max oder ultracode; welche Stufen zur Auswahl stehen, hängt am Modell, und max wie ultracode gelten nur für die laufende Session. auto ist keine weitere Stufe, sondern setzt auf den Standard des Modells zurück. Über Sessions hinweg hält CLAUDE_CODE_EFFORT_LEVEL eine Vorgabe. Zwei Wörter wirken direkt im Prompt: ultrathink zieht die Denktiefe unabhängig von der Effort-Einstellung hoch, ultracode löst einen dynamischen Workflow aus — dieses Schlüsselwort hieß bis v2.1.160 workflow, und wer das Wort tippen will, ohne einen Lauf auszulösen, setzt workflowKeywordTriggerEnabled auf false.

MAX_THINKING_TOKENS ist keine Ein-Aus-Schaltung, sondern die Obergrenze des Denk-Budgets; sie reicht höchstens bis zu den maximalen Ausgabe-Tokens des Modells minus eins. Der Wert 0 schaltet das Denken auf der Anthropic API ab — außer bei Fable 5, das immer denkt. Bei Drittanbietern bewirkt 0 etwas anderes: Der thinking-Parameter entfällt dann einfach, und das Modell kann trotzdem denken. Die Unterscheidung nach Modellgeneration gehört zu einer anderen Variablen: CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING nimmt Opus 4.6 und Sonnet 4.6 das adaptive Reasoning und ist ab v2.1.111 auf Fable 5, Sonnet 5 sowie Opus 4.7 und neuer wirkungslos.

Beide Schalter zusammen ergeben die Gangart für schwierige Entwurfsfragen — Plan-Modus für die Reihenfolge, eine hohe Effort-Stufe für die Tiefe, dazu das Modell-Routing: 

claude --permission-mode plan --effort high --model opusplan "migrate from REST to GraphQL"

Wenn das Modell überlastet ist: die Ersatzkette

Fällt das Hauptmodell aus, muss die Anfrage nicht scheitern. Claude Code kann auf ein Ersatzmodell wechseln, wenn das primäre überlastet oder nicht erreichbar ist oder einen anderen Serverfehler liefert, der sich nicht durch einen erneuten Versuch beheben lässt. Fehler bei Anmeldung, Abrechnung, Rate Limit, Anfragegröße und Transport lösen bewusst keinen Wechsel aus — sie laufen durch die normale Wiederholungslogik. Der Wechsel gilt für den Rest des laufenden Turns; die nächste Nachricht beginnt wieder beim primären Modell, und ein Hinweis in der Sitzung zeigt an, dass gewechselt wurde.

Für eine einzelne Sitzung reicht das Flag --fallback-model mit einer kommaseparierten Liste: 

claude --fallback-model sonnet,haiku

Soll die Kette dauerhaft stehen, gehört sie als Array in die Einstellung fallbackModel: 

{
  "fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]
}

Drei Regeln lohnen sich zu merken. Das Flag schlägt die Einstellung. Jeder Eintrag darf ein Modellname oder ein Alias sein, und "default" löst zum Standardmodell deines Account-Typs auf. Nach dem Entfernen von Duplikaten bleiben höchstens drei Modelle stehen; alles Weitere wird ignoriert. Und anders als die meisten Array-Einstellungen mischt sich fallbackModel nicht über die Einstellungsdateien hinweg: Die Datei mit dem höchsten Vorrang liefert die ganze Kette. Zusammen mit availableModels ist das die einzige Ausnahme von der Merge-Regel.

Ultraplan: den Entwurf in die Cloud auslagern

Ultraplan verschiebt genau den Teil in die Cloud, der am längsten dauert: das Entwerfen. Eine Sitzung von Claude Code on the web arbeitet im Plan-Modus an deiner Aufgabe, während dein Terminal frei bleibt. Der fertige Entwurf landet in einer Ansicht im Browser, die mehr kann als ein Terminal — Abschnitte einzeln kommentieren statt auf den ganzen Text zu antworten.

Starten kannst du auf drei Wegen: mit /ultraplan und deinem Auftrag dahinter, indem du das Wort ultraplan irgendwo in einen normalen Prompt schreibst, oder indem du im Freigabedialog eines fertigen lokalen Plans „Nein, mit Ultraplan auf Claude Code on the web verfeinern" wählst. Die ersten beiden Wege fragen vorher nach; der dritte nicht, weil die Auswahl im Dialog bereits die Bestätigung ist. Läuft gerade Remote Control, trennt sich die Verbindung beim Start — beide Funktionen belegen denselben Kanal.

Während die Cloud arbeitet, steht über deiner Eingabe eine Statuszeile: ◇ ultraplan, solange recherchiert und geschrieben wird, ◇ ultraplan needs your input bei einer Rückfrage und ◆ ultraplan ready, wenn der Entwurf zur Prüfung bereitliegt. /tasks öffnet dazu eine Detailansicht mit dem Sitzungslink, der Aktivität und einem Abbruch; ein Abbruch archiviert die Cloud-Sitzung, und im Terminal bleibt nichts zurück. Im Browser markierst du Textstellen und kommentierst sie, reagierst mit Emoji auf einen Abschnitt und lässt überarbeiten, so oft du willst.

Steht der Plan, entscheidest du im Browser, wo er ausgeführt wird:

  • In der Cloud ausführen — Claude setzt den Plan in derselben Sitzung um, und du prüfst das Diff im Browser und öffnest von dort den Pull Request
  • Zurück ins Terminal — der Plan kommt in deine CLI, wo du zwischen Weiterarbeiten in der laufenden Konversation, einer frischen Sitzung nur mit dem Plan und dem blossen Sichern in eine Datei wählst 
/ultraplan migrate the auth service from sessions to JWTs

Ultraplan setzt einen Zugang zu Claude Code on the web und ein GitHub-Repository voraus. Weil die Sitzung auf Anthropics Infrastruktur läuft, steht die Funktion bei Amazon Bedrock, Google Clouds Agent Platform und Microsoft Foundry nicht zur Verfügung. Fehlt noch eine Cloud-Umgebung, legt der erste Start eine an.

Auto Mode und die Frage, wer wann gefragt wird

Auto Mode dreht die Rückfrage um: Statt dich bei jedem Tool-Aufruf zu fragen, prüft ein eigenes Klassifikator-Modell die Aktion vorab und blockt, was über deine Anweisung hinausgeht, auf unbekannte Infrastruktur zielt oder nach fremdgesteuertem Inhalt aussieht. Ausdrückliche Nachfrage-Regeln erzwingen weiterhin eine Rückfrage. Gedacht ist das für Arbeit, die weitgehend allein laufen soll, bei der du aber um die riskanten Stellen weiterhin eine Leitplanke willst.

Bedient wird er wie jeder andere Modus: auto in den Berechtigungseinstellungen wählen oder mit Shift+Tab dorthin blättern, sofern der Modus in deinem Setup verfügbar ist. Was er als vertrauenswürdige Infrastruktur behandeln soll, beschreibt eine Organisation im Einstellungsblock autoMode.

Ab Werk ist der Klassifikator vorsichtig bei allem, was nach Abfluss von Daten, riskanter Shell-Ausführung oder Eingriffen in Produktionssysteme aussieht. Bleibt eine Prüfung hängen, färbt sich der Spinner rot — damit sichtbar ist, dass geprüft wird und nicht ein Tool arbeitet. Eigene Repos, interne Domains, Buckets oder Dienste, die als normal gelten sollen, gehören in autoMode.environment.

Beim Anpassen von autoMode.allow, autoMode.soft_deny, autoMode.hard_deny und autoMode.environment ist ein Detail entscheidend: Ohne die wörtliche Zeichenkette "$defaults" im Array ersetzt deine Liste die eingebauten Regeln vollständig. Steht sie darin, werden die Standardeinträge an genau dieser Stelle eingefügt, und deine eigenen können davor oder dahinter stehen.

Innerhalb des Klassifikators gilt eine feste Rangfolge. hard_deny blockt bedingungslos; weder eine Ausnahme aus allow noch deine erklärte Absicht kommen dagegen an. soft_deny blockt ebenfalls, lässt sich aber überstimmen — durch eine passende allow-Regel oder durch eine Aufforderung, die die Absicht klar benennt: „force-push this branch" hebt den weichen Block auf, ein vages „clean up the repo" nicht. Daraus folgt etwas, das eine Organisation wissen sollte: Weil allow als Ausnahme innerhalb des Klassifikators wirkt, kann ein selbst ergänzter allow-Eintrag ein soft_deny aus verwalteten Einstellungen aushebeln — die Kombination ist additiv, keine harte Policy-Grenze. Kommt es zu drei Blockaden in Folge oder zwanzig im Ganzen, hält der Modus an und die Rückfragen kehren zurück; genehmigst du die anstehende Aktion, geht es weiter. Eine erlaubte Aktion setzt den Serienzähler zurück, einstellbar sind die beiden Grenzen nicht.

Drei Unterbefehle machen die Regeln sichtbar, bevor du dich auf sie verlässt: claude auto-mode defaults gibt die eingebauten Regeln aus, claude auto-mode config die daraus und deinen Ergänzungen zusammengesetzte, tatsächlich wirksame Fassung, und claude auto-mode critique lässt deine eigenen Regeln kommentieren. So sieht eine Ergänzung aus, die die Standardwerte behält: 

{
  "autoMode": {
    "allow": ["$defaults", "Deploying to staging is allowed"],
    "soft_deny": ["$defaults", "Never run migrations outside the migrations CLI"],
    "hard_deny": ["$defaults", "Never send repo contents to third-party APIs"],
    "environment": ["$defaults", "Internal API: api.corp.example.com"]
  }
}

Die Berechtigungsmodi bilden ein Spektrum. default liest frei und fragt bei allem darüber hinaus. acceptEdits nimmt für die Sitzung die Rückfrage bei Datei-Änderungen heraus, mit Ausnahme geschützter Verzeichnisse. plan ist der Recherchemodus von oben. auto übergibt die Entscheidung dem Klassifikator. dontAsk führt ausschließlich vorab genehmigte Tools aus und verweigert den Rest. bypassPermissions überspringt die Abfragen weitgehend — seit v2.1.126 auch für Schreibvorgänge in vorher geschützte Pfade wie .claude/, .git/ oder Shell-Konfigurationsdateien, während besonders folgenreiche Löschbefehle weiterhin nachfragen. --dangerously-skip-permissions ist die Kurzform dafür; der bewusst unangenehme Name benennt den Handel, den du eingehst.

Beim Start wählt --permission-mode den Modus für genau diesen Lauf und überschreibt dabei defaultMode aus den Einstellungsdateien — praktisch, um eine einmalige Automatisierung strenger zu fahren, ohne die Konfiguration anzufassen. Das Flag arbeitet auch mit -p zusammen. dontAsk ist dabei der eine Modus, der im Shift+Tab-Zyklus fehlt — erreichbar ist er über dieses Flag oder über defaultMode in den Einstellungen, nur eben nicht durch Durchblättern. 

claude --permission-mode plan "draft the migration"
claude -p "audit dependencies" --permission-mode dontAsk

Damit die Mehrzahl deiner Sitzungen ohne Flag im gewünschten Modus startet, gehört der Standard in die Einstellungen: 

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Und so beschreibst du dem Klassifikator die Infrastruktur, der er vertrauen darf: 

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com"
    ]
  }
}

Verfügbar ist Auto Mode inzwischen bei jedem Anbieter von sich aus — Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Clouds Agent Platform, Microsoft Foundry. Die frühere Freischaltung über CLAUDE_CODE_ENABLE_AUTO_MODE=1 galt von v2.1.158 bis v2.1.206; seit v2.1.207 wird die Variable nur noch aus Kompatibilität angenommen und bewirkt nichts mehr. Geblieben sind zwei andere Bedingungen. Erstens das Modell: auf der Anthropic API und Claude Platform on AWS Opus 4.6 oder neuer, Sonnet 4.6 oder neuer oder Fable 5 — bei den übrigen Anbietern nur Sonnet 5, Opus 4.7 oder neuer und Fable 5. Zweitens die Organisation: auf Team- und Enterprise-Plänen muss eine Eigentümerrolle den Modus erst freigeben, und permissions.disableAutoMode in den verwalteten Einstellungen nimmt ihn ganz aus der Auswahl.

Zwei jüngere Einstellungen passen hierher. enforceAvailableModels (v2.1.175) dehnt die Allowlist availableModels auf das Standardmodell aus: Löst der Standard auf ein nicht erlaubtes Modell auf, greift das erste erlaubte, und Benutzer- oder Projekteinstellungen können eine verwaltete Liste nicht mehr aufweiten. footerLinksRegexes (v2.1.176) blendet zusätzliche Badges in die Fußzeile ein, wenn ein regulärer Ausdruck auf die Ausgabe eines Turns passt — jeder Eintrag bringt Muster, URL-Vorlage und wahlweise eine Beschriftung mit.

Ohne Terminal-Sitzung: Skriptbetrieb und Sandbox

Mit claude -p läuft Claude Code ohne interaktive Oberfläche: Der Prompt kommt als Argument, die Antwort geht nach stdout und lässt sich damit in Shell-Pipelines und Automatisierung einbauen. --output-format json liefert sie strukturiert, wenn ein Skript sie weiterverarbeiten soll, und für vollautomatische Läufe nimmt --permission-mode bypassPermissions die Rückfragen heraus. Hooks und Bash-Aufrufe in solchen Sitzungen lesen die aktive Denktiefe aus $CLAUDE_EFFORT; Ultracode ist dort keine eigene Stufe und meldet sich als xhigh.

/cd verschiebt eine laufende Sitzung in ein anderes Arbeitsverzeichnis, ohne den Prompt-Cache zu zerstören: Die CLAUDE.md des neuen Verzeichnisses kommt als zusätzliche Nachricht dazu, statt den System-Prompt neu zu bauen. Die Sitzung zieht dabei in die Ablage des neuen Verzeichnisses um, sodass --resume und --continue sie dort wiederfinden. Zusammen ergeben diese Bausteine Läufe, die niemand beaufsichtigen muss: 

# Automated code review in CI
git diff HEAD~1 | claude -p "review these changes for security issues" \
  --output-format json \
  --permission-mode bypassPermissions

# Generate docs for changed files
claude -p "generate JSDoc for all functions in $CHANGED_FILE" \
  --print --no-session-persistence

Sandboxing setzt die Grenze eine Ebene tiefer, im Betriebssystem statt in der Berechtigungslogik. Verfügbar ist die Sandbox-Variante von Bash unter macOS, Linux und WSL2; natives Windows unterstützt sie nicht — dort gehört Claude Code in eine WSL2-Distribution. In der Sitzung schaltet /sandbox um und legt die Wahl in .claude/settings.local.json ab; projektweit setzt du sandbox.enabled in ~/.claude/settings.json auf true. Ein Start-Flag dafür gibt es nicht; ab Werk ist sie aus. Danach erreicht Claude nur noch freigegebene Pfade und die Netzwerkziele, die du beschrieben hast — die Wahl, wenn fremder Code im Spiel ist.

Das Netzwerk regelst du über sandbox.network.allowedDomains und sandbox.network.deniedDomains. Die erste Liste öffnet ausgehenden Verkehr, die zweite schließt einzelne Ziele wieder — und zwar auch dann, wenn ein Platzhalter der ersten Liste sie erlauben würde. Deny gewinnt immer, und beide Listen verstehen Muster wie *.example.com: 

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"],
      "deniedDomains": ["uploads.github.com"]
    }
  }
}

In verwalteten Installationen ist die Blockliste bewusst nicht verhandelbar: deniedDomains wird aus allen Quellen zusammengeführt — verwaltet, Benutzer, Projekt, lokal — unabhängig von allowManagedDomainsOnly. Dieses Flag entscheidet nur, aus welchen Bereichen allowedDomains überhaupt gelesen wird. Eine Sperre, die jemand auf Benutzerebene gesetzt hat, kann eine Unternehmensrichtlinie so nicht stillschweigend fallen lassen.

Liegen die Hilfsprogramme der Sandbox unter Linux oder WSL2 an ungewöhnlichen Orten, benennen sandbox.bwrapPath und sandbox.socatPath die Binärdateien von bubblewrap und socat direkt und ersetzen die Suche über PATH. Beide Schlüssel werden ausschließlich aus verwalteten Einstellungen gelesen — in einer Benutzer- oder Projektdatei bleiben sie wirkungslos: 

{
  "sandbox": {
    "bwrapPath": "/usr/local/bin/bwrap",
    "socatPath": "/usr/bin/socat"
  }
}

Verwaltete Einstellungen sind überhaupt der Hebel für den Unternehmenseinsatz: Ausgerollt werden sie mit den Mitteln des jeweiligen Systems: unter macOS als plist, unter Windows über die Registry, dazu verwaltete Konfigurationsdateien und die Fragmente im Verzeichnis managed-settings.d/, die alphabetisch geordnet ineinandergreifen. Sie stehen über den Benutzereinstellungen. Von verwalteten Memory-Dateien wie einer organisationsweiten CLAUDE.md ist das getrennt. Sandbox und Skriptbetrieb lassen sich dabei kombinieren: 

# Headless run (sandboxing comes from sandbox.enabled, not from a flag)
claude -p "analyze the security of this codebase" \
  --permission-mode plan \
  --output-format json

Zweitmeinung im laufenden Turn: das Advisor-Tool

Das Advisor-Tool paart zwei Modelle in einer Sitzung. Das Hauptmodell arbeitet, und an den Stellen, an denen es zählt — bevor es sich auf einen Weg festlegt, wenn derselbe Fehler wiederkehrt, bevor es eine Aufgabe für erledigt erklärt —, holt es die Einschätzung eines zweiten, stärkeren Modells ein. Der Berater bekommt die vollständige Konversation samt aller Tool-Aufrufe und Ergebnisse und gibt eine Empfehlung zurück; die Ausführung bleibt beim Hauptmodell. Das lohnt sich bei langen, mehrstufigen Aufgaben, in denen die meisten Schritte Routine sind, die Qualität des Plans aber über das Ergebnis entscheidet — bei kurzer Arbeit oder wenn ohnehin jeder Schritt das stärkste Modell braucht, ist ein Modellwechsel die bessere Antwort.

Aktiviert wird der Berater dadurch, dass ein Advisor-Modell gesetzt ist — auf drei Wegen: /advisor mitten in der Sitzung (die Auswahl landet als advisorModel in deinen Benutzereinstellungen und gilt weiter), advisorModel direkt in der Einstellungsdatei oder --advisor für einen einzelnen Start. Danach zeigt die Sitzung eine Hinweiszeile mit dem Zusatz „experimental" an. Der Berater muss mindestens so leistungsfähig sein wie das Hauptmodell. Abschalten lässt sich das Ganze mit CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1: Dann verschwindet /advisor, ein gesetztes advisorModel wird ignoriert, und --advisor wird zwar noch angenommen, bleibt aber ohne Wirkung — bestehende Skripte laufen also weiter. Weil das Werkzeug serverseitig auf Anthropics Infrastruktur läuft, setzt es die Anthropic API voraus und steht bei Amazon Bedrock, Claude Platform on AWS, Google Clouds Agent Platform und Microsoft Foundry nicht zur Verfügung.

Suchen ohne Umweg auf macOS und Linux

Auf nativen Builds für macOS und Linux treten an die Stelle der Werkzeuge Glob und Grep die eingebetteten Programme bfs und ugrep, die über das Bash-Tool erreichbar sind. Der Unterschied ist der eingesparte Umweg: Claude setzt einen Bash-Befehl ab, statt ein eigenes Tool aufzurufen und auf dessen Antwort zu warten — in großen Repositories macht das die Suche spürbar schneller.

Für Windows und für Installationen über npm ändert sich nichts; dort bleiben die ursprünglichen Werkzeuge im Einsatz. Ebenso wirken CLAUDE_CODE_GLOB_HIDDEN, CLAUDE_CODE_GLOB_NO_IGNORE und CLAUDE_CODE_GLOB_TIMEOUT_SECONDS weiterhin dort, wo diese Werkzeuge noch verwendet werden.

Wie lange Sitzungsdateien liegen bleiben

cleanupPeriodDays bestimmt, wie lange Sitzungsdateien und andere Anwendungsdaten liegen bleiben, bevor sie beim Start gelöscht werden. Voreingestellt sind 30 Tage; kleiner als 1 geht nicht, und wer 0 einträgt, bekommt einen Validierungsfehler. Dieselbe Altersgrenze gilt für das Aufräumen verwaister Worktrees beim Start — Überbleibsel abgestürzter oder abgebrochener paralleler Läufe, und nur, solange sie keine uncommitteten Änderungen, keine unversionierten Dateien und keine ungepushten Commits enthalten; was du selbst mit --worktree angelegt hast, fasst dieser Durchlauf nie an. Kann Claude Code eine Einstellungsdatei nicht lesen, pausiert der Durchlauf mit einem Hinweis in /status, bis die Datei repariert ist: 

{
  "cleanupPeriodDays": 14
}

Soll im nicht-interaktiven Betrieb gar nichts erst geschrieben werden, gibt es --no-session-persistence neben -p; im Agent SDK entspricht dem persistSession: false. Wer Transkripte generell unterbinden will, setzt CLAUDE_CODE_SKIP_PROMPT_HISTORY.

Alles für ein Projekt auf einmal löschen

Reicht eine Aufbewahrungsfrist nicht und soll der Zustand eines Projekts sofort verschwinden, ist claude project purge das Werkzeug — verfügbar ab v2.1.124. Weg sind danach die Transkripte, die Aufgabenlisten, die Debug-Protokolle, was an Datei-Änderungen und Eingaben aufgezeichnet wurde, und der Projekteintrag gleich mit: 

# Preview what would be deleted
claude project purge --dry-run

# Purge state for the current project
claude project purge

# Skip the confirmation prompt
claude project purge --yes

# Interactively choose which items to remove
claude project purge --interactive

# Purge state for every project at once
claude project purge --all

Die Zusätze greifen ineinander: Mit claude project purge --all --dry-run siehst du über sämtliche Projekte hinweg, was ein vollständiges Löschen mitnähme, während nichts angefasst wird. -y überspringt die Rückfrage, -i lässt dich einzeln auswählen, und ein Pfad hinter dem Befehl adressiert ein anderes Projekt als das aktuelle.

Schalter, die es nur als Umgebungsvariable gibt

Einige Fähigkeiten haben weder einen Befehl noch eine Einstellung — sie hängen an einer Umgebungsvariablen. Die folgenden lohnen sich zu kennen, weil sie entweder beim Debuggen helfen oder in verwalteten Installationen gebraucht werden.

OTEL_LOG_RAW_API_BODIES schreibt die vollständigen Anfragen und Antworten der Messages API als OpenTelemetry-Log-Events. 1 legt sie inline ab, an der Inhaltsgrenze gekürzt (standardmäßig 60 KB); file:<dir> schreibt sie ungekürzt auf die Platte und hinterlässt im Event nur einen Verweis. Die Bodies enthalten die gesamte Konversation, weshalb das Einschalten zugleich die Zustimmung zu allem ist, was OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS und OTEL_LOG_TOOL_CONTENT preisgeben würden — und weshalb die Protokolle danach so sorgfältig zu behandeln sind wie Geheimnisse.

OTEL_RESOURCE_ATTRIBUTES nimmt eigene key=value-Paare, kommasepariert, ohne Leerzeichen und mit prozentkodierten Sonderzeichen. Jeder Metrik-Datenpunkt und jedes Event bekommt sie von Claude Code als Label angeheftet, und im Resource-Block reisen sie zusätzlich mit — damit lässt sich die Nutzung im eigenen Backend nach Team, Abteilung oder Kostenstelle aufschlüsseln. Eingebaute Attribute wie user.id oder session.id überschreibt das nie. Wer die Kardinalität niedrig halten will, lässt die Labels an den Datenpunkten mit OTEL_METRICS_INCLUDE_RESOURCE_ATTRIBUTES=false weg; im Resource-Block bleiben sie erhalten.

CLAUDE_CODE_USE_POWERSHELL_TOOL steuert das PowerShell-Tool, und die Voreinstellung hängt an der Plattform: Unter Windows ohne Git Bash ist es von sich aus an, 0 schaltet es ab; unter Windows mit Git Bash läuft die Einführung schrittweise, dort wählst du mit 1 oder 0 selbst. Unter Linux, macOS und WSL aktiviert erst 1 das Tool, und dafür muss pwsh im PATH liegen. Aktiviert führt Claude PowerShell-Befehle direkt aus, statt sie über Git Bash zu leiten.

DISABLE_UPDATES=1 blockiert jeden Aktualisierungsweg, auch das von Hand angestoßene claude update und claude install. Das ist die strengere Variante gegenüber DISABLE_AUTOUPDATER, das nur die automatische Aktualisierung verhindert, und gedacht für Installationen, die über einen eigenen Kanal verteilt werden und deren Version sich nicht ändern soll.

CLAUDE_CODE_SAFE_MODE=1 — gleichbedeutend mit --safe-mode — startet ohne jede Anpassung: CLAUDE.md, Skills, Plugins, Hooks, MCP-Server, eigene Befehle und Agenten, Output Styles, Workflows, Themes, Tastenbelegungen, Statuszeile und LSP-Server bleiben außen vor. Eine Ausnahme gibt es bewusst: Was die verwalteten Einstellungen vorschreiben, gilt weiterhin. Der Modus beantwortet damit die Frage, ob ein Fehlverhalten aus der Konfiguration stammt oder nicht.

CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1 — oder disableBundledSkills in den Einstellungen — nimmt die mitgelieferten Skills und Workflows vollständig heraus. Eingebaute Befehle wie /init bleiben dagegen tippbar und verschwinden nur aus dem, was das Modell sieht; für /doctor gibt es dafür DISABLE_DOCTOR_COMMAND. Skills aus Plugins, aus .claude/skills/ und aus .claude/commands/ bleiben unberührt.

CLAUDE_CODE_HIDE_CWD=1 lässt das Arbeitsverzeichnis aus dem Start-Banner verschwinden. Nützlich bei Aufzeichnungen und in geteilten Bildschirmen, wo schon der Pfad mehr verrät als gewollt — etwa den Benutzernamen des Betriebssystems.

CLAUDE_CODE_NATIVE_CURSOR=1 übergibt die Eingabemarke dem Terminal: Sichtbar ist dann dessen eigener Cursor und nicht der Block, den Claude Code sonst zeichnet. Damit gelten wieder die Einstellungen des Terminals für Blinken, Form und Fokus — was zählt, wenn ein bestimmter Cursor-Stil eingerichtet ist oder Barrierefreiheit im Spiel ist.

CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE ist seit v2.1.160 wirkungslos. Die Variable hielt Fast Mode früher auf Opus 4.6 fest, statt dem jeweiligen Standard zu folgen; Opus 4.6 unterstützt Fast Mode inzwischen gar nicht mehr.

CLAUDE_CODE_RESUME_PROMPT ersetzt die Nachricht, die beim Fortsetzen einer mitten im Turn beendeten Sitzung eingefügt wird; voreingestellt ist Continue from where you left off.. Skripte, die Agenten über lange Zeit starten und wieder aufnehmen, können hier eine deutlich direktivere Startanweisung hinterlegen. Ein leerer String bedeutet: wieder die Voreinstellung.

CLAUDE_CODE_ENABLE_FEEDBACK_SURVEY_FOR_OTEL=1 hält die Qualitätsumfrage „How is Claude doing?" am Leben, wenn der nicht-essenzielle Verkehr zu Anthropic ohnehin gesperrt ist: Die Bewertungen landen dann als OTEL-Events beim eigenen Collector und sonst nirgends. Voraussetzung ist eine der drei Sperren — CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY oder DO_NOT_TRACK; fehlt sie, tut die Variable nichts. Vorrang behalten CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY und die Richtlinie, die deine Organisation für Produkt-Feedback gesetzt hat.

ANTHROPIC_WORKSPACE_ID nennt den Workspace für die Workload Identity Federation. Deckt deine Federation-Regel mehr als einen Workspace ab, braucht der Token-Austausch diese Angabe, um sich für einen zu entscheiden — sonst fehlt ihm das Kriterium und der Austausch scheitert. Ist die Regel auf genau einen Workspace zugeschnitten, bleibt die Variable ungesetzt: 

# Capture full OTEL telemetry while reproducing an API bug
OTEL_LOG_RAW_API_BODIES=1 claude --print 'reproduce the failure'

# Slice metrics by team and cost center in your OTEL backend
OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123" \
  claude

# Enable PowerShell tool on macOS or Linux
CLAUDE_CODE_USE_POWERSHELL_TOOL=1 claude

# Block all updates on a locked-down machine
DISABLE_UPDATES=1 claude

# Hide the working directory in the startup banner
CLAUDE_CODE_HIDE_CWD=1 claude

# Use the terminal's own cursor at the input caret
CLAUDE_CODE_NATIVE_CURSOR=1 claude


# Override the resume continuation message for an agent boot script
CLAUDE_CODE_RESUME_PROMPT="Resume the migration and stop after the next test run." \
  claude --resume

# Route the session quality survey through your OTEL collector
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
  CLAUDE_CODE_ENABLE_FEEDBACK_SURVEY_FOR_OTEL=1 claude

# Workload identity federation with a multi-workspace rule
ANTHROPIC_WORKSPACE_ID=ws_01abcd... claude

Zwischen Terminal und Cloud hin und her

Unter claude.ai/code läuft Claude Code on the web — die Arbeit findet dort auf Infrastruktur statt, die Anthropic betreibt. Eine Cloud-Sitzung läuft weiter, wenn du den Browser schließt, und lässt sich unterwegs aus der Claude-App verfolgen.

Aus dem Terminal startet claude --cloud mit der Aufgabenbeschreibung eine solche Sitzung; --remote ist dafür nur noch ein veralteter Alias. Claude klont dein Repository von GitHub — lokale Commits also vorher pushen —, arbeitet den Auftrag selbstständig ab und kann am Ende einen Pull Request öffnen. Mehrere Aufrufe laufen parallel.

Die Gegenrichtung ist /teleport, kurz /tp: Es öffnet eine Auswahl, holt den Branch und den gesamten Gesprächsverlauf der Cloud-Sitzung ins lokale Terminal und lässt dich dort weiterarbeiten; ein claude.ai-Abonnement ist dafür Voraussetzung. Zusammen mit dem Start in die Cloud entsteht so eine Schleife, in der Arbeit dort läuft, wo sie gerade besser aufgehoben ist.

/autofix-pr startet eine Cloud-Sitzung, die den Pull Request deines ausgecheckten Branches beobachtet: Scheitert die CI oder kommentiert jemand im Review, sucht Claude die Ursache und pusht eine Korrektur. Den offenen PR ermittelt der Befehl über gh pr view, weshalb die gh-CLI vorhanden sein muss und ein anderer PR erst ausgecheckt wird. Ohne Argument gilt der Auftrag für jeden CI-Fehler und jeden Review-Kommentar; ein Prompt grenzt ihn ein, etwa /autofix-pr only fix lint and type errors. Die Claude GitHub App muss im Repository installiert sein, denn über sie kommen die PR-Webhooks: 

# Plan locally, execute in the cloud
claude --permission-mode plan
# ... finalize plan, commit, push ...
claude --remote "Execute the migration plan in docs/migration-plan.md"

# Pull the cloud session back when done
/teleport

Die Cloud-Umgebung bringt die üblichen Laufzeiten mit — unter anderem Node.js, Python, Go, Rust, Java, Ruby, Docker und PostgreSQL — und arbeitet mit ungefähr 4 vCPUs, 16 GB Arbeitsspeicher und 30 GB Platte; Netzzugriff regelt die Zugriffsstufe der Umgebung. Was aus dem Repository kommt, gilt auch in der Cloud: CLAUDE.md, Einstellungen, MCP-Server, Hooks und die Skills unter .claude/skills/ — sie sind Teil des Klons. Nicht mit reist, was auf deiner Maschine unter ~/.claude/ liegt; dafür lädt eine Cloud-Sitzung zusätzlich die Skills, die für deinen claude.ai-Account aktiviert sind. Projektkonfiguration gehört deshalb eingecheckt.

Das PR-Badge auf das eigene Review-Werkzeug lenken

Das PR-Badge in der Fußzeile zeigt normalerweise auf GitHub. prUrlTemplate richtet es auf ein anderes Review-Werkzeug — GitLab, Bitbucket oder eine interne Oberfläche. Die Vorlage ist ein URL-Muster mit den Platzhaltern {host}, {owner}, {repo}, {number} und {url}, gefüllt aus der PR-URL, die gh meldet. Sie wirkt auf das Badge und auf die Zusammenfassungen von Tool-Ergebnissen, nicht auf Verweise wie #123 im Fließtext. Der folgende Block zeigt nur die Form der Einstellung — welche Platzhalter eingesetzt werden, entscheidet die Liste oben: 

{
  "prUrlTemplate": "https://gitlab.example.com/org/repo/-/merge_requests/{number}"
}

Woher ein neuer Worktree abzweigt

Git-Worktrees erlauben mehrere ausgecheckte Branches nebeneinander, ohne Stash und ohne Branch-Wechsel; claude --worktree legt einen an und verknüpft ihn mit einem Verzeichnis dieses Namens. Wovon dieser Worktree abzweigt, steuert worktree.baseRef (seit v2.1.133). fresh — die Voreinstellung — nimmt origin/<default-branch> und damit einen Baum im Zustand des Remote; head nimmt deinen lokalen HEAD. Ein Branch-Name ist als Wert nicht vorgesehen: 

{
  "worktree": {
    "baseRef": "head"
  }
}

Der Unterschied zählt, sobald du unveröffentlichte Arbeit hast: Mit head sind ungepushte Commits und der Zustand des Feature-Branches im neuen Worktree vorhanden. Aus einem verknüpften Worktree heraus meint head dessen eigenen HEAD, nicht den des Haupt-Checkouts. Die Einstellung gilt für --worktree, für das Werkzeug EnterWorktree und für die Worktrees, in denen isolierte Subagenten arbeiten.

Claude an der grafischen Oberfläche

Computer Use gibt Claude Tastatur, Maus und Bildschirm unter macOS. Damit lässt sich in derselben Konversation eine App schreiben, übersetzen, starten, durchklicken und das Ergebnis als Bildschirmfoto festhalten. Gedacht ist es für Aufgaben, die ohne Oberfläche nicht gehen: einen nativen Build prüfen, eine Oberfläche von Anfang bis Ende testen, ohne dafür ein Test-Framework aufzusetzen, ein Layout-Problem nachstellen und beheben, oder ein Werkzeug bedienen, das nur grafisch existiert.

Claude greift vorher zu genaueren Mitteln: einem MCP-Server, der Shell oder der Chrome-Integration. Computer Use ist die Rückfallebene für alles, was auf diesen Wegen nicht erreichbar ist — native Programme, Simulatoren, Software ohne Schnittstelle.

Technisch ist es ein eingebauter MCP-Server namens computer-use, der ausgeschaltet geliefert wird: In der Sitzung /mcp aufrufen, den Server in der Liste suchen und aktivieren; die Entscheidung gilt pro Projekt weiter. Beim ersten Einsatz verlangt macOS die Rechte für Bedienungshilfen und Bildschirmaufnahme — nach dem Erteilen der Bildschirmaufnahme kann ein Neustart nötig sein. Danach wird jede App einzeln freigegeben: Claude fragt beim ersten Zugriff, die Freigabe gilt für die laufende Sitzung, und Programme mit weitem Zugriff wie Terminals, Finder oder die Systemeinstellungen bringen eine zusätzliche Warnung mit.

Während Claude arbeitet, werden die übrigen sichtbaren Fenster ausgeblendet, damit nur freigegebene Programme im Spiel sind; nach dem Turn kehren sie zurück. Dein Terminal bleibt sichtbar und ist von den Bildschirmfotos ausgenommen — Claude sieht seine eigene Ausgabe also nicht. Esc an beliebiger Stelle oder Ctrl+C im Terminal bricht sofort ab, blendet die Fenster wieder ein und gibt dir die Kontrolle zurück. Die Maschine ist dabei exklusiv belegt: Die Sperre hält ab der ersten Aktion, und seit v2.1.195 gibt erst das Beenden der Sitzung sie wieder frei, nicht schon das Ende der Aufgabe.

Vorausgesetzt sind macOS, ein Pro- oder Max-Plan, die Anmeldung über claude.ai und eine interaktive Sitzung — mit -p steht die Funktion nicht zur Verfügung, auf Team- und Enterprise-Plänen ebenso wenig. Über Amazon Bedrock, Google Clouds Agent Platform oder Microsoft Foundry ist sie nicht erreichbar; wer ausschließlich über einen dieser Wege arbeitet, braucht dafür ein eigenes claude.ai-Konto. Taucht computer-use in /mcp gar nicht auf, ist eine dieser Bedingungen nicht erfüllt.

Was sonst noch im Werkzeugkasten liegt

Der Rest des fortgeschrittenen Werkzeugkastens sei wenigstens genannt. Hintergrundaufgaben lassen lange Läufe weiterarbeiten, während du im Vordergrund weiterredest. Für Wiederholungen gibt es zwei verschiedene Dinge: /loop ist ein mitgelieferter Skill, der einen Prompt wiederholt, solange die Sitzung offen ist — mit Intervall oder ohne, dann bestimmt Claude den Takt selbst —, während /schedule (Alias /routines) Routinen anlegt, die auf Anthropics Infrastruktur laufen und dich nicht am Rechner brauchen. /resume, /rename und /teleport sorgen dafür, dass eine Sitzung zwischen Terminal, Browser und Desktop-App wandern kann.

Dazu kommt, was den Alltag betrifft: Diktieren mit /voice, die Browser-Anbindung über --chrome, Fernsteuerung vom Browser aus mit /remote-control, kurze interaktive Lektionen über /powerup, dauerhafte Aufgabenlisten und die Worktree-Abläufe von oben. Alles davon hängt am selben Berechtigungssystem — fortgeschritten zu arbeiten heißt deshalb vor allem, den passenden Modus mit der passenden Oberfläche zu verbinden.

Ein Problem mit diesem Modul melden