Unternehmensverwaltete Einstellungen

Verwenden Sie diesen Verweis, um die derzeit unterstützten Schlüssel zu verstehen in managed-settings.json.

Informationen zu Bereitstellungsmethoden und unterstützten Clients finden Sie unter Konfigurieren von unternehmensverwalteten Einstellungen.

Rangfolgeregeln

Wenn mehrere Einstellungsquellen vorhanden sind, haben einstellungen weiter oben in dieser Liste Vorrang vor den Einstellungen weiter unten in der Liste:

1. MDM-verwaltete Einstellungen
2. Serververwaltete Einstellungen
3. Dateibasierte Einstellungen
4. Einstellungen auf Benutzerebene

Ausnahmsweise werden die folgenden Schlüssel in der restriktivsten Richtung über verschiedene Übermittlungsmethoden hinweg verfasst:

• sandbox
• permissions.deny, permissions.ask und permissions.allow

Unterstützte Schlüssel

Anwenden unterschiedlicher Einstellungen auf Unternehmensteams

Bei serververwalteten Bereitstellungen kann das Unternehmen verschiedene Governance auf Gruppen von Benutzern basierend auf ihrer Unternehmensteammitgliedschaft anwenden. Das Unternehmen definiert alle Einstellungen – die Teammitgliedschaft bestimmt nur, welche Benutzer einen bestimmten Wertesatz erhalten.

Um einen Schlüssel für teamspezifische Werte verfügbar zu machen, markieren Sie ihn in managed-settings.json mithilfe der { "overridable": <VALUE> }-Syntax als überschreibbar. Ein überschreibbarer Schlüssel verwendet den Wert des Teams, wenn er festgelegt ist, oder greift auf die Standardeinstellung Ihres Unternehmens zurück, wenn das Team sie nicht festgelegt hat. Die { "overridable": <VALUE> }-Syntax gilt für die Schlüssel model, permissions.disableBypassPermissionsMode, permissions.deny, permissions.allow, permissions.ask, allowedMcpServers und deniedMcpServers. Schlüssel, die nicht als übersteuerbar gekennzeichnet sind, bleiben eine Entscheidung auf Unternehmensebene, die von Teams nicht geändert werden kann.

enabledPlugins und extraKnownMarketplaces wirken additiv. Das Unternehmen managed-settings.json legt einen Basisplan fest, und eine Unternehmensteamdatei kann darüber hinaus weitere Plug-Ins und Marketplaces hinzufügen. Die vollständigen Einrichtungsschritte finden Sie unter Konfigurieren von unternehmensverwalteten Einstellungen.

Beispielkonfiguration

Das folgende Beispiel zeigt diese Schlüssel in einer verwalteten Einstellungsdatei.

{
  "model": "auto",
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Shell(rm -rf *)",
      "Read(~/.ssh/**)",
      "Edit(//etc/**)",
      "Domain(*.unapproved.example)"
    ],
    "ask": [
      "Shell(git push *)",
      "Edit(/src/**)",
      "Domain(api.github.com)"
    ],
    "allow": [
      "Shell(npm test *)",
      "Read(/src/**)",
      "Domain(registry.npmjs.org)"
    ]
  },
  "enabledPlugins": {
    "my-plugin@agent-skills": true
  },
  "extraKnownMarketplaces": {
    "agent-skills": {
      "source": {
        "source": "github",
        "repo": "OWNER/REPO"
      },
      "autoUpdate": true
    }
  },
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "OWNER/REPO"
    }
  ],
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "http/protobuf",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "copilot",
    "resourceAttributes": {
      "deployment.environment": "production"
    },
    "headers": {
      "Authorization": "Bearer TOKEN"
    }
  },
  "remoteControl": {
    "mode": "requireSSO",
    "githubDotComOrganizations": ["ORG-NAME"]
  },
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "@playwright/mcp@latest"] },
    { "serverCommand": ["cmd", "/c", "uvx", "markitdown-mcp"] }
  ],
  "deniedMcpServers": [
    {
      "serverCommand": [
        "npx",
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/"
      ]
    }
  ],
  "sandbox": {
    "enabled": true,
    "allowBypass": false,
    "sandboxMcpServers": true,
    "sandboxLspServers": true
  }
}

