Alle Artikel

Blog

Claude Code im Unternehmen ausrollen: managed-settings.json per Intune verteilen

Managed Settings für Claude Code per Intune verteilen: Registry oder Datei, Präzedenz ohne Merge, Login-Erzwingung und eine Beispiel-managed-settings.json.

JL.Digital GmbH
Claude CodeIntuneEndpoint ManagementKI

Sobald mehr als eine Handvoll Entwickler Claude Code einsetzen, reicht „jeder konfiguriert sich selbst” nicht mehr. Welche Tools darf Claude ohne Rückfrage ausführen, welche MCP-Server sind vertrauenswürdig, mit welchem Login muss sich jeder anmelden, welche Telemetrie verlässt das Gerät - das sind keine Entwicklerentscheidungen mehr, sobald ein Sicherheitsteam oder ein Betriebsrat mitredet. Für Microsoft-Umgebungen läuft die Antwort auf einen Weg hinaus: Claude Code per Intune ausrollen und die Konfiguration als Managed Settings verteilen - als managed-settings.json oder als Registry-Wert, den kein Entwickler auf dem eigenen Gerät überschreiben kann.

Anthropic dokumentiert für genau diesen Zweck sogenannte Managed Settings - Konfigurationsebenen, die kein Entwickler auf dem eigenen Gerät überschreiben kann. Was in der offiziellen Dokumentation fehlt, ist eine Anleitung, wie man diese Managed Settings tatsächlich über Intune ausrollt. Anthropic nennt Intune an mehreren Stellen als Stichwort und verlinkt aus der Settings-Doku auf ein Beispielverzeichnis mit Starter-Vorlagen für Jamf, Iru (Kandji), Intune und Group Policy - darunter ein PowerShell-Skript, ein ADMX/ADML-Paar und eine macOS-Plist. Anthropic kennzeichnet diese Vorlagen allerdings selbst als „community-maintained templates which may be unsupported or incorrect”; eine Schritt-für-Schritt-Anleitung für den Intune-Rollout ersetzen sie nicht. Genau diese Lücke schließt dieser Artikel: mit den belegten Fakten aus der Claude-Code-Dokumentation und den dazu passenden, über Microsoft Learn dokumentierten Intune-Mechanismen.

Ein Hinweis vorweg: Alle Versions-, Pfad- und Statusangaben in diesem Artikel geben den Dokumentationsstand August 2026 wieder. Claude Code erscheint mehrmals wöchentlich, und viele der hier genannten Verhaltensweisen sind ausdrücklich an Mindestversionen gebunden - prüfen Sie versionsgebundene Aussagen vor einem Rollout gegen die dann aktuelle Dokumentation.

Was Managed Settings in Claude Code erzwingen können

Managed Settings sind eine von vier Konfigurationsebenen in Claude Code (Managed, User, Project, Local) - wie diese vier zusammenspielen und wofür die anderen drei jenseits von Managed gedacht sind, ordnet der Grundlagenartikel zum Claude-Code-Harness ein. Managed ist die einzige Ebene, die keine andere Ebene überschreiben kann, abgesehen von einigen wenigen dokumentierten Ausnahmen, bei denen ein strengerer Wert aus einer niedrigeren Ebene gewinnt. Darüber lässt sich unter anderem steuern:

  • Permissions und Sandboxing: welche Tools und Befehle erlaubt, verboten oder nachfragepflichtig sind (permissions.allow/deny/ask), ob der Start-Permission-Mode fest vorgegeben ist, ob Sandboxing verpflichtend ist und welche Netzwerk-Domains oder Lesepfade erlaubt sind.
  • MCP- und Plugin-Kontrolle: welche MCP-Server erlaubt sind (allowedMcpServers/deniedMcpServers), ob ausschließlich die zentral gepflegte Allowlist gilt (allowManagedMcpServersOnly - Allowlists aus User-, Projekt- und Local-Settings werden dann ignoriert, Denylists mergen weiterhin aus allen Quellen), und welche Plugin-Marketplaces überhaupt bekannt sein dürfen.
  • Login-Erzwingung: dass sich Claude Code nur mit einer bestimmten Methode (forceLoginMethod) und nur gegen eine bestimmte Organisation (forceLoginOrgUUID) anmelden lässt.
  • Hooks und Anpassung: dass nur zentral verteilte Hooks laufen (allowManagedHooksOnly - wie Hooks Regeln tatsächlich erzwingen, statt sie nur zu formulieren, erklärt ein eigener Artikel), welche HTTP-Ziele Hooks ansprechen dürfen, oder ob Skills/Hooks überhaupt nur über Plugins kommen dürfen (strictPluginOnlyCustomization).
  • Versionen und Modelle: eine Mindestversion (minimumVersion) oder ein erlaubter Versionsbereich, sowie eine Liste erlaubter Modelle (availableModels).
  • Telemetrie: über den env-Block lassen sich OpenTelemetry-Ziele fest vorgeben (dazu mehr weiter unten).

