CGS IT Solutions GmbH — Claude Code Training · Erweiterung 4 · Konfiguration · v0.10.1

Erweiterung 4

Konfiguration im Detail

Vertiefung zu Modul 2 · Ebenen, Wirksamkeit, Bestand

Inhalt

1Vier Ebenen — und wer wen überstimmt 2Wann etwas wirkt — und wann es still ausfällt 3Der Bestand — nach Zweck statt alphabetisch 4Nachsehen statt raten — was wirklich gilt Glossar — Begriffe zum Nachschlagen

Was dieses Deck ergänzt

Modul 2 zeigt, wo die Dateien liegen. Hier geht es darum, welche gewinnt, wann eine Änderung greift, und warum manchmal nichts passiert.

  1. Vier Ebenen mit fester Reihenfolge — und eine Ausnahme, die anders funktioniert als alle anderen Schlüssel.
  2. Die meisten Änderungen wirken sofort, zwei erst nach einem Neustart.
  3. Ein Syntaxfehler in der eigenen Datei legt sie ganz still. In einer Firmenrichtlinie nicht — das ist der wichtigste Unterschied.
  4. 126 Schlüssel sind alphabetisch unbrauchbar. Nach Zweck gruppiert sind sie zu überblicken.
Dieses Deck nennt keine vollständige Schlüsselliste und soll das auch nicht. Sie ändert sich schneller als jede Folie — die Quelle ist die Doku, hier stehen die Gruppen und die Fallen.

Vier Ebenen

Und wer wen überstimmt

Die Reihenfolge

Bei gleichem Schlüssel gewinnt die höhere Ebene. Managed Settings gewinnen gegen alles — auch gegen Kommandozeilenargumente.

RangEbeneOrtGeteilt
1ManagedSystemebene, Registry, Server-Richtlinieja, von der IT
2KommandozeileArgumente beim Startnein
3Local.claude/settings.local.jsonnein
4Project.claude/settings.jsonja, eingecheckt
5User~/.claude/settings.jsonnein
Die Reihenfolge erklärt die häufigste Verwirrung im Team: Project schlägt User. Ein persönliches Abschalten in den User-Settings verpufft, wenn das Projekt es einschaltet — der wirksame Ort ist dann settings.local.json.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Welches Feature liegt wo

Nicht alles folgt derselben Aufteilung. Vor allem MCP (Model Context Protocol) und CLAUDE.md tanzen aus der Reihe.

FeatureUserProjectLocal
Settings~/.claude/settings.json.claude/settings.json.claude/settings.local.json
Subagenten~/.claude/agents/.claude/agents/—
MCP-Server~/.claude.json.mcp.json~/.claude.json pro Projekt
Plugins~/.claude/settings.json.claude/settings.json.claude/settings.local.json
CLAUDE.md~/.claude/CLAUDE.mdCLAUDE.mdCLAUDE.local.md
Subagenten haben keine Local-Ebene — wer einen nur für sich will, legt ihn unter ~/.claude/agents/ ab. Und die MCP-Zeile ist der Grund, warum ~/.claude.json nicht dieselbe Datei ist wie ~/.claude/settings.json.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Die Ausnahme: Permissions

Permission-Regeln folgen der Reihenfolge nicht. Sie werden über alle Ebenen hinweg zusammengeführt, statt einander zu überschreiben.

  1. Wird ein Werkzeug auf irgendeiner Ebene verweigert, kann keine andere es erlauben. Auch nicht die höhere.
  2. Ein deny in den User-Settings blockiert ein allow im Projekt — und umgekehrt.
  3. Ein Managed-deny lässt sich nicht mit --allowedTools aufheben. Umgekehrt darf --disallowedTools weiter einschränken.
Das ist bewusst so und richtig: eine Einschränkung soll sich addieren, eine Freigabe nicht. Wer Verbote überschreiben könnte, hätte keine.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Wann etwas wirkt

Sofort, nach Neustart — oder gar nicht

Sofort oder erst nach Neustart

