Claude Code im Terminal: 7 Workflow-Upgrades für Power-User

Schon das Vanilla-Claude Code ist out of the box nützlich. Du installierst es, gibst Prompts ein, und es baut, was du brauchst. Das ist für die meisten die Vibe-Coding-Variante – und sie funktioniert.

Die Version von Claude Code, die jemand mit einem angepassten Terminal nutzt, ist ein anderes Werkzeug. Dort sind die Bash-Befehle, denen man vertraut, vorab freigegeben – Claude fragt also fast nie nach Genehmigungen. Eine CLAUDE.md liegt im Projekt-Root, sodass Claude deine Konventionen schon beim Öffnen der Session kennt. Und wenn eine Session durcheinandergerät, ist der erste Griff nicht der Neustart.

Dieser Artikel schließt die Lücke zwischen diesen beiden Setups – in sieben Upgrades. Keines davon dauert länger als zehn Minuten in der Einrichtung, und jedes zahlt sich binnen einer Woche aus.

Wenn du Claude Code noch nie geöffnet hast, ist unser Hauptguide zu Claude Code der bessere Einstiegspunkt. Alles Weitere hier setzt voraus, dass du bereits Prompts geben und Tool-Aufrufe akzeptieren kannst.

1. Hör auf, dieselben Befehle immer wieder zu genehmigen

Standardmäßig fragt jeder neue Tool-Aufruf nach Freigabe. Beim ersten pytest-Lauf ok. Beim dritten nervig. Beim zehnten hämmerst du nur noch auf Enter, ohne zu lesen. Das ist das Schlechteste aus beiden Welten: Du ignorierst die Sicherheitsabfrage – und sie bremst dich trotzdem.

Klar, es gibt den Modus „dangerously bypass permissions“ bzw. „auto mode“. Die Trade-offs dazu haben wir ausführlich in meinem Tutorial zu Claude Code Auto Mode und Channels beleuchtet.

Berechtigungen in der settings.json definieren

Die Lösung ist eine .claude/settings.json im Projekt-Root mit einem permissions-Block, der vertraute Muster vorab genehmigt und unsichere blockiert:

{
  "permissions": {
	"allow": [
  	"Bash(pytest *)",
  	"Bash(uv run *)",
  	"Bash(ruff check *)",
  	"Read(~/.zshrc)"
	],
	"deny": [
  	"Bash(curl *)",
  	"Read(./.env)",
  	"Read(./.env.*)",
  	"Read(./secrets/**)"
	]
  }
}

Regeln werden in fester Reihenfolge ausgewertet: erst deny, dann ask, dann allow. Der erste Treffer gewinnt – eine deny-Regel sticht also jedes spätere allow.

Scope und Wildcards meistern

Drei Dinge stolpern bei der ersten Regeldatei gern.

1. Erstens der Scope. Eine projektweite .claude/settings.json überschreibt deine globale ~/.claude/settings.json. Wenn du also global Bash(rm *) erlaubt hast, ein Projekt es aber verbietet, gewinnt das Projekt. Das ist sinnvoll, überrascht aber, wenn man erwartet, dass globale Allows „kleben“.