Ein Teil dieser Schlüssel wirkt ausschließlich aus Managed Settings - in User- oder Projekt-Settings gesetzt, haben sie schlicht keine Wirkung. Genau deshalb lohnt sich der Aufwand, sie tatsächlich zentral zuzustellen, statt sie nur als Empfehlung in ein Onboarding-Dokument zu schreiben.

Die vier Zustellwege für Managed Settings - und die Präzedenz-Falle

„Managed Settings” ist keine einzelne Datei, sondern eine Kategorie mit vier möglichen Zustellwegen, die in dieser Reihenfolge geprüft werden:

  1. Server-managed - über die claude.ai Admin-Konsole oder einen self-hosted Claude-apps-Gateway. Höchste Priorität.
  2. Plist / Registry-Policy - macOS: com.anthropic.claudecode-Plist, Windows: HKLM\SOFTWARE\Policies\ClaudeCode.
  3. File-based managed - die managed-settings.json am jeweiligen Systempfad.
  4. Windows User-Registry - HKCU\SOFTWARE\Policies\ClaudeCode, niedrigste Priorität, nur unter Windows.

Die Falle: Claude Code mergt diese Quellen nicht. Es nimmt die erste Quelle in dieser Reihenfolge, die eine nicht-leere Konfiguration liefert - und diese Quelle gilt dann komplett. Wer also über server-managed nur die Login-Erzwingung setzt und sich darauf verlässt, dass die Permission-Regeln aus der lokal verteilten managed-settings.json trotzdem greifen, irrt: Sind beide Quellen aktiv, gewinnt ausschließlich server-managed, und die Permission-Regeln aus der Datei werden schlicht ignoriert.

Zwei dokumentierte Ausnahmen von dieser Regel:

  • Cross-source lock keys (etwa Sandbox-Allowlist-Locks) gelten, sobald irgendeine admin-kontrollierte Quelle sie setzt - mit Ausnahme der user-schreibbaren HKCU-Ebene.
  • Der env-Block mergt pro Schlüssel über admin-kontrollierte Quellen hinweg (seit v2.1.223). Innerhalb dieses Merges folgt die „Telemetry-Unit” (OTEL_EXPORTER_OTLP_* und verwandte Variablen) als Einheit der höchsten Quelle; Routing-Variablen, die eine Quelle mit einem Credential-Key wie apiKeyHelper oder otelHeadersHelper paart, steuert diese Quelle nur bei, wenn sie die Gewinner-Quelle ist. CLAUDE_CODE_DISABLE_ADMIN_ENV_UNION=1 stellt das alte Winner-only-Verhalten wieder her, falls das gewünscht ist.

Ein Missverständnis lohnt sich hier auszuräumen, weil zwei verschiedene Mechaniken leicht ineinanderlaufen. Die eben genannten Ausnahmen betreffen das Verhältnis der Managed-Quellen untereinander. Davon zu unterscheiden sind die Ausnahmen von der Managed-Präzedenz aus dem vorigen Abschnitt: Sie umfassen genau vier sicherheitsrelevante Keys und ausdrücklich keine Permission-Regeln - für die gilt unverändert „no other level, including command line arguments, can override a managed permission rule”. Und wieder etwas anderes ist die Merge-Sonderregel für Permission-Regeln über die Scopes hinweg: Array-Werte wie permissions.allow und permissions.deny werden aus Managed-, User-, Projekt- und Local-Settings zusammengeführt, und ein deny auf irgendeiner Ebene blockt. Entwickler können eine zentrale Liste also erweitern, aber nichts daraus entfernen. Über die vier Zustellwege hinweg mergen Permission-Regeln dagegen nicht.

Für den Praxisfall heißt das: Wer server-managed und endpoint-managed (Datei oder Registry) gleichzeitig nutzt, muss sich bewusst entscheiden, wo die eigentliche Policy liegt - und darf nicht davon ausgehen, dass sich beide Quellen sinnvoll ergänzen.