enabledPlugins

Definiert Plug-Ins, die für alle Unternehmensbenutzer automatisch installiert oder blockiert werden. Jeder Eintrag verwendet das Format PLUGIN-NAME@MARKETPLACE-NAME als Schlüssel mit einem booleschen Wert: true um das Plug-In zu aktivieren oder false zu deaktivieren. Siehe Informationen zu unternehmensverwalteten Plug-In-Standards.

extraKnownMarketplaces

Definiert zusätzliche Plug-In-Marketplaces, die benutzern zur Verfügung stehen. Jeder Eintrag ist ein benanntes Marketplace-Objekt, das eine source Eigenschaft und einen optionalen booleschen autoUpdate Wert enthält.

Setzen Sie autoUpdate auf true, um Clients dazu zu verpflichten, diesen Marketplace regelmäßig neu zu laden und darüber bezogene installierte Plug-ins zu aktualisieren. Setzen Sie es auf false, damit automatische Updates für diesen Marktplatz deaktiviert bleiben müssen. Wenn Sie weglassen autoUpdate, verwenden Clients das vorhandene Standardverhalten oder das vom Benutzer konfigurierte Verhalten.

Da verwaltete Einstellungen Vorrang haben, können Benutzer einen definierten autoUpdate Wert nicht außer Kraft setzen. Die Einstellung gilt nur für diesen Marktplatz, und etwaige Einschränkungen in strictKnownMarketplaces gelten weiterhin vor Aktualisierungs- und Updatevorgängen.

Die folgenden Quelltypen werden unterstützt:

• "github" — erfordert repo im Format OWNER/REPO; optional sind ref (Branch, Tag oder SHA) und path (Unterverzeichnis)
• "git" — erfordert url; optional ref und path
• "directory" — erfordert path

Siehe Informationen zu unternehmensverwalteten Plug-In-Standards.

Streng bekannte Marktplätze

Beschränkt die Plug-In-Installation auf nur die vom Unternehmen explizit definierten Marketplaces. Ein leeres Array bedeutet einen vollständigen Sperrmodus. Jeder Eintrag ist ein Marketplace-Objekt mit einer source Eigenschaft, die den Quelltyp angibt. Die folgenden Quelltypen werden unterstützt:

• "github" — erfordert repo im Format OWNER/REPO; optional ref und path
• "git" — erfordert url; optional ref und path
• "url" — erfordert url; optionales headers Objekt
• "npm" — erfordert package
• "file" — erfordert path
• "directory" — erfordert path
• "hostPattern" — erfordert hostPattern (Regex zum Abgleichen von Marketplace-Hosts)
• "pathPattern" — erfordert pathPattern (regex-übereinstimmende Marketplace-Pfade)

model

Legt die Automatische Modellauswahl als Standard für neue Unterhaltungen fest. Siehe Über Copilotauto model selection.

• Wenn Sie model auf "auto" setzen, verwenden neue Sitzungen das Auto-Modell, sofern der Benutzer nicht für jede Unterhaltung ein anderes Modell angibt.
• Dieser Schlüssel kann von der Unternehmensteamzuordnung außer Kraft gesetzt werden. Verwenden Sie in Ihrem managed-settings.json die Syntax { "overridable": "auto" }, um die Konfiguration des Schlüssels für jedes Team anzupassen. Anschließend können Sie in einer Datei mit Teameinstellungen "model": "unmanaged" festlegen und so eine Spezialisierung angeben, die für Mitglieder des betreffenden Teams Vorrang vor managed-settings.json hat.

permissions

Ablehnen, Fragen, Zulassen

Die Schlüssel permissions.deny, permissions.allow und **** verwenden die Rangfolge permissions.ask. Wenn eine vom MDM verwaltete, serververwaltete oder dateibasierte Quelle eine Berechtigungsregel definiert – oder wenn eine zutreffende Quelle eine allow Liste angibt –, erfordert ein nicht zugeordneter unterstützter Vorgang standardmäßig eine Genehmigung. Andernfalls folgt sie dem üblichen Berechtigungsablauf.