2. Zweitens Wildcards bei Netzwerkbefehlen. Bash(curl http://github.com/ *) wirkt restriktiv, fängt aber kein https://, keine Optionen vor der URL, keine Redirects oder Variablenerweiterungen. Die empfohlene Praxis in der Doku: Bash(curl *) pauschal verbieten. Dann das WebFetch-Tool mit WebFetch(domain:github.com) für die Domains verwenden, die du wirklich erlauben willst.

3. Drittens Leerzeichen. Bash(ls *) matched ls -la, aber nicht lsof. Bash(ls*) matched beides. Das Leerzeichen vor dem Stern tut etwas – achte bewusst darauf, was du schreibst.

Ein paar Tastenkürzel gehören in dieselbe Kategorie „kämpf nicht gegen das Terminal“ und lohnen sich ab Tag eins:

• Shift+Tab wechselt die Berechtigungsmodi (Standard, Auto-Accept, Plan)

• Esc+Esc öffnet den Rewind-Picker (mehr dazu in #3)

• Ctrl+R durchsucht die Prompt-Historie rückwärts – wie in bash und zsh

• Ctrl+U löscht vom Cursor bis zum Zeilenanfang

• Shift+Enter fügt eine neue Zeile innerhalb des Prompts ein

Die meisten dieser Shortcuts funktionieren im Terminal direkt. Falls nicht, einmal den Slash-Befehl /terminal-setup ausführen, um alles zu installieren.

2. Bring Claude Code dazu, sich an dein Projekt zu erinnern

Jede Session startet mit einem frischen Kontextfenster.

Standardmäßig merkt sich Claude nicht, dass du uv statt pip verwendest. Es merkt sich nicht, dass Tests in tests/ und nicht in test/ liegen. Und die API-Konventionen, die du gestern zehn Runden lang erklärt hast, sind auch weg. Die Lösung ist eine CLAUDE.md im Projekt-Root. Starte Claude Code aus diesem Ordner (oder einem Unterordner), und die Datei wird vor deinem ersten Prompt automatisch in den Kontext geladen.

Am schnellsten startest du mit /init. Führe es im Projekt aus. Claude liest den Code und schreibt eine Starter-CLAUDE.md mit Build-Befehlen, Testanweisungen und erkannten Konventionen. Danach bearbeitest du sie, denn /init liefert eine solide Basis, keine fertige Datei.

Claude zieht Kontext aus drei Quellen – übereinander gestapelt:

Projekt-CLAUDE.md unter ./CLAUDE.md liegt im Repo. Sie ist für alle gleich – daher hier projektspezifische Fakten ablegen:

• Der Paketmanager und die Sprachversion
• Der Testbefehl und der Speicherort der Tests
• Die Verzeichnisstruktur und nicht offensichtliche Konventionen
• Alles, was ein neues Teammitglied am ersten Tag wissen muss

User-CLAUDE.md unter ~/.claude/CLAUDE.md begleitet dich über alle Projekte auf deiner Maschine. Hier stehen persönliche Vorlieben: dein Codestil, dein bevorzugtes Docstring-Format, deine Sprachen erster Wahl. Keine Projektfakten, sonst schwappen sie in jedes andere Repo.

Auto-Memory ist die dritte Schicht, die Claude selbst schreibt. Wenn du es in der Session korrigierst („wir nutzen hier snake_case, nicht camelCase“), loggt es das nach ~/.claude/projects/<project>/memory/MEMORY.md. Die ersten 200 Zeilen oder 25 KB dieser Datei werden zu Beginn jeder Unterhaltung im gleichen Projekt geladen. Mit /memory siehst du, was geladen wird und kannst Auto-Memory ein- oder ausschalten.

Eine Daumenregel zur Größe: Halte jede CLAUDE.md unter 200 Zeilen. Darüber frisst sie spürbar Kontext in jeder Runde, und Claude folgt langen Dateien weniger zuverlässig als kurzen. Wenn deine Datei darüber hinauswächst, teile sie in .claude/rules/ mit Pfad-Scopes. Was tatsächlich in eine CLAUDE.md gehört, erläutere ich ausführlich im Guide Writing the best CLAUDE.md tutorial.

3. Hör auf, Sessions neu zu starten, wenn sie entgleisen

Wenn sich eine Session falsch anfühlt, ist der Impuls oft /clear und Neustart. Meist ist das der falsche Impuls. Du wirfst damit die Dateipfade weg, die Claude bearbeitet hat, den verfolgten fehlschlagenden Test oder die zu Beginn erklärten Constraints. Eine frische Session muss all das neu lernen – das kostet Tokens und Zeit.

Zuerst solltest du die Symptome erkennen. Kontextverfall zeigt sich deutlich:

• Claude fragt erneut nach einem Pfad, den es vor fünf Runden bearbeitet hat
• Es wiederholt einen Vorschlag, den du schon abgelehnt hast
• Es verliert den Überblick über den aktuellen Branch
• Du hast es in einer Session mehr als zweimal zur selben Sache korrigiert

Sobald du das siehst, hast du vier Optionen – nicht austauschbar:

Deine Session komprimieren

 /compact ist besser als sein Ruf.

Deine Projekt-CLAUDE.md überlebt das. Claude liest die Datei nach dem Komprimieren erneut von der Platte und injiziert sie wieder – deine Konventionen gehen also nicht verloren. Du kannst die Zusammenfassung mit Fokus-Hinweisen steuern, z. B. /compact keep the auth refactor decisions, drop the failed test runs. Das ist der Unterschied zwischen nützlich und generisch.

Die „Undo“-Option von Claude Code nutzen

Der Esc+Esc-Rewind-Picker ist die Funktion, die viele nicht kennen. Er zeigt alle Prompt-Checkpoints der Session. Nach der Auswahl hast du drei Optionen: nur die Unterhaltung wiederherstellen, nur den Code, oder beides.

„Code und Unterhaltung wiederherstellen“ ist meist das Richtige. Eine halbe Stunde schlechter Runden verschwindet, ohne dass du git öffnest. Das ist das nächste an „Undo“ für eine ganze Session.

Wenn du nicht mehr neu startest, kommt als Nächstes die Frage: Sessions wiederfinden.

Sessions benennen und wieder öffnen

claude -n <name> (oder --name) startet eine benannte Session. Der Name erscheint in /resume und im Terminal-Titel. Wenn du im selben Repo drei Dinge parallel machst (Experiment-Branch, Refactor, Debug), helfen Namen beim Unterscheiden. /rename ändert den Namen mitten in der Session, wenn sich der Scope verschiebt.

Profi-Tipp: Nutze /color, um Sessions zusätzlich zu unterscheiden, wenn du mehrere im gleichen Terminal-Fenster laufen lässt.

Zum Wiederöffnen gibt es zwei Flags. claude --continue (oder -c) lädt die jüngste Unterhaltung im aktuellen Verzeichnis – ideal, wenn du gerade hier warst und weitermachen willst.

claude --resume öffnet einen interaktiven Picker, und claude --resume <name-or-id> springt direkt in eine bestimmte Session. Behandle Sessions wie git-Branches: Unterschiedliche Workstreams verdienen ihre eigene.

4. Schwieriges planen, Einfaches günstig erledigen

Der größte Kostenhebel in einem Custom-Setup ist nicht Editor oder Shortcuts, sondern wie gut du den Rechenaufwand dem Schwierigkeitsgrad der Aufgabe anpasst. Drei Tools greifen hier zusammen: Planmodus, /effort und /model.

Den Planmodus in Claude Code nutzen

Der Planmodus zwingt Claude dazu, erst einen Ansatz zu durchdenken, bevor Dateien angefasst werden. Es schreibt den Plan, du prüfst ihn, gibst frei oder widersprichst – erst dann wird ausgeführt.

Ein simpler Prompt, mit dem ich Pläne besonders robust mache:

Red-team this plan from multiple angles using as many Opus 4.7 agents as you need.

Das startet mehrere Subagenten, die den Plan aus verschiedenen Blickwinkeln prüfen und Verbesserungen vorschlagen. Besonders sinnvoll bei Plänen mit über 500 Zeilen.

Der Preis: Planung plus Red-Teaming fügen zwei Runden hinzu, bevor Code landet. Für alles unterhalb größerer Features oder Bugfixes ist das Overkill.

Es gibt fünf Wege, in den Planmodus zu wechseln:

Die inline-Variante (/plan refactor the auth module to use JWT) übersehen viele: Sie setzt Modus und Aufgabe in einem Schritt. Für einen detaillierten Walkthrough von Review-first-Plan-Workflows erklärt mein Claude Code Planmodus-Tutorial jeden Schritt.

Ein passendes Effort-Level setzen

Als Nächstes: Effort. Es steuert, wie viel „Extended Thinking“ Claude pro Runde investiert. Höherer Effort bedeutet tiefere Begründung, mehr Tokens, langsamere Antwort.

/effort <level> und das CLI-Flag --effort <level> akzeptieren alle fünf Stufen. Low, medium, high und xhigh bleiben über Sessions hinweg bestehen. Max gilt nur für die aktuelle Session, weil es die Token-Bremse entfernt – du setzt es also bewusst jedes Mal neu. Der richtige Alltagsstandard ist low oder medium. high bzw. xhigh hebst du dir für wirklich harte Nüsse auf und max für Momente, in denen du lieber Tokens verbrennst als falsch liegst.

Ein Gegenpunkt: Ein Modell auf low mit starkem Kontext schlägt oft dasselbe Modell auf max mit schwachem Kontext. Den Prompt aufzuräumen bringt meist mehr als den Effort hochzudrehen.

Das passende Modell wählen

Die größten Einsparungen kommen bei der Modellauswahl. /model wechselt mitten in der Session, und Option+P (macOS) / Alt+P (Win/Linux) wechselt das Modell, ohne deinen aktuellen Prompt zu löschen. Nützliche Aliasse:

• sonnet ist der Daily Driver

• opus für die härtesten Probleme (der Alias best zeigt ebenfalls auf Opus)

• haiku für maximale Geschwindigkeit

• sonnet[1m] und opus[1m] sind die 1M-Kontext-Varianten

• opusplan nutzt Opus im Planmodus und Sonnet in der Ausführung

• default hebt Overrides auf und geht zurück zum empfohlenen Modell

Wenn du standardmäßig alles mit Opus erledigst, ist der Wechsel zu Sonnet für den Großteil deines Tages der größte mögliche Kostenschnitt.

Opus ist richtig, wenn du an etwas Hartem festhängst und das schlauste Modell willst. Sonnet deckt fast alles andere ab. Die Kostendifferenz ist so groß, dass „zur Sicherheit immer Opus“ die teuerste Gewohnheit im Autopilot ist.

5. Automatisiere, was du noch per Hand tust

Sind die Reibungsverluste weg, folgt die Arbeit, die du noch manuell erledigst.

Geplante Tasks

Automatisieren ist leichter, als es zu lassen. Zwei Features decken das meiste ab: /loop für wiederkehrende Checks, die du sonst babysittest, und Hooks für Garantien, die eine CLAUDE.md nicht erzwingen kann.

/loop führt einen Prompt oder Slash-Befehl wiederholt aus. Zwei Syntax-Varianten:

• /loop 5m <prompt> führt den Prompt alle 5 Minuten aus

• /loop <prompt> überlässt das Intervall dem Modell

Intervalleinheiten: s, m, h und d, Mindestintervall 1 Minute. Erfordert Claude Code v2.1.72 oder höher.

Beispiel: Ein Test-Watcher mit /loop 2m run the test suite and report failures. Statt nach jeder Änderung an Tests zu denken (und es oft zu vergessen), fängt Claude defekte Tests beim nächsten 2-Minuten-Tick ab.

Genauso für Staging-Deploy-Checks (/loop 10m check if the staging deploy is green) oder Log-Tailing bei flakey Incidents (/loop 1m tail the last 50 lines of app.log and flag errors).

Loops leben 7 Tage.

Am siebten Tag feuert der Task ein letztes Mal und löscht sich selbst. Sie sind session-gescoped, --continue oder --resume bringt sie zurück, wenn du schließt und wieder öffnest. Zum vorzeitigen Stoppen drücke Esc. Wenn du Zeitpläne brauchst, die Session-Schließen überleben (nächtlich, wöchentlich), nutze Routines via /schedule.

Hooks

Hooks sind die zweite Hälfte. Sie führen Shell-Befehle an definierten Punkten im Claude-Workflow aus, konfiguriert in .claude/settings.json.

Warum ein Hook statt einer CLAUDE.md-Anweisung? CLAUDE.md ist beratend, Hooks laufen garantiert. Klassiker: „Nach jedem Edit den Linter ausführen“ – was Claude gern mal vergisst. Ein Hook schließt die Lücke.

Sechs Events decken die meisten Fälle ab:

Ein minimales PostToolUse-Beispiel, das nach jedem Edit lintet:

{
  "hooks": {
	"PostToolUse": [
  	{
    	"matcher": "Edit|Write",
    	"hooks": [
      	{ "type": "command", "command": "/path/to/lint-check.sh" }
    	]
  	}
	]
  }
}

Ein wichtiger Stolperstein: Nur Exit-Code 2 blockiert Claude wirklich. Exit 1 gilt als nicht-blockierender Fehler – Claude macht weiter, obwohl 1 im Unix-Umfeld oft für Fehler steht. Wenn dein Hook eine Regel erzwingen soll, gib 2 zurück.

Hooks musst du nicht von Hand schreiben.

Frag Claude mit „write a hook that runs ruff after every file edit“, und es entwirft dir das JSON. Mit /hooks listest du alle aktiven Hook-Konfigurationen – ohne in Settings-Dateien zu greppen, wenn unerwartet etwas feuert. Den kompletten Event-Katalog und die JSON-Schemas für stdin/stdout erkläre ich im Claude Code Hooks Tutorial.

6. Behalte die Kosten im Blick

Loops, lange Sessions und Opus-als-Standard verbrennen Tokens. Drei Befehle machen die Ausgaben sichtbar – die Gewohnheit ist der schnelle Blick, nicht die Dauer-Konfiguration.

/usage zeigt deinen Plan, Session-Gesamtwerte, Kosten je Modell und Fortschrittsbalken für die 5-Stunden- und Wochenratelimits.

/context visualisiert das aktuelle Kontextfenster als farbiges Raster – mit Kapazitätswarnungen und Hinweisen, welche Tools oder Dateien Platz fressen. Nutze es, wenn sich eine Session „schwerfällig“ anfühlt und du zwischen /compact und /clear entscheidest.

/statusline richtet eine permanente Zeile am unteren Rand deines Terminals ein. Sie kann Modell, Kontext-Prozent, Ratelimits und alles anzeigen, was aus dem Session-JSON auslesbar ist. Das verändert Verhalten am stärksten, weil die kostenrelevanten Zahlen im peripheren Blick bleiben.

Du kannst /statusline ausführen und in normaler Sprache beschreiben, was angezeigt werden soll – Claude generiert das Script und aktualisiert die Settings. Oder du schreibst selbst ein Shell-Script und verweist in ~/.claude/settings.json darauf:

{
  "statusLine": {
	"type": "command",
	"command": "~/.claude/statusline.sh"
  }
}

Für langfristiges Tracking über Sessions hinweg bündelt npx ccusage den Token-Verbrauch über die Zeit. Community-Tool, nicht von Anthropic, aber genau die Lücke zwischen Session-/usage und Monatsrechnung.

7. Drei weitere Features, die du kennen solltest

Die sechs Upgrades oben nutze ich täglich. Die drei hier seltener – aber es lohnt sich, sie zu kennen, damit du sie am Tag X parat hast.

Push-to-Talk mit /voice nutzen

/voice aktiviert Push-to-Talk-Diktat. Space halten, sprechen, loslassen – der Text landet transkribiert im Prompt. Erfordert v2.1.69 oder höher, zwanzig Sprachen werden unterstützt.

Stimme schlägt Tippen, wenn du unterwegs bist und laut denkst oder zu Beginn einer Aufgabe die Absicht diktierst. Für Zeilenänderungen ist Tippen meist schneller („ändere Zeile 47 zu …“).

Cloud-Sessions mit /teleport ziehen

/teleport (Alias /tp) holt eine Cloud-Session ins lokale Terminal. Beispiel: Du hast eine lange Aufgabe in der Web- oder iOS-App gestartet und sitzt wieder am Laptop. claude --teleport öffnet einen Picker und bringt die Session ins Terminal – mit dem richtigen Branch bereits ausgecheckt.

Ein paar Voraussetzungen müssen passen:

• Sauberer Git-Status
• Richtiges Repo
• Dasselbe claude.ai-Konto wie in der Cloud-Session
• Branch ist zum Remote gepusht

Verwechsele --teleport nicht mit --resume. Letzteres öffnet nur lokale Sessions aus dem Verlauf dieser Maschine. Den kompletten Ablauf erklärt unser Claude Code Remote-Control-Tutorial im Detail.

Nebenfragen mit /btw stellen

/btw ist für die schnelle Frage zwischendurch – ohne den Flow zu brechen.

Stell dir vor, Claude ist mitten in einer Aufgabe. Ein langer Edit oder Tool-Call läuft – und du musst schnell wissen, wie der Regex für IPs aussieht oder welcher Flag X macht.

Tippe einfach /btw <question>, und die Antwort erscheint in einem schließbaren Overlay. Die laufende Aufgabe geht weiter, die Antwort landet nicht im Verlauf – du brauchst also keine neue Session für einen Einmal-Nachschlag und verschmutzt die aktuelle nicht.

Fazit

Der schnellste Weg, all das wieder zu verlernen, ist, alles an einem Tag zu probieren. Nimm dir zwei, drei Punkte, bau dir dafür Muskelgedächtnis auf – und ergänze den Rest, wenn die ersten automatisch laufen.

Drei zum Start – je einer für einen anderen Teil des Tages, damit sie sich nicht in die Quere kommen:

• Eine schlanke Projekt-CLAUDE.md plus zwei, drei Wildcard-Berechtigungsregeln in .claude/settings.json für die Bash-Befehle, die du sonst jede Session neu freigibst. Das ist die Morgenroutine – du merkst es daran, dass die Unterbrechungen aufhören.

• Die Entscheidung /compact versus /clear und der Esc+Esc-Rewind-Picker. Das ist die Mid-Session-Gewohnheit – der Auslöser ist der Moment, in dem Claude erneut nach einem Pfad fragt, den es vor einer Stunde kannte.

• Ein /loop für einen wiederkehrenden Check, der dich schon heute Zeit kostet. Das ist die Hintergrund-Gewohnheit – läuft es erst, zahlt es von allein zurück.

Wenn die Unterschiede zwischen Sonnet, Opus und Haiku noch unklar sind, führt unser Introduction to Claude Models Kurs durch die passenden Einsatzzwecke. Dann fallen dir /effort- und /model-Entscheidungen deutlich leichter.