Wann Intune der einzige Weg bleibt: Foundry, Bedrock, Vertex AI

Der wichtigste Grund, warum dieser Artikel überhaupt nötig ist: Server-managed Settings erreichen nicht jede Claude-Code-Installation. Anthropic dokumentiert ausdrücklich, dass der Fetch nicht stattfindet bei Amazon Bedrock, Google Clouds Agent Platform, Microsoft Foundry, Claude Platform on AWS oder einer eigenen ANTHROPIC_BASE_URL bzw. einem Third-Party-LLM-Gateway. Auch Keys aus einem apiKeyHelper-Skript lösen den Fetch nicht aus.

Für Organisationen, die Claude Code über Microsoft Foundry oder einen anderen selbst gehosteten Endpunkt betreiben - also ein klassisches Azure-Kunden-Szenario - , ist server-managed damit faktisch keine Option. Das dokumentierte Äquivalent für diese Fälle ist ein self-hosted Claude-apps-Gateway. Wer diesen nicht betreiben will oder kann, bleibt mit einer einzigen zentralen Steuerungsmöglichkeit übrig: Managed Settings über MDM - sprich Registry-Policy oder Datei, verteilt per Intune.

Damit dreht sich auch Anthropics eigene Empfehlung nicht zufällig in diese Richtung: Wo bereits ein Endpoint-Management-System vorhanden ist, empfiehlt Anthropic ausdrücklich endpoint-managed statt server-managed - die Datei lässt sich auf Betriebssystemebene vor Änderungen schützen, was stärkere Garantien bietet. Server-managed bleibt sinnvoll für Organisationen ohne MDM oder für nicht verwaltete Geräte. Ein Punkt zur Vollständigkeit: Wer zusätzlich Claude Code on the web nutzt, erreicht diese Cloud-Sessions mit endpoint-managed Settings nicht - dafür ist zusätzlich server-managed nötig. Auch managed-mcp.json, die Datei für exklusive MCP-Server-Kontrolle, lässt sich grundsätzlich nicht über server-managed verteilen - Anthropic nennt hier in der eigenen Doku ausdrücklich „Group Policy or Intune on Windows” als Zustellweg.

managed-settings.json unter Windows und macOS verteilen

Bevor es an die Intune-Mechanik geht, eine Klarstellung: Anthropic liefert keine Schritt-für-Schritt-Anleitung für Intune. Die Settings-Doku nennt „Deploy via Group Policy or Intune” für Windows und „Jamf, Iru (Kandji), or similar MDM tools” für macOS - beides generische Hinweise. Dazu kommen die oben erwähnten Starter-Vorlagen im MDM-Beispielverzeichnis des Claude-Code-Repositorys, die Anthropic selbst als community-maintained und möglicherweise fehlerhaft kennzeichnet. Was folgt, kombiniert diese Angaben mit dokumentierten Intune-Mechanismen aus Microsoft Learn.

Windows: Registry-Pfad statt managed-settings.json

Auf Windows gibt es zwei Zustellwege, aber einen klaren Favoriten. Die Registry-Policy liegt unter HKLM\SOFTWARE\Policies\ClaudeCode, im Value Settings, vom Typ REG_SZ oder REG_EXPAND_SZ, mit dem kompletten JSON der Settings als Wert. Ein einzelner Registry-Value statt einer Datei im Programmverzeichnis - das lässt sich über Intune deutlich sauberer ausrollen als eine Datei.

Ein Stolperstein, der in älteren Anleitungen noch auftaucht: Der Pfad C:\ProgramData\ClaudeCode\managed-settings.json wird seit Version 2.1.75 nicht mehr unterstützt. Der korrekte Dateipfad - falls die File-based-Variante statt der Registry genutzt wird - ist C:\Program Files\ClaudeCode\managed-settings.json.

