CGS IT Solutions GmbH — Claude Code Training · Modul 10b · Konfiguration im Detail · v2.0.1

Modul 10b

Konfiguration im Detail

Vertiefung zu Modul 10 · Ebenen, Wirksamkeit, Bestand

Inhalt

1Die Konfigurationsebenen — 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

Vorrang, Wirkung, Bestand

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

  1. Fünf Ebenen mit fester Reihenfolge — Listen wie die Permission-Regeln werden dabei zusammengeführt statt überschrieben.
  2. Die meisten Änderungen wirken sofort, Modell und Effort erst in der nächsten Session.
  3. Ungültiges JSON legt die eigene Datei ganz still. Eine Managed-Datei ohne gültiges JSON hält Claude Code an; dort fallen nur einzelne falsche Einträge weg.
  4. Über 170 Schlüssel sind alphabetisch unbrauchbar. Nach Zweck gruppiert sind sie zu überblicken.
Dieses Deck nennt keine vollständige Schlüsselliste. Die Liste ändert sich schneller als jede Folie — die Quelle ist docs/en/settings-reference, hier stehen die Gruppen und die Fallen.
checked am 2026-09-26 gegen docs/en/settings-reference

Die Konfigurationsebenen

Und wer wen überstimmt

Welche Settings-Datei gewinnt

Bei gleichem Schlüssel gewinnt die höhere Ebene.
Managed Settings gewinnen gegen alles — auch gegen --settings und Startflags.

gewinnt gegen alles
Managedmanaged-settings.json, MDM, Server
geteilt — von der IT
beim Start
Kommandozeile--settings, Flags
nur diese Session
nur bei euch
Local.claude/settings.local.json
nicht eingecheckt
im Repository
Project.claude/settings.json
geteilt — eingecheckt
euer Rechner
User~/.claude/settings.json
nicht geteilt
oben gewinnt bei gleichem Schlüsselnicht überschreibbar
Project schlägt User: Ein persönliches Abschalten in den User-Settings verpufft, wenn das Projekt den Schlüssel setzt.
Der wirksame Ort für die eigene Ausnahme ist settings.local.json.
checked am 2026-09-26 gegen docs/en/settings

Ablageorte je Konfigurationsebene

Nicht jede Konfigurationsart folgt derselben Aufteilung.
Vor allem MCP (Model Context Protocol) und CLAUDE.md liegen anderswo.

Feature User Project Local
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.
checked am 2026-09-26 gegen docs/en/claude-directory

Listen addieren sich, Einzelwerte überschreiben

Setzen mehrere Dateien denselben Listenschlüssel, führt Claude Code die Listen zusammen.
Das wichtigste Beispiel sind die Permission-Regeln.

  1. Ein deny gilt, egal auf welcher Ebene — keine andere hebt es auf, auch keine höhere.
  2. „Yes, and don't ask again" schreibt ein allow in settings.local.json. Gegen ein ask aus Projekt oder Managed hilft es nicht.
  3. Ein Managed-deny lässt sich nicht mit --allowedTools aufheben. --disallowedTools darf weiter einschränken.
  4. Modell-Listen folgen eigenen Regeln: fallbackModel kommt ganz aus der höchsten Datei, eine Managed-availableModels gilt unverändert.
User: deny
Project: allow
Local: allow
zusammengeführtnicht überschrieben
verweigert
ein deny genügt
jede Ebene liefert Regeln, keine ersetzt eine andere
checked am 2026-09-26 gegen docs/en/settings

Wann etwas wirkt

Sofort, in der nächsten Session — oder gar nicht

Welche Änderung sofort wirkt