Claude Code beobachtet die Settings-Dateien und lädt sie neu, wenn sie sich ändern. Die meisten Schlüssel wirken also ohne Neustart.

  1. Sofort: permissions, hooks, Zugangsdaten-Helfer. Über alle vier Ebenen hinweg.
  2. Der ConfigChange-Hook feuert für jede erkannte Änderung — damit lässt sich darauf reagieren.
  3. Erst beim Start: model — mitten in der Sitzung geht /model.
  4. Erst beim Start: outputStyle — er ist Teil des System-Prompts, der bei /clear oder Neustart neu gebaut wird.
Praktisch heißt das: eine Hook- oder Regeländerung kann man im laufenden Gespräch ausprobieren. Bei Modell und Output Style lohnt der Umweg nicht — da ist /model beziehungsweise ein Neustart schneller als Rätselraten.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Ungültige Einträge — zweimal anders

Der Unterschied zwischen Firmenrichtlinie und eigener Datei ist groß — und erklärt „meine Settings gehen plötzlich nicht mehr".

Managed: fehlertolerant

  • ein ungültiger Eintrag wird einzeln entfernt
  • alle übrigen Richtlinien gelten weiter
  • ein Tippfehler kann die Richtlinie nicht abschalten
  • Sicherheitsfelder scheitern sogar nach zu: eine ungültige Server-Erlaubnisliste gilt als leer

Eigene Dateien: streng

  • eine Datei, die die Prüfung nicht besteht, wird als Ganzes verworfen
  • ein Komma zu viel legt alle Regeln darin still
  • gilt für User-, Projekt- und Local-Settings
  • zusätzlich pausiert der Aufräumlauf und /status warnt
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Was aus dem Projekt nicht gelesen wird

Einige Schlüssel werden aus Projekt- und Local-Dateien bewusst ignoriert — damit ein geklontes Repository sich nicht selbst Rechte schreiben kann.

  1. autoMode — nur User, --settings und Managed. Ein Build-Schritt könnte sonst eigene Freigaben einschleusen.
  2. defaultMode: "auto" — im Projekt ignoriert: ein Repository kann sich Auto-Mode nicht selbst gewähren.
  3. skipDangerousModePermissionPrompt — im Projekt ignoriert, damit kein fremdes Repository die Warnung wegklickt.
  4. pluginConfigs — nur User und Managed, weil die Werte in Hook- und MCP-Konfigurationen eingesetzt werden.
Das Muster dahinter ist immer dasselbe: Was Rechte erweitert, darf nicht aus einer Datei kommen, die ein fremdes Repository mitbringt. Deshalb greifen auch allow-Regeln aus dem Projekt erst nach dem Workspace-Trust-Dialog — deny und ask sofort.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Der Bestand

Nach Zweck statt alphabetisch

Modell, Kontext, Skills

Die Gruppen, die im Alltag am häufigsten angefasst werden.

  1. Modell und Aufwand: model, fallbackModel, availableModels, effortLevel, alwaysThinkingEnabled, fastMode
  2. Kontext und Gedächtnis: autoCompactEnabled, autoMemoryEnabled, claudeMdExcludes, includeGitInstructions, outputStyle
  3. Skills: skillOverrides, skillListingBudgetFraction, disableBundledSkills, disableSkillShellExecution
# Zwei Schluessel mit Ueberraschung

autoMemoryEnabled: false
# macht auch das memory-Feld eines
# Subagenten wirkungslos

includeGitInstructions: false
# entfernt die eingebauten Commit-
# Anweisungen UND den Git-Status
# aus dem System-Prompt

skillListingBudgetFraction: 0.01
# 1 Prozent des Kontextfensters
# fuer die Skill-Liste
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Anschlüsse, Automatik, Umgebung

Der Rest, gruppiert — zum Fotografieren, nicht zum Vorlesen.

  1. MCP: enableAllProjectMcpServers, enabledMcpjsonServers, disabledMcpjsonServers, disableClaudeAiConnectors
  2. Hooks: hooks, disableAllHooks, allowedHttpHookUrls, statusLine
  3. Plugins: enabledPlugins, pluginConfigs, extraKnownMarketplaces
  4. Wartung: cleanupPeriodDays, autoUpdatesChannel, minimumVersion
  5. Oberfläche: theme, editorMode, language, verbose, axScreenReader