Für die Intune-Verteilung sind mehrere Wege über Microsoft Learn belegt. Die beiden naheliegendsten zuerst:

  • PowerShell-Skript über die Intune Management Extension (IME): zugewiesen unter Devices > Scripts and remediations > Platform scripts > Add > Windows 10 and later. Voraussetzungen sind eine unterstützte Windows-Edition (kein S-Mode), Microsoft-Entra-Join oder Hybrid-Join - Geräte, die in Microsoft Entra ID lediglich registriert sind, erhalten die Skripte laut Microsoft nicht - sowie IME ab Version 1.58.103.0. Das Skript läuft nach Zuweisung einmal, bei Fehlschlag mit bis zu drei Retries über die folgenden IME-Check-ins (Check-in-Takt: alle acht Stunden, Timeout 30 Minuten). Logs liegen unter C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
  • Win32-App (.intunewin): paketiert mit dem Microsoft Win32 Content Prep Tool. Der Vorteil gegenüber dem reinen Skript: Win32-Apps unterstützen Detection Rules - der Registry-Value lässt sich als Soll-Zustand definieren, womit man echtes Compliance-Reporting statt eines „Skript lief durch” bekommt. Die Installation muss silent laufen; ein PowerShell-Skript kann statt einer Command Line direkt als Installer hochgeladen werden.

Für ein einmaliges „Wert setzen” reicht das PowerShell-Skript. Wer Reporting und einen definierten Soll-Zustand will, sollte die Win32-App mit Detection Rule vorziehen. Eine dritte, wiederkehrende Variante sind Remediations (von Microsoft inzwischen so genannt, früher „Proactive Remediations”): ein Detection- und ein Remediation-Skript, wobei das Remediation-Skript nur läuft, wenn das Detection-Skript mit exit 1 einen Drift meldet. Zu finden unter Devices > Manage devices > Scripts and remediations. Bevor Sie damit planen, drei Punkte aus der Microsoft-Doku: Remediations setzen zusätzliche Lizenzen voraus - Windows Enterprise E3 oder E5 (enthalten in Microsoft 365 F3, E3 oder E5), Windows Education A3 oder A5 (enthalten in Microsoft 365 A3 oder A5) oder Windows Virtual Desktop Access (VDA) pro Nutzer. Die Geräte müssen Microsoft Entra joined oder hybrid joined sein und entweder als MDM-verwaltetes Windows Enterprise, Professional oder Education laufen oder co-managed sein. Und als Zeitplan stehen genau drei Optionen zur Verfügung: Once, Hourly (konfigurierbares Intervall, kleiner als 24 Stunden) und Daily - standardmäßig in der lokalen Zeit des Geräts, auf Wunsch in UTC. Zugewiesen wird an Gerätegruppen; Microsoft rät ausdrücklich davon ab, Nutzer- und Gerätegruppen über Include- und Exclude-Zuweisungen zu mischen.

Einen deklarativen Weg ohne eigenes Skript gibt es ebenfalls. Anthropic legt in seinem MDM-Beispielverzeichnis eine ADMX/ADML-Vorlage ab (ClaudeCode.admx plus en-US/ClaudeCode.adml), die HKLM\SOFTWARE\Policies\ClaudeCode\Settings als REG_SZ mit einzeiligem JSON schreibt und ausdrücklich für „Group Policy or Intune Import ADMX” gedacht ist. Microsoft dokumentiert den Import benutzerdefinierter ADMX-Dateien unter Devices > Manage devices > Configuration > Import ADMX; das Konfigurationsprofil entsteht danach über Templates > Imported Administrative templates (Preview). Zwei Einschränkungen gehören zur ehrlichen Einordnung: Der ADMX-Import ist bei Microsoft als Public Preview gekennzeichnet und begrenzt (maximal 20 ADMX-Dateien à 1 MB, nur en-us-ADML, Rolle „Policy and Profile Manager”), und Anthropic bezeichnet die Vorlagen selbst als community-maintained und möglicherweise fehlerhaft. Der Intune Settings Catalog dagegen bringt für diesen Registry-Pfad keine eingebauten Settings mit - über ihn allein lässt sich die Policy nicht setzen.

macOS: Datei oder Preference-Profil

Auf macOS liegt die File-based-Variante unter /Library/Application Support/ClaudeCode/managed-settings.json. Parallel dazu unterstützt Claude Code Managed Preferences über die Preference-Domain com.anthropic.claudecode - die Top-Level-Keys spiegeln dabei managed-settings.json, verschachtelte Settings werden zu Dictionaries, Arrays zu Plist-Arrays.