Claude Code beobachtet die Settings-Dateien und lädt sie bei jeder Änderung neu.
Die meisten Schlüssel wirken also ohne Neustart.

  1. Sofort: permissions, hooks, Zugangsdaten-Helfer wie apiKeyHelper — für User, Project, Local und Managed.
  2. Eine neue Datei im .claude/-Ordner lädt Claude Code noch in der laufenden Session.
  3. Der ConfigChange-Hook läuft bei jeder erkannten Dateiänderung — nicht bei Managed Settings aus MDM oder Konsole.
  4. Erst in der nächsten Session: model, effortLevel, modelSettings. Mittendrin wechseln /model und /effort.
Eine Hook- oder Regeländerung lässt sich im laufenden Gespräch ausprobieren.
Für Modell und Effort sind /model und /effort der kurze Weg.
checked am 2026-09-26 gegen docs/en/settings

Kaputte Settings-Datei: was ausfällt

Wie viel eine fehlerhafte Datei kostet, hängt von der Ebene ab.
Eine eigene Datei fällt still aus, eine Firmenrichtlinie behält ihre gültigen Einträge.

Eigene Dateien: User, Project, Local

  • ungültiges JSON oder ein abgelehnter Wert: die ganze Datei fällt aus
  • ein //-Kommentar oder ein Komma zu viel genügt
  • interaktiv fragt ein Dialog: reparieren, beenden oder ohne die Datei weiter — ein -p-Lauf fragt nicht
  • ein einzelner falscher Eintrag, etwa eine kaputte Regel: nur dieser fällt weg

Managed: der Rest gilt weiter

  • ungültige Einträge und Schlüssel werden einzeln entfernt
  • Sicherheitsschlüssel scheitern nach zu: eine ungültige allowedMcpServers gilt als leere Allowlist
  • ist die Datei kein JSON, startet Claude Code gar nicht
2026-08-05 — eigene ~/.claude/settings.json Kommentare in der Datei: Rund 220 Regeln, Statuszeile und Plugins waren still weg. Drei Tests danach maßen eine Datei, die gar nicht geladen war. Nach jeder Änderung jq -e . oder claude doctor — nicht erst, wenn etwas seltsam ist.
checked am 2026-09-26 gegen docs/en/settings + managed-settings

Schlüssel, die ein Repository nicht setzen kann

Einige Schlüssel liest Claude Code aus dem geteilten Projekt bewusst nicht.
Ein geklontes Repository soll sich keine Rechte selbst schreiben.

  1. autoMode — nur aus User, --settings und Managed.
  2. defaultMode: "auto" und "bypassPermissions" — aus Project und Local ignoriert.
  3. skipDangerousModePermissionPrompt — nicht aus dem geteilten Projekt: ein fremdes Repository kann die Warnung nicht wegklicken.
  4. pluginConfigs — nur User und Managed, weil die Werte in Hook- und MCP-Konfigurationen landen.
  5. Warten auf die Workspace-Trust-Abfrage: allow-Regeln, extraKnownMarketplaces, die meisten env-Werte. deny und ask gelten sofort.
geklontes Repository bringt mit:
autoMode · defaultMode: auto
skipDangerousModePermissionPrompt · pluginConfigs
aus dem geteilten Projekt nicht gelesen
wirksam nur aus
User · --settings · Managed
was Rechte erweitert, kommt nie aus dem Repository
checked am 2026-09-26 gegen docs/en/settings-reference

Der Bestand

Nach Zweck statt alphabetisch

Häufig angefasst: 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
# Drei Schluessel mit Ueberraschung

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

includeGitInstructions: false
# entfernt die eingebauten Commit-
# Anweisungen UND den Git-Status

skillListingBudgetFraction: 0.01
# 1 Prozent des Kontextfensters
# fuer die Skill-Liste (Standard)
checked am 2026-09-26 gegen docs/en/settings-reference

Weitere Gruppen: MCP, Hooks, Plugins, Wartung

Die übrigen Gruppen mit ihren wichtigsten Schlüsseln.

  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 und die eigenen Dateivorschläge ab.
cleanupPeriodDays steuert auch das Aufräumen verwaister Worktrees.
checked am 2026-09-26 gegen docs/en/settings-reference