• deny blockiert bestimmte Vorgänge, unabhängig davon, ob sie auch mit einer ask oder allow einer Regel übereinstimmen. Eine Verweigerungsregel, die von jeder verwalteten Einstellungsquelle festgelegt wird, blockiert den Vorgang für alle Benutzer unabhängig von Regeln in den anderen Quellen.
• ask erfordert eine erneute einmalige Genehmigung, bevor ein bestimmter Vorgang fortgesetzt werden kann, auch wenn der Vorgang andernfalls zulässig wäre. Eine verwaltete ask-Regel lässt sich nicht durch den Umgehungsmodus (auch als „Alle zulassen“- oder YOLO-Modus bezeichnet), eine Einstellung zur automatischen Genehmigung, einen Hook oder eine andere Abkürzung bei der Genehmigung oder durch eine aus einer früheren Genehmigung fortbestehende Freigabe erfüllen. Beim nächsten Anfordern wird für den gleichen Vorgang erneut eine Aufforderung angezeigt.
• allow ermöglicht, dass ein bestimmter Vorgang ohne Aufforderung fortgesetzt werden kann. Die effektive Erlaubnisliste ist die Schnittmenge aller Quellen, die eine definieren, nicht die Vereinigung. Eine Quelle, die keine allow Liste deklariert, enthält keine eigenen Einschränkungen für diesen Schlüssel.

Regeln verwenden die folgenden Selektoren:

Selektor	Übereinstimmungen
Shell(...)	Shellbefehle. Verwenden Sie <command> * (z. B. git push *), um mit einem Befehlspräfix abzugleichen; andernfalls stimmt die Regel nur mit exakt diesem Text überein.
Bash(...) ist ein Kompatibilitätsalias für Shell(...).
PowerShell(...) verwendet dieselbe Selektorfamilie mit einer Befehlsübereinstimmung ohne Beachtung der Groß-/Kleinschreibung.
Read(...)	Pfade zum Lesen und Anzeigen von Dateien. Unterstützt Globmuster und folgende Stammverzeichnisse: // für das Stammverzeichnis des Dateisystems, / für das Stammverzeichnis des Arbeitsbereichs, ~/ für das Home-Verzeichnis und ./ für das aktuelle Arbeitsverzeichnis.
Edit(...)	Dateischreib- und Bearbeitungspfade, die auf die gleiche Weise übereinstimmen wie Read(...).
Write(...) ist ein Alias für Edit(...).
Domain(...)	Netzwerkherkunft. Bei einem Bare-Host wird standardmäßig HTTPS verwendet, und bei einem Hostabgleich wird die Groß-/Kleinschreibung nicht beachtet. Verwenden Sie *.example.com, um Subdomains einzuschließen; zum Beispiel entspricht *. sowohl example.com als auch dessen Subdomains.

Jeder Unterschlüssel ist für Enterprise-Teams überschreibbar. Legen Sie den Unternehmenswert auf { "overridable": <VALUE> } fest und ersetzen Sie <VALUE> durch das Regelarray. Verwenden Sie dann die reguläre Syntax, um Ersetzungsregeln in der Datei jedes Teams zu definieren.

disableBypassPermissionsMode

Verhindert, dass Benutzer den Umgehungsmodus aktivieren (auch bekannt als "YOLO-Modus"). Mit dem Umgehungsmodus kann ein Agent Befehle ausführen, auf Dateien zugreifen und URLs abrufen, ohne um Genehmigung zu bitten.

Wenn Sie disableBypassPermissionsMode auf "disable" festlegen, können Benutzer den Bypassmodus nicht aktivieren:

• In Copilot CLI sind alle Befehlszeilenoptionen zum Gewähren aller Berechtigungen (--yolo, --allow-all und die einzelnen Optionen --allow-all-tools, --allow-all-paths und --allow-all-urls) beim Start unterdrückt und können keine erhöhten Berechtigungen gewähren. Die /yolo und /allow-all Slash-Befehle sind ebenfalls blockiert.
• In VS Code, die globale Einstellung für die automatische Genehmigung (chat.tools.global.autoApprove) ist deaktiviert und kann nicht erneut aktiviert werden.
• Im GitHub Copilot app ist die Einstellung „Alle zulassen“ für „Tool-Berechtigungen“ in den Sitzungseinstellungen blockiert.
• Dieser Schlüssel kann von der Unternehmensteamzuordnung außer Kraft gesetzt werden. Verwenden Sie in Ihrem managed-settings.json die Syntax { "overridable": "disable" }, um die Konfiguration des Schlüssels für jedes Team anzupassen. Anschließend können Sie in einer Datei mit Teameinstellungen "disableBypassPermissionsMode": "unmanaged" festlegen und so eine Spezialisierung angeben, die für Mitglieder des betreffenden Teams Vorrang vor managed-settings.json hat.

Telemetrie

Konfiguriert den OpenTelemetry-Export und leitet Copilot-Nutzungsdaten an einen Collector Ihrer Wahl weiter.

Diese Eigenschaft wird unterstützt für Copilot CLI und VS Code.

Wenn Sie die telemetry Eigenschaft festlegen, wird Copilot Telemetrie an den von Ihnen angegebenen Endpunkt gesendet. Die folgenden Untereigenschaften werden unterstützt:

• enabled: Auf true festlegen, um den Telemetrieexport zu aktivieren, oder auf false, um ihn zu deaktivieren.
• endpoint: Die URL Ihres OTLP-Collectors (z. B. https://otel-collector.example.com).
• protocol: Das Transportprotokoll für den Telemetrieexport. Akzeptierte Werte sind "http/json" und "http/protobuf".
• captureContent: Auf true festlegen, um Prompt- und Antwortinhalte in die Telemetrie-Nutzlast einzuschließen, oder auf false, um sie auszuschließen.
• lockCaptureContent: Legen Sie den Wert auf true fest, um zu verhindern, dass Benutzer die Einstellung captureContent ändern.
• serviceName: Eine Bezeichnung für den Telemetriedienstnamen (z. B "copilot". ).
• resourceAttributes: Ein Objekt von OpenTelemetry-Ressourcenattributen, die an alle exportierten Telemetrie angefügt werden sollen (z. B {"deployment.environment": "production"}. ).
• headers: Ein Objekt von HTTP-Headern, das in jede Telemetrieanforderung eingeschlossen werden soll (z. B. eine Authorization Kopfzeile für den Sammler).

remoteControl

Beschränkt, ob auf einem Gerät gehostete Copilot Sitzungen ferngesteuert werden können. Dies wirkt sich nicht auf die Fähigkeit eines Benutzers aus, seine Sitzungen remote zu steuern, die auf anderen Geräten gehostet werden.

• mode: Legen Sie den Wert auf "disabled" fest, um die Remotesteuerung von Sitzungen auf dem Gerät zu verhindern, auf "requireSSO", um die Remotesteuerung nur von einem Client zuzulassen, der für die in githubDotComOrganizations aufgeführten Organisationen per SSO autorisiert ist, oder auf "enabled", um sie uneingeschränkt zuzulassen.
• githubDotComOrganizations: Ein Array mit Organisations-Logins. Erforderlich, wenn mode gleich "requireSSO" ist.

allowedMcpServers

Definiert eine Liste von MCP-Servern, die ausgeführt werden dürfen. Wenn festgelegt, sind nur Server zulässig, die mit mindestens einem Eintrag übereinstimmen. Jeder Server, der nicht übereinstimmt, wird blockiert.

Lassen Sie diesen Schlüssel vollständig aus, um alle Server zuzulassen, vorbehaltlich aller Einträge in deniedMcpServers. Legen Sie es auf ein leeres Array fest, um alle Server außer integrierten Standardservern zu blockieren.

Wenn mehrere Einstellungsquellen allowedMcpServers definieren, ist die wirksame Zulassungsliste die Schnittmenge aller Quellen. Ein Server muss von jeder Quelle zum Ausführen zugelassen werden.

Jeder Eintrag muss genau eine Matcher-Eigenschaft enthalten.

Eigentum	Zuordnungsverhalten	Anwendbare Server
serverName	Entspricht exakt der benutzerdefinierten Serverbezeichnung. Wildcards werden nicht unterstützt. Da Benutzer Servernamen auswählen, verwenden serverUrl oder serverCommand wenn Sie die Identität eines Servers erzwingen müssen.	Jeder Server. In-Memory-Server können nur serverName verwenden.
serverUrl	Entspricht einer Remoteserver-URL. Unterstützt * Platzhalter für Unterdomänen oder Pfadpräfixe – zum Beispiel https://mcp.example.com/* oder https://*.internal.example.com/*.	Remoteserver, die eine Verbindung über HTTP- oder servergesendete Ereignisse (SSE) herstellen. Diese Eigenschaft gilt nicht für lokale Server, auch wenn sie über eine URL verfügen.
serverCommand	Stimmt genau mit dem Befehl und jedem Argument für einen lokalen Server überein – zum Beispiel ["npx", "-y", "my-mcp-server"]. Wildcards und Befehlszeilenerweiterung werden nicht unterstützt.	Lokale Server mit Standardeingabe und -ausgabe (stdio). Diese Eigenschaft gilt nicht für Remoteserver, auch wenn sie über einen Befehl verfügen.

Dieser Schlüssel ist für Unternehmensteams außer Kraft gesetzt. Fassen Sie die Matcher-Objekte auf Unternehmensebene unter overridable zusammen und verwenden Sie dann die reguläre Syntax, um Zulassungslisten und Sperrlisten in der Datei des jeweiligen Teams zu definieren.

URL-Kanonisierung

Vor dem Vergleichen eines serverUrl Musters mit einer Server-URL normalisiert der Client beide Werte:

• Konvertiert das Schema und den Host in Kleinbuchstaben.
• Konvertiert internationalisierte oder Unicode-Hostnamen in Punycode.
• Entfernt den Standardport :80 für HTTP oder :443 HTTPS.
• Dekodiert prozentkodierte Host-Oktette. %65vil wird beispielsweise zu evil.
• Entfernt URL-Fragmente und nachfolgende Punkte aus DNS-Namen.
• Verhindert, dass Die Zuordnung von Wildcards in der Autoritätskomponente über die / Grenze zum Pfad erfolgt.

verweigertMcpServers

Definiert MCP-Server, die bedingungslos blockiert werden. Ein Server, der auf irgendeinen Eintrag zutrifft, wird blockiert, auch wenn er auch auf einen Eintrag in allowedMcpServers zutrifft. Ablehnungsregeln haben immer Vorrang vor Zulassungsregeln.

Erstanbieterserver Copilot , z. B. der integrierte MCP-Server GitHub , sind von Deny-Regeln ausgenommen und können nicht blockiert werden.

Wenn mehrere Einstellungsquellen deniedMcpServers definieren, ist die resultierende Sperrliste die Vereinigung aller Quellen. Ein von jeder Quelle blockierter Server wird für alle blockiert.

Jeder Eintrag verwendet dieselben Eigenschaften serverName, serverUrl oder serverCommand, die in allowedMcpServers beschrieben werden.

sandbox

Erzwingt lokale Mindesteinschränkungen der Sandbox für Copilot CLI. Verwaltete Sandkasteneinstellungen setzen Einschränkungen anstelle von Standardeinstellungen auf:

• Bei Einstellungen vom Typ „Erzwingen“ erzwingt ein verwalteter Wert von true die Einstellung. false oder das Weglassen lässt die Benutzerkonfiguration unverändert.
• Für Funktionseinstellungen verbietet ein verwalteter Wert false die Funktion. true oder das Weglassen lässt die Benutzerkonfiguration unverändert.
• Verwaltete Lese-/Schreib- und schreibgeschützte Pfadlisten beschränken die vom Benutzer konfigurierten Berechtigungen, während verwaltete Pfade mit Zugriffsverweigerung die vom Benutzer konfigurierten Verweigerungen ergänzen.

Die folgenden Untereigenschaften werden unterstützt:

• enabled: true schreibt Sandboxing vor und verhindert, dass Benutzer es deaktivieren.
• allowBypass: false verhindert, dass das Modell anfordert, dass ein einzelner Befehl außerhalb der Sandbox ausgeführt wird.
• addCurrentWorkingDirectory: false verhindert, dass Copilot CLI das aktuelle Arbeitsverzeichnis automatisch zu den Lese-/Schreibpfaden der Sandbox hinzugefügt wird.
• sandboxMcpServers: true erfordert, dass von Copilot CLI gestartete lokale MCP-Server in der Sandbox ausgeführt werden. Remote-MCP-Server werden nicht im lokalen Sandkasten ausgeführt.
• sandboxLspServers: true erfordert, dass von Copilot CLI gestartete Sprachserver in der Sandbox ausgeführt werden.
• gitAuth: false hindert Copilot CLI daran, ein GitHub-Token für authentifizierte Git-HTTPS-Vorgänge in der Sandbox einzuschleusen.
• ghAuth: false verhindert, dass Copilot CLI ein GitHub-Token für GitHub CLI in die Sandbox einschleust.
• allowDevToolAccess: false verhindert den automatischen Zugriff auf die Konfiguration von Entwicklungstools, Caches, Registrierungen und Toolketten. Diese Speicherorte können Paketregistrierungsanmeldeinformationen oder Token enthalten. Das Deaktivieren des Zugriffs kann dazu führen, dass Paketwiederherstellung, authentifizierte Registrierungsvorgänge oder Builds, die freigegebene Caches verwenden, fehlschlagen, es sei denn, Sie gewähren explizit die erforderlichen Pfade.
• userPolicy: Ein Objekt, das Dateisystem-, Netzwerk- und macOS-spezifische Seatbelt-Einschränkungen konfiguriert. Die unterstützten Eigenschaften werden in den folgenden Abschnitten beschrieben.

sandbox.userPolicy.filesystem

Konfiguriert den Dateisystemzugriff für Sandkastenprozesse. Pfade sollten absolut sein. Listen mit verwalteten Berechtigungen werden anhand exakter Pfadzeichenfolge und nicht durch die Abdeckung des übergeordneten oder untergeordneten Pfads mit benutzerdefinierten Listen abgeglichen.

• readwritePaths: Ein Array von Pfaden, auf die in einer Sandbox ausgeführte Prozesse lesend und schreibend zugreifen können. Ein vom Benutzer konfigurierter Pfad bleibt nur verfügbar, wenn seine genaue Zeichenfolge auch in jeder verwalteten Quelle angezeigt wird, die diese Eigenschaft angibt. Ein leeres verwaltetes Array entfernt alle vom Benutzer konfigurierten Lese-/Schreibpfadberechtigungen, entfernt jedoch keinen separat gewährten Zugriff, z. B. auf temporäre Verzeichnisse oder das aktuelle Arbeitsverzeichnis.
• readonlyPaths: Ein Array von Pfaden, die von in einer Sandbox ausgeführten Prozessen gelesen, aber nicht beschrieben werden können. Ein vom Benutzer konfigurierter Pfad bleibt nur verfügbar, wenn seine genaue Zeichenfolge auch in jeder verwalteten Quelle angezeigt wird, die diese Eigenschaft angibt. Ein leeres verwaltetes Array entfernt alle vom Benutzer konfigurierten schreibgeschützten Pfadberechtigungen, entfernt jedoch keinen separat gewährten Zugriff.
• deniedPaths: Ein Array von Pfaden, auf die Sandkastenprozesse nicht zugreifen können. Ein verwalteter Wert wird den verweigerten Pfaden eines Benutzers hinzugefügt, anstatt diesen zu ersetzen.

sandbox.userPolicy.network

Konfiguriert den Netzwerkzugriff für Sandkastenprozesse.

• allowOutbound: false blockiert den ausgehenden Netzwerkzugriff.
• allowLocalNetwork: false verhindert den Zugriff auf das lokale Netzwerk.

Das Netzwerkverhalten variiert je nach Betriebssystem. Insbesondere ist ein Proxy keine vollständige Grenze für die Kontrolle ausgehender Verbindungen, da einige Anwendungen Proxyeinstellungen ignorieren können.

sandbox.userPolicy.seatbelt

Konfiguriert macOS-spezifische Sitzgurtoptionen.

• keychainAccess: false verhindert, dass Sandkastenprozesse auf den macOS-Schlüsselbund zugreifen.