Für Intune gibt es dafür zwei Wege:

  • Konfigurationsprofil „Preference file” (Devices > Manage devices > Configuration > Create > New policy > Platform: macOS > Profile type: Templates > Preference file): Als Preference domain name trägt man die Bundle-ID der App ein, hier also com.anthropic.claudecode, dazu eine .plist- oder .xml-Datei. Microsofts Formatvorgabe dafür ist eng und wörtlich dokumentiert: „The file should only have key value pairs, and shouldn’t be wrapped in <dict>, <plist>, or <xml> tags.” Zwei weitere Hinweise aus derselben Doku, die man leicht überliest: Intune validiert den Inhalt der Property-List-Datei nicht, und die Datei muss Device-Channel-Settings adressieren, keine User-Channel-Settings. **Belegt ist damit allerdings ausschließlich die Microsoft-Formatvorgabe. Nicht belegt - und im Rahmen dieses Artikels auch nicht praktisch getestet
  • ist, wie ein so „entpacktes” Preference-File für com.anthropic.claudecode tatsächlich ankommt.** Offen bleibt insbesondere, ob verschachtelte Strukturen korrekt landen: Anthropic verlangt, dass verschachtelte Settings als Dictionaries und Arrays als Plist-Arrays abgebildet werden - also etwa permissions.deny als <array> und sandbox.network als <dict> - , während Microsofts Beispiel nur flache Key-Value-Paare zeigt. Vor einem Produktiv-Rollout gehört das Profil deshalb auf ein Test-Gerät im eigenen Tenant und anschließend unter /status überprüft; erwartete Ausgabe ist Enterprise managed settings (plist). Alternativ steht ein Custom-Profil (Templates > Custom) zur Verfügung, das eine vollständige .mobileconfig- oder .xml-Datei samt <dict>/<plist>-Wrapper aufnimmt (maximal knapp 1 MB; der Deployment channel wird beim Anlegen gewählt und ist danach nicht mehr änderbar). Anthropic legt für genau diesen Fall eine fertige com.anthropic.claudecode.mobileconfig im MDM-Beispielverzeichnis ab - mit dem Hinweis, die Platzhalter PayloadUUID und PayloadOrganization durch eigene Werte zu ersetzen.
  • macOS Shell-Skript (Devices > By platform > macOS > Manage devices > Scripts > Add) für die Datei-Variante: Voraussetzung ist macOS 12.0 oder neuer, eine direkte Internetverbindung (Proxy wird nicht unterstützt) sowie der installierte Microsoft Intune management agent. Für Systempfade muss „Run script as signed-in user” auf „No” stehen; Skripte über 60 Minuten werden als fehlgeschlagen gemeldet.

Das Konfigurationsprofil ist der sauberere Weg: Es liegt in der Zustellpriorität über der Datei, ist MDM-verwaltet und wird beim Entfernen des Profils automatisch zurückgenommen. Das Shell-Skript bleibt die Fallback-Option - es hinterlässt eine Datei, die man beim Offboarding aktiv wieder entfernen muss.

Grenzen: Managed Settings sind eine Client-Kontrolle, keine Sicherheitsgrenze

So durchdacht das Zustellsystem ist - Anthropic macht selbst keinen Hehl daraus, wo die Grenze liegt: Server-managed Settings seien „a client-side control, not a security boundary”. Auf einem nicht MDM-verwalteten Gerät braucht ein Nutzer weder Admin-Rechte noch sudo, um sie zu umgehen. Ein modifizierter Client oder eine ältere Client-Version hebelt jede client-seitige Kontrolle aus.

Genau hier liegt der praktische Wert von endpoint-managed Settings über Intune: Auf einem MDM-verwalteten Gerät lässt sich die Registry oder die Konfigurationsdatei auf Betriebssystemebene vor Änderung durch den angemeldeten Nutzer schützen - eine Garantie, die eine reine Server-Konfiguration nicht bieten kann. Wer die Frage „Ist das eine Security-Boundary?” ernst nimmt, sollte Claude Code deshalb als einen weiteren Baustein in einem Zero-Trust-Modell für KI-Agenten betrachten, nicht als abschließende Kontrolle für sich allein - Grundsätze dazu haben wir im Artikel zu OpenClaw und Zero Trust für AI-Agents eingeordnet.

Login-Erzwingung: forceLoginMethod und forceLoginOrgUUID zusammen setzen