Umgebungsvariable gegen Settings-Schlüssel

Umgebungsvariablen sind keine Ebene im Stapel.
Welche Seite gewinnt, ist je Paar festgelegt.

Setting Variable Verhältnis
modelANTHROPIC_MODEL, --modelVariable vor jeder Datei, Flag vor beiden
includeGitInstructionsCLAUDE_CODE_DISABLE_GIT_INSTRUCTIONSVariable hat Vorrang
autoCompactEnabledDISABLE_AUTO_COMPACTwer abschaltet, gewinnt
autoMemoryEnabledCLAUDE_CODE_DISABLE_AUTO_MEMORYVariable gewinnt in beide Richtungen
effortLevel--effort, CLAUDE_CODE_EFFORT_LEVELVariable vor Flag vor Schlüssel
—CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS und Verwandtenur als Variable
Variablen für alle setzt man im env-Block der Settings.
NO_COLOR und FORCE_COLOR erreichen von dort nur Child-Processes — für die eigene Oberfläche gehören sie vor den Start in die Shell.
checked am 2026-09-26 gegen docs/en/env-vars

Nachsehen statt raten

Was wirklich gilt

Welche Einstellung gilt: die Prüfbefehle

Für jede Frage zur Konfiguration gibt es einen Befehl, der sie beantwortet.

  1. /status — Zeile Setting sources: welche Dateien geladen sind und ob Managed Settings greifen. Nicht: welcher Schlüssel woher kommt.
  2. claude doctor in der Shell — verworfene Einträge mit Quelle und Feld, ohne Session. /doctor schlägt zusätzlich Korrekturen vor.
  3. /permissions — alle Regeln nach Scope, zum Ansehen und Ändern.
  4. /config — eine kurze Liste persönlicher Optionen, keine Ansicht der settings.json.
  5. claude auto-mode config — die wirksame Klassifizierer-Konfiguration als JSON.
/permissions zeigt jede Regel zusammen mit dem Scope, aus dem sie stammt — die Antwort auf „wer hat das gesetzt?".
checked am 2026-09-26 gegen docs/en/debug-your-config

Modul 10b 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 — Modell und Effort erst in der nächsten Session.
  4. Ungültiges JSON legt die ganze eigene Datei still. In einer Firmenrichtlinie fallen nur falsche Einträge weg; ist sie kein JSON, startet Claude Code nicht.
  5. Was Rechte erweitert, liest Claude Code nicht aus dem geteilten Projekt — und /permissions zeigt, woher jede Regel kommt.

Glossar Glossar

Scope (Konfigurationsebene) Eine der Ebenen, auf denen Konfiguration liegen kann: Managed, Kommandozeile, Local, Project, User. Bei gleichem Schlüssel gewinnt die höhere; Listen wie die Permission-Regeln werden stattdessen zusammengeführt.
Managed Settings Von der Organisation ausgerollte Konfiguration, die keine andere Ebene überschreiben kann. Ein ungültiger Eintrag fällt einzeln weg, der Rest gilt weiter.
MCP (Model Context Protocol) Offenes Protokoll, über das Claude Code fremde Systeme als Werkzeuge anbindet. Seine Konfiguration liegt in ~/.claude.json und .mcp.json, nicht in den Settings-Dateien.
Auto-Memory Von Claude Code selbst gepflegtes Gedächtnis zwischen Sessions. Abschaltbar mit autoMemoryEnabled — dann wirkt auch das memory-Feld eines Subagenten nicht mehr.
Workspace-Trust-Abfrage Der Dialog, mit dem man einem Ordner vertraut. Erst danach wirken allow-Regeln und Marketplaces aus dessen .claude/settings.json.
Worktree Ein zweites Arbeitsverzeichnis desselben Git-Repositorys auf einem anderen Branch. Claude Code legt Worktrees für parallele Sessions und Subagenten an.

© 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 · Modul 10b · Konfiguration · v2.0.1