disableAllHooks schaltet auch die eigene Statuszeile ab — die läuft technisch als Hook. Und cleanupPeriodDays steuert nicht nur alte Sitzungen, sondern auch das Aufräumen verwaister Arbeitskopien.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Settings gegen Umgebungsvariablen

Manches gibt es nur als Variable, und in einem Fall gewinnt die Variable gegen den Settings-Schlüssel.

SettingVariableVerhältnis
includeGitInstructionsCLAUDE_CODE_DISABLE_GIT_INSTRUCTIONSVariable hat Vorrang
autoCompactEnabledDISABLE_AUTO_COMPACTVariable schaltet ab
autoMemoryEnabledCLAUDE_CODE_DISABLE_AUTO_MEMORYVariable schaltet ab
effortLevelCLAUDE_CODE_EFFORT_LEVEL, --effortüberschreiben für eine Sitzung
—CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS und Verwandtenur als Variable
Variablen setzt man im env-Block der Settings — mit einer Einschränkung: NO_COLOR und FORCE_COLOR erreichen von dort nur Unterprozesse. Für die eigene Oberfläche müssen sie vor dem Start in der Shell stehen.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Nachsehen statt raten

Was wirklich gilt

Vier Befehle statt Vermutungen

Bei Konfiguration ist Raten teuer. Für jede Frage gibt es einen Befehl, der sie beantwortet.

  1. /doctor — ungültige Einträge mit Quelldatei und Feld, Namenskollisionen bei Subagenten, Schätzung der Skill-Listengröße.
  2. /status — warnt, wenn eine Settings-Datei nicht lesbar ist und deshalb der Aufräumlauf pausiert.
  3. /permissions — alle Regeln und die Datei, aus der jede kommt.
  4. claude auto-mode config — die wirksame Klassifizierer-Konfiguration, nicht-interaktiv.
/permissions ist der wichtigste davon: Es zeigt nicht nur, welche Regel gilt, sondern woher sie kommt. Damit ist die Frage „wer hat das gesetzt?" in zwei Sekunden beantwortet statt in zehn Minuten Dateisuche.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Erweiterung 4 in fünf Sätzen

Was von diesem Deck hängenbleiben soll.

  1. Project schlägt User. Ein persönliches Abschalten gehört in settings.local.json, nicht in die User-Settings.
  2. Permission-Regeln überschreiben nicht, sie addieren sich. Ein deny auf irgendeiner Ebene gewinnt.
  3. Die meisten Änderungen wirken sofort — nur model und outputStyle brauchen einen Neustart.
  4. Ein Syntaxfehler verwirft die ganze eigene Datei. In einer Firmenrichtlinie nur den einzelnen Eintrag.
  5. Was Rechte erweitert, wird aus Projektdateien nicht gelesen — und /permissions sagt euch, woher jede Regel kommt.

Glossar Glossar

Scope (Konfigurationsebene) Eine der vier Ebenen, auf denen Konfiguration liegen kann: Managed, User, Project, Local. Bei gleichem Schlüssel gewinnt die höhere; Permission-Regeln werden stattdessen zusammengeführt.
Managed Settings Von der Organisation ausgerollte Konfiguration, die keine andere Ebene überschreiben kann. Fehlertolerant: ein ungültiger Eintrag wird einzeln entfernt, der Rest gilt weiter.
MCP (Model Context Protocol) Offenes Protokoll, über das Claude Code fremde Systeme als Werkzeuge anbindet. Seine Konfiguration folgt einer eigenen Aufteilung: ~/.claude.json und .mcp.json statt der Settings-Dateien.
Auto-Memory Von Claude Code selbst gepflegtes Gedächtnis zwischen Sitzungen. Abschaltbar mit autoMemoryEnabled — und dann wirkt auch das memory-Feld eines Subagenten nicht mehr.

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Erweiterung 4 · Konfiguration · v0.10.1