Ein Detail, das in keiner Kurzanleitung auftaucht, aber Freigabe-Prüfungen regelmäßig zu Fall bringt: forceLoginOrgUUID (Organisations-ID aus den Admin-Settings) und forceLoginMethod (mit den dokumentierten Werten claudeai, console und gateway) gehören zu keiner der Merge-Ausnahmen aus dem vorherigen Abschnitt. Wer nur server-managed konfiguriert, aber Geräte im Feld hat, die aus irgendeinem Grund keine server-managed Verbindung bekommen (etwa weil sie über Foundry laufen, siehe oben), hat auf diesen Geräten überhaupt keine Login-Erzwingung aktiv - die Datei- oder Registry-Ebene wurde ja nie gesetzt.

Die Konsequenz: Beide Keys müssen in server-managed und in endpoint-managed gesetzt werden, wenn beide Wege im Einsatz sind. Das ist etwas redundante Pflege, aber die einzige Konfiguration, die auf jedem Zustellweg zuverlässig greift. Ergänzend gilt: forceLoginOrgUUID wird nur bei claude.ai-Logins über Terminal, VS-Code-Extension und Agent SDK geprüft

  • bei Console-Logins erfolgt keine echte Organisations-Verifikation, nur eine Vorauswahl auf der Sign-in-Seite.

OpenTelemetry für Claude Code zentral vorgeben

Wer Claude Code unternehmensweit ausrollt, will in der Regel auch sehen, was damit passiert - ohne dabei automatisch Prompt-Inhalte zu protokollieren. Claude Code unterstützt dafür OpenTelemetry: Metriken und Events gelten als GA, verteiltes Tracing (Spans) ist Beta und muss über CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 aktiviert werden.

Die zentrale Aktivierung läuft über den env-Block der Managed Settings, mit mindestens CLAUDE_CODE_ENABLE_TELEMETRY=1, einem OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER, dem gewünschten OTEL_EXPORTER_OTLP_PROTOCOL und dem Ziel-Endpoint (OTEL_EXPORTER_OTLP_ENDPOINT). Erfasst werden unter anderem Sitzungen, Zeilen geänderten Codes, Kosten- und Token-Nutzung sowie Tool-Entscheidungen - als Events unter anderem Prompts, Antworten, API-Requests und -Fehler, MCP-Verbindungen und Permission-Änderungen.

Der Punkt, der für einen Betriebsrats- oder Datenschutz-Absatz zählt: Standardmäßig sind Inhalte redigiert. Erst explizite Flags wie OTEL_LOG_USER_PROMPTS=1, OTEL_LOG_ASSISTANT_RESPONSES=1 oder OTEL_LOG_TOOL_CONTENT=1 schalten den tatsächlichen Prompt- und Antworttext frei - inklusive einem konfigurierbaren Längenlimit (Standard 60 KB). Wer nur Nutzungsmetriken und Kosten sehen will, bekommt das bereits mit den Standardeinstellungen, ohne Mitarbeiter-Prompts mitzuschreiben. Das „Aufdrehen” auf Inhaltsebene ist damit eine bewusste, dokumentierbare Entscheidung - und genau als solche gehört sie vor die Mitbestimmung, nicht als Nebeneffekt einer Monitoring-Einführung. Dieser Absatz ersetzt keine Rechtsberatung; ob und wie eine solche Erfassung mitbestimmungspflichtig ist, gehört in die Hände der eigenen Datenschutz- und Personalvertretung.

Werden OTEL_EXPORTER_OTLP_*-Variablen zentral über Managed Settings gesetzt, sperren sie das Exportziel: widersprechende Entwickler-Variablen werden beim Start entfernt. Einzelne Signale lassen sich trotzdem lokal abschalten (etwa OTEL_METRICS_EXPORTER=none) - das Ziel selbst aber nicht verbiegen. Wichtig für den Rollout-Plan: Änderungen an der OTel-Konfiguration greifen erst nach einem vollständigen Neustart von Claude Code, anders als die meisten übrigen Managed Settings.

Beispiel: managed-settings.json für den Rollout

Das folgende Beispiel zeigt ausschließlich Felder, die in der offiziellen Dokumentation belegt sind. Platzhalter in spitzen Klammern müssen durch echte Werte aus der eigenen Umgebung ersetzt werden - nichts davon ist eine Kopiervorlage für Produktivwerte.

{
  "permissions": {
    "defaultMode": "default",
    "deny": [
      "Read(./secrets/**)",
      "Read(./.env)",
      "Bash(curl *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["<interne-registry.contoso.com>"],
      "allowManagedDomainsOnly": true
    }
  },
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.contoso.com/*" }
  ],
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": "<org-uuid-aus-admin-settings>",
  "minimumVersion": "<mindestversion, z. B. 2.1.200>",
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://<otel-collector.contoso.com>:4317"
  }
}

Diese Datei (oder ihr JSON-Inhalt als Registry-Value unter Windows) lässt sich unverändert über die oben beschriebenen Intune-Wege ausrollen. Wichtig: forceLoginMethod und forceLoginOrgUUID gehören - wie oben beschrieben - zusätzlich in eine eventuell parallel genutzte server-managed Konfiguration, nicht nur hierher. Über denselben env-Block lässt sich auf die gleiche Art zentral steuern, ob experimentelle Features wie Agent Teams in Ihrer Organisation überhaupt zur Verfügung stehen sollen.

Häufige Fragen zum Claude-Code-Rollout

Wo liegt die managed-settings.json unter Windows?

Unter C:\Program Files\ClaudeCode\managed-settings.json - geprüft wird sie aber erst, wenn keine server-managed oder Registry-Policy-Quelle greift, denn die Zustellwege mergen nicht. Auf macOS liegt die Datei stattdessen unter /Library/Application Support/ClaudeCode/managed-settings.json.

Kann ein Entwickler Managed Settings überschreiben?

Nein, mit dokumentierten Ausnahmen. Auf einem MDM-verwalteten Gerät lässt sich die Registry oder die Konfigurationsdatei auf Betriebssystemebene vor Änderung schützen. Permission-Regeln bilden dabei einen Sonderfall: Sie werden über die Scopes hinweg gemergt, ein deny auf irgendeiner Ebene blockt - Entwickler können eine zentrale Liste also erweitern, aber nichts daraus entfernen.

Brauchen wir Claude for Enterprise, um Managed Settings per Intune auszurollen? Nein. Endpoint-managed Settings (Registry oder Datei, verteilt per Intune) setzen keinen bestimmten Claude-Code-Plan voraus - sie wirken unabhängig davon, ob im Hintergrund die Anthropic-API, Bedrock, Vertex AI oder Microsoft Foundry angebunden ist. Server-managed Settings dagegen brauchen mindestens Claude for Teams und die Rolle Owner oder Primary Owner.

Funktioniert das auch, wenn Claude Code über Microsoft Foundry läuft?

Ja - und das ist genau der Anwendungsfall, für den dieser Artikel gedacht ist. Server-managed Settings erreichen Foundry-Deployments nicht. Das einzige dokumentierte Äquivalent wäre ein self-hosted Claude apps gateway - wer den nicht betreiben will, hat mit Intune faktisch den einzigen zentralen Steuerungsweg.

Wie prüfe ich, ob eine Policy tatsächlich angekommen ist?

Mit /status in Claude Code - die Zeile „Enterprise managed settings” zeigt die Quelle in Klammern ((remote), (plist), (HKLM), (HKCU) oder (file)). Eine Datei mit kaputtem JSON taucht dort gar nicht erst auf, was beim Debugging ein nützliches Signal ist.

Was gilt für Entwickler, die unter WSL arbeiten?

WSL liest standardmäßig ausschließlich /etc/claude-code. Mit wslInheritsWindowsSettings: true - nur gültig, wenn in der HKLM-Registry oder in C:\Program Files\ClaudeCode\managed-settings.json gesetzt - liest WSL zusätzlich die Windows-Policy-Kette, wobei die Windows-Quellen Vorrang haben. Damit auch eine HKCU-Policy auf WSL greift, muss der Schalter zusätzlich in HKCU selbst gesetzt sein. Für gemischte Windows/WSL-Flotten lohnt sich dieser Schalter fast immer.

Fazit

Claude Code Intune-Rollout ist kein Nice-to-have für Organisationen, die bereits auf Microsoft-Endpoint-Management setzen - für alle mit einer Foundry-, Bedrock- oder Vertex-Anbindung ist es der einzige Weg, Claude Code überhaupt zentral zu steuern. Wer die Präzedenz-Logik ohne Merge kennt, die Registry- bzw. Preference-Pfade korrekt trifft und die Login-Erzwingung konsequent doppelt setzt, bekommt damit eine Kontrolle, die härter ist als jede Server-Konfiguration allein - mit der ehrlichen Einschränkung, dass auch das „nur” eine client-seitige Kontrolle bleibt, kein vollständiger Sicherheits-Perimeter.

Quellen (Stand: August 2026):

Fragen zum Thema?

Gespräch vereinbaren

06102 / 7488091 web@jl.digital