Unternehmensverwaltete Einstellungen

Verwenden Sie diese Referenz, um unternehmensverwaltete Einstellungen für Copilot zu verstehen. Die meisten Einstellungen können in managed-settings.json konfiguriert werden. Einstellungen, die die Geräteverwaltung erfordern, werden unten aufgeführt.

Anweisungen zum Erstellen der Datei finden Sie unter Erste Schritte mit unternehmensverwalteten Einstellungen.

Unterstützte Schlüssel

Clientunterstützung per Schlüssel

telemetry wird je nach Untereigenschaft und Harness unterschiedlich unterstützt. Siehe Aufnahmesteuerung für die Clients, die eine differenzierte Erfassung unterstützen.

Weitere Informationen zu Copilot in the cloud

Cloud-Sitzungen können in Sandboxen oder auf GitHub Actions ausgeführt werden. Die Abdeckung von Richtlinien und vom Unternehmen verwalteten Einstellungen variiert derzeit zwischen Umgebungen. Wenn Benutzer zwischen diesen Umgebungen wählen können, sind Cloud-Sandboxen die Standardeinstellung. Derzeit sind einige Oberflächen jedoch nur auf GitHub Actions verfügbar (z. B. das Zuweisen eines Issues zu Copilot oder die Erwähnung von @Copilot in einem Pull Request).

Die in der Tabelle für Copilot in the cloud (Sandbox) definierten Schlüssel werden von allen Oberflächen unterstützt, die das Starten von Sitzungen in Cloud-Sandboxes unterstützen. Als Ausnahme wird die model Taste nur für Cloudsitzungen unterstützt, die von der GitHub Website gestartet wurden, Copilot CLI und VS Code.

allowedMcpServers und deniedMcpServers gelten für MCP-Server, die in Benutzereinstellungen und Repositoryeinstellungen definiert sind, gelten jedoch nicht für MCP-Server, die in benutzerdefinierten Agentprofilen des Repositorys definiert sind. Sie können jedoch die Verwendung von MCP-Servern verhindern, die in benutzerdefinierten Agentprofilen konfiguriert sind, indem Sie sicherstellen, dass alle erforderlichen Domänen, die zum Starten dieser Server erforderlich sind, nicht von der benutzerdefinierten Firewall auf Organisations- oder Repository-Ebene zugelassen sind. Siehe Anpassen oder Deaktivieren der Firewall für GitHub Copilot.

Beispielkonfiguration

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

{
  "features": {
    "computerUse": false
  },
  "model": "auto",
  "autoTier": "intelligence",
  "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",
    "capture": {
      "identity": true,
      "prompts": false,
      "responses": false,
      "toolArguments": false,
      "toolOutput": false,
      "policyDetail": false
    },
    "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,
    "failIfUnavailable": true,
    "allowBypass": false,
    "sandboxMcpServers": true,
    "sandboxLspServers": true
  }
}

features.computerUse

Steuert, ob Benutzer die Computernutzung in GitHub Copilot CLI und in GitHub Copilot app aktivieren können. Legen Sie diese Einstellung features.computerUse fest, um zu false verhindern, dass Benutzer die Computerverwendung aktivieren. Eine lokale Einstellung kann diese Einschränkung nicht außer Kraft setzen. Legen Sie den Wert auf den Wert fest true, oder lassen Sie den Schlüssel aus, damit Benutzer die Verwendung des Computers über ihre lokalen Einstellungen steuern können.

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.

Verwaltete Werte haben immer Vorrang vor Repository-Standardeinstellungen und Mitgliedereinstellungen. Repositorystandardwerte können kein Plug-In aktivieren, das durch verwaltete Richtlinien blockiert wird oder einen Marketplace verwendet, der durch Richtlinien nicht zulässig ist.

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.

Schließen Sie für serververwaltete Enterprise-Teamüberschreibungen die vollständige Marketplace-Karte in overridable:

{
  "extraKnownMarketplaces": {
    "overridable": {
      "enterprise-plugins": {
        "source": {
          "source": "github",
          "repo": "OWNER/REPO"
        }
      }
    }
  }
}

Eine Datei eines Unternehmensteams kann dann eine reguläre Marketplace-Zuordnung bereitstellen, um diese Standardeinstellung zu ersetzen. Fügen Sie alle Standard-Marketplaces hinzu, die das Unternehmensteam beibehalten soll. Wenn das Enterprise-Team den Schlüssel auslässt, bleibt der Enterprise-Standard.

strictKnownMarketplaces

Beschränkt die Plug-In-Installation auf nur die vom Unternehmen explizit definierten Marketplaces. Wenn dieser Schlüssel festgelegt wird, werden die integrierten Marktplätze deaktiviert. 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)

Dieser Schlüssel kann für Unternehmensteams außer Kraft gesetzt werden. Umschließen Sie die vollständige Liste zulässiger Elemente auf Unternehmensebene mit overridable:

{
  "strictKnownMarketplaces": {
    "overridable": [
      { "source": "github", "repo": "OWNER/REPO" }
    ]
  }
}

Verwenden Sie ein normales Array in der Enterprise-Teamdatei, um die Standard-Allowlist zu ersetzen. Beim Weglassen des Schlüssels wird der Unternehmensstandard beibehalten. Ein explizites leeres Array, []bedeutet einen vollständigen Sperrmodus, keine nicht verwaltete Richtlinie.

model

Legt Ihr bevorzugtes Modell als Standard für neue Unterhaltungen fest. Auf diese Weise können Sie das Standardmodell auswählen, das am besten zu den Workflows Ihres Unternehmens passt. Benutzer können weiterhin ein anderes Modell pro Unterhaltung auswählen.

• Setzen Sie model auf "fusion", um Copilot Fusion als Standard zu verwenden, sodass neue Sitzungen automatisch ein Modell oder ein Ausführungsmuster auswählen, es sei denn, der Benutzer gibt pro Unterhaltung ein anderes Modell an. Siehe Informationen zu GitHub Copilot Fusion.
• Setzen Sie model auf "auto", um auto model selection als Standard zu verwenden, sodass neue Sitzungen automatisch ein Modell auswählen, es sei denn, der Benutzer gibt für eine bestimmte Unterhaltung ein anderes Modell an. Siehe Über GitHub Copilotauto model selection.
• Legen Sie für model ein bestimmtes Modell und eine bestimmte Version fest, um dieses Modell zum Standard für neue Konversationen zu machen, z. B. "kimi-k3".

Dieser Schlüssel kann von der Unternehmensteamzuordnung außer Kraft gesetzt werden. Verwenden Sie in Ihrer managed-settings.json die { "overridable": "auto" }-Syntax, um die Konfiguration des Schlüssels für ein Unternehmensteam zu spezialisieren. Anschließend können Sie "model": "unmanaged" in einer Einstellungsdatei für Unternehmensteams festlegen und eine Spezialisierung bereitstellen, die für Mitglieder dieses Unternehmensteams Vorrang vor managed-settings.json hat.

fusionTier

Legt die Standardaufwandsstufe für neue Unterhaltungen fest, wenn als Modell "fusion" ausgewählt ist. Akzeptierte Werte, von den restriktivsten bis zu den am wenigsten restriktiv, sind "standard", "high", "max"und "unmanaged". Diese Einstellung wählt das Modell selbst nicht aus.

Für diese Einstellungen sind die folgenden Versionen erforderlich:

• In Copilot CLI ist Version 1.0.104-3 oder höher erforderlich.
• In VS Code ist Version 1.144.0 oder höher erforderlich.
• In GitHub Copilot app ist 1.1.33-4 oder höher erforderlich.

Legen Sie fusionTier auf eine andere Zeichenfolge als "unmanaged" fest, um die Leistungsstufe gegen Überschreibungen durch Benutzer und Repository zu sperren. Um einen Standardwert bereitzustellen, den Unternehmensteams außer Kraft setzen können, verwenden Sie overridable:

{
  "model": "fusion",
  "fusionTier": { "overridable": "standard" }
}

Beispielsweise kann eine Teameinstellungsdatei "fusionTier": "high" festlegen. Wenn das Team nicht festgelegt wird fusionTier, gilt der Unternehmensstandard.

AutoTier

Legt die Standardroutingebene für neue Unterhaltungen fest, wenn das ausgewählte Modell ist "auto". Akzeptierte Werte, von den restriktivsten bis zu den am wenigsten restriktiv, sind "efficiency", "balance", "intelligence"und "unmanaged". Diese Einstellung wählt das Modell selbst nicht aus.

In Copilot CLI, diese Einstellung erfordert Version 1.0.87-0 oder höher. In VS Code, es erfordert Version 1.140.0 oder höher.

Festlegen autoTier auf eine andere Zeichenfolge als "unmanaged" das Sperren der Ebene für Benutzer- und Repository-Außerkraftsetzungen. Um einen Standardwert bereitzustellen, den Unternehmensteams außer Kraft setzen können, verwenden Sie Folgendes: overridable

{
  "model": "auto",
  "autoTier": { "overridable": "balance" }
}

Beispielsweise kann eine Einstellungsdatei für Unternehmensteams "autoTier": "intelligence" festlegen. Wenn das Enterprise-Team autoTier nicht festlegt, wird die Standardeinstellung des Unternehmens angewendet.

forceRemoteSettingsRefresh

Erfordert einen neuen Download von serververwalteten Einstellungen beim Start in Copilot CLI, VS Codeund der GitHub Copilot app. Setzen Sie forceRemoteSettingsRefresh auf true, um diese Anforderung zu aktivieren.

In Copilot CLI und dem GitHub Copilot app wird der normale einstündige Cache übersprungen, und es wird verhindert, bei einem fehlgeschlagenen Download auf eine ältere zwischengespeicherte Richtlinie zurückzugreifen. Bei einer nicht erfolgreichen Aktualisierung wird die Richtlinie nicht bestätigt, sodass betroffene Vorgänge eingeschränkt sind. In VS Code, Copilot Features werden blockiert, bis die erforderliche Aktualisierung erfolgreich abgeschlossen ist. Benutzer benötigen daher beim Starten des Clients eine Netzwerkverbindung.

Um die Anforderung ab dem ersten Start eines Geräts anzuwenden, stellen Sie sie über von MDM verwaltete oder dateibasierte Einstellungen bereit. Ein serververwalteter Wert kann Aktualisierungen für nachfolgende Startups erfordern, nachdem der Client ihn erhalten hat. Hilfsskripte für Richtlinien können diesen Schlüsselwert nicht festlegen.

Verwenden Sie in managed-settings.json einen JSON-Boolean, z. B. "forceRemoteSettingsRefresh": true. Beim Konfigurieren von Copilot CLI über die Windows-Registrierung oder die verwalteten macOS-Einstellungen speichern Sie diesen Wert als Zeichenfolge, die true oder false enthält. Verwenden Sie keinen DWORD- oder nativen booleschen Typ.

permissions

Ablehnen, Fragen, Zulassen

In VS Code, diese granularen Berechtigungsregeln gelten für Copilot Sitzungen, die Agent-Host verwenden. Die permissions.disableBypassPermissionsMode Einstellung hat umfassendere VS Code Unterstützung und ist nicht auf Agent-Host beschränkt.

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 er 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 Zuweisung 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 Zulassungsliste ist die Schnittmenge aller Quellen, die eine deklarieren, 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 *) für ein passendes Befehlspräfix, 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 Unternehmensteams zu definieren.

disableBypassPermissionsMode

Verwenden Sie dies, um zu verhindern, dass Benutzer den Bypass-Modus aktivieren. Mit dem Umgehungsmodus kann ein Agent Befehle ausführen, auf Dateien zugreifen und URLs abrufen, ohne um Genehmigung zu bitten.

Setzen Sie diesen Schlüssel auf "disable", um den Umgehungsmodus zu deaktivieren.

Diese Einstellung verhindert assisted permissionsnicht. Schreibgeschützte Vorgänge und Anfragen, die von anwendbaren Berechtigungsregeln zulässig sind, können weiterhin ohne Aufforderung ausgeführt werden. Verwaltete deny Und ask Regeln werden weiterhin angewendet. Weitere Informationen zu assisted permissions findest du unter Zulassen der Ausführung sicherer Befehle ohne manuelle Genehmigung.

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

• In Copilot CLI, alle Befehlszeilenoptionen zum Zulassen aller Berechtigungen (--yolo, --allow-allund der einzelnen --allow-all-tools, --allow-all-pathsund --allow-all-urls Optionen) haben keine Auswirkungen auf den Start und können keine erhöhten Berechtigungen erteilen. Der /permissions allow-all Schrägstrichbefehl und seine Aliase /allow-all und /yolo, werden ebenfalls blockiert. Diese Einstellung blockiert weder /permissions assisted noch /allow-all auto. Die permissions.disableAssistedPermissionsMode Einstellung steuert, ob Benutzer assisted permissions aktivieren können.
• In VS Code, die globale Einstellung für die automatische Genehmigung (chat.tools.global.autoApprove) ist deaktiviert und kann nicht erneut aktiviert werden.
• In den GitHub Copilot appSitzungen kann Alle genehmigen nicht für Tool-Berechtigungen verwendet werden, auch wenn ein Benutzer dies in Einstellungen**** > als Standard auswählt.

Für diesen Schlüssel gewinnt der restriktivste Wert über alle Richtlinienebenen hinweg. Eine "disable" Einstellung, die auf einer beliebigen Ebene festgelegt wird, tritt in Kraft und kann nicht aufgehoben werden. Eine Ebene mit niedrigerer Autorität oder eine Überschreibung pro Team kann diesen Schlüssel nicht wieder auf „Nicht verwaltet“ festlegen, sobald eine Ebene den Umgehungsmodus deaktiviert hat.

disableAssistedPermissionsMode

Setzen Sie permissions.disableAssistedPermissionsMode auf true, um zu verhindern, dass Benutzer assisted permissions aktivieren. Diese Einstellung deaktiviert den Umgehungsmodus nicht.

defaultMode

Legen Sie permissions.defaultMode auf "manual", "assisted" oder "allow-all" fest, um den Standardberechtigungsmodus für neue Sitzungen auszuwählen. Wenn der ausgewählte Modus nicht verfügbar oder durch die Richtlinie blockiert ist, beginnt die Sitzung mit der manuellen Genehmigung.

Diese Einstellung wählt einen Standardwert und keinen gesperrten Modus aus. Eine explizit zulässige Wahl für eine Sitzung hat Vorrang vor dem verwalteten Standardwert. Wiederaufgenommene Sitzungen behalten ihren gespeicherten Modus bei, vorbehaltlich der aktuellen Richtlinieneinschränkungen.

In Copilot CLI hat dieser verwaltete Standardwert Vorrang vor der defaultPermissionMode-Einstellung des Benutzers.

Telemetrie

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

Weitere Informationen finden Sie in der Tabelle mit unterstützten Tasten für die Clientunterstützung.

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".
• capture: Ein Objekt mit unabhängigen, fein abgestimmten Steuerelementen für Identitäts- und vertrauliche Inhalte. Jede Untereigenschaft ist standardmäßig auf false. Ausführliche Informationen finden Sie unter Aufnahmesteuerung.
• captureContent: Veraltete Kurzform, die die Erfassungsklassen prompts, responses, toolArguments, toolOutput und policyDetail gemeinsam aktiviert oder deaktiviert. Es hat keine Auswirkungen auf identity. Eine explizit konfigurierte capture Untereigenschaft hat für diese Klasse Vorrang vor captureContent.
• lockCaptureContent: Auf true setzen, um zu verhindern, dass lokale Einstellungen eine ältere Inhaltsklasse aktivieren, es sei denn, Sie konfigurieren diese Klasse oder captureContent im verwalteten telemetry-Objekt explizit. Diese Eigenschaft steuert die Identität nicht.
• 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 Literal-HTTP-Headern, die in jede Telemetrieanforderung eingeschlossen werden sollen (z. B. ein Authorization Header für den Sammler). Sie müssen telemetry im selben endpoint Objekt konfigurieren. Headerwerte sind nicht in Protokollen oder Statusausgabe enthalten. Verwenden Sie HTTPS, wenn Header Anmeldeinformationen enthalten, da HTTP Werte in Nur-Text sendet.
• headersProvider: Ein Objekt, das einen Befehl ausführt, um neue OTLP-Header bereitzustellen, oder false, um dynamische Header zu deaktivieren. Ein verwaltetes Hilfsprogramm überschreibt ein Benutzerhilfsprogramm, und verwaltete statische headers haben Vorrang vor der Benutzerhilfsausgabe. Diese Eigenschaft gilt für Copilot CLI. Zu Feldern und Verhalten siehe GitHub Copilot CLI-Befehlsreferenz.

Verwaltete telemetry Werte haben Vorrang vor lokalen Einstellungen, SDK-Konfiguration und Umgebungsvariablen. Wenn mehr als eine verwaltete Quelle telemetry definiert, stellt die Quelle mit der höchsten Priorität das vollständige verwaltete telemetry-Objekt bereit. Objekte aus verwalteten Quellen mit niedrigerer Rangfolge werden nicht darin zusammengeführt.

Aufnahmesteuerung

Verwenden Sie capture.identity, wenn Sie Agent-Aktivitäten attributieren müssen, ohne Eingabeaufforderungen, Antworten oder Toolinhalte zu sammeln. Verwenden Sie die anderen Aufnahmeklassen, um nur die zusätzlichen Inhalte zu sammeln, die für Ihr Audit oder Ihre Untersuchung erforderlich sind.

Feinkörnige Erfassungssteuerelemente werden in Copilot CLI, GitHub Copilot app und VS Code-Sitzungen mit Agent-Host unterstützt. VS CodeDas lokale Agent-Harness unterstützt capture.identity und die Legacy-Einstellung captureContent, wendet jedoch nicht unabhängig prompts, responses, toolArguments, toolOutput oder policyDetail an.

Die folgenden Konfigurationsattribute werden z. B. einem Benutzer und einem Computer zugeordnet, ohne Eingabeaufforderungen, Antworten, Toolinhalte oder unformatierte Richtliniendetails zu erfassen:

{
  "telemetry": {
    "capture": {
      "identity": true
    }
  }
}

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 effektive 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. Zulassungslisteneinträge sind groß- und kleinschreibungsempfindlich und auf Buchstaben, Zahlen und die Zeichen _, ., - und / beschränkt, sodass Registrierungsnamen wie microsoft/playwright-mcp akzeptiert werden. 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 kann für Unternehmensteams außer Kraft gesetzt werden. Umschließen Sie die Übereinstimmungsobjekte unter overridable auf Unternehmensebene, und verwenden Sie dann die reguläre Syntax, um Zulassungslisten und Denylisten in der Datei jedes Unternehmensteams 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 Platzhalter in der Autoritätskomponente über die /-Grenze in den Pfad zugeordnet werden.

deniedMcpServers

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 effektive 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 minimale lokale Sandkasteneinschränkungen für Copilot CLI, Copilot Agent-Hostsitzungen in VS Codeund die GitHub Copilot app. 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.

In VS Code 1.138.0 und höher gelten diese Einstellungen für Copilot Sitzungen, die den integrierten Sandkasten von Agent Host verwenden. Diese Unterstützung erstreckt sich nicht auf jede Art von Chatsitzung oder Terminal in VS Code. In VS Code 1.140.0 und höher verhindert das Festlegen von true auf sandbox.enabled, dass Benutzer die Sandkastenschaltung der Sitzung deaktivieren. Wenn Ihre Richtlinie die Umgehung zulässt, können Benutzer sie für die aktuelle Sitzung weiterhin deaktivieren, wenn Benutzer auf eine Eingabeaufforderung zur Sandkastenumgehung reagieren. Dadurch wird die Richtlinie Ihrer Organisation nicht geändert.

Für Sitzungen in der Copilot app eingebetteten Laufzeit analysiert, kombiniert und erzwingt die eingebettete Laufzeit das vollständige verwaltete sandbox-Objekt, einschließlich Eigenschaften, die in den Repositoryeinstellungen der App nicht verfügbar sind. Die App zeigt die Repositoryeinstellungen des Benutzers, nicht die vollständige effektive verwaltete Richtlinie an und zeigt keine verwalteten Sperren pro Einstellung an.

Die folgenden Untereigenschaften werden unterstützt:

• enabled: true erfordert standardmäßig eine Sandbox. Benutzer können sie nicht durch ihre Konfigurationseinstellungen oder die Option der CLI --no-sandbox deaktivieren. In der GitHub Copilot appRepositoryeinstellung und im /sandbox offBefehl können diese es nicht außer Kraft setzen. Wenn die effektive Richtlinie die Umgehung zulässt, kann ein Benutzer das Sandboxing für den Rest der aktuellen Sitzung weiterhin über eine aktive Aufforderung zur Umgehung der Sandbox-Beschränkung deaktivieren. In Copilot CLI können sie auch /sandbox disable für diese nur für diese Sitzung geltende Opt-out-Möglichkeit verwenden. Keines von beiden ändert die gespeicherte Richtlinie.
• failIfUnavailable: true macht in Kombination mit enabled: true die verwaltete Sandbox obligatorisch. Wenn Copilot die Sandbox-Richtlinie nicht mit einem verfügbaren Sandbox-Backend validieren, kompilieren oder durchsetzen kann, blockiert es stattdessen die Ausführung des Modells und der Tools, anstatt zuzulassen, dass Befehle fehlschlagen oder ohne Sandbox ausgeführt werden. Diese Eigenschaft aktiviert Sandboxing nicht von selbst.
• allowBypass: false verhindert, dass einzelne Befehle außerhalb der Sandbox ausgeführt werden, und dass Benutzer das Sandboxing für den Rest der aktuellen Sitzung über eine aktive Berechtigungsabfrage zum Umgehen der Sandbox deaktivieren. In Copilot CLI wird außerdem verhindert, dass Benutzer das Sandboxing mit /sandbox disable deaktivieren.
• addCurrentWorkingDirectory: false verhindert, dass die Laufzeit automatisch das aktuelle Arbeitsverzeichnis zu den Lese-/Schreibpfaden der Sandbox hinzufügt.
• sandboxMcpServers: true Erfordert, dass lokale MCP-Server, die in der Sitzung gestartet wurden, im Sandkasten ausgeführt werden. Remote-MCP-Server werden nicht im lokalen Sandkasten ausgeführt.
• sandboxLspServers: true, erfordert, dass die in der Sitzung gestarteten Sprachserver in der Sandbox ausgeführt werden.
• auth.git: false verhindert, dass die Laufzeit ein GitHub Token für authentifizierte Git-HTTPS-Vorgänge im Sandkasten einfügt.
• auth.gh: false verhindert, dass die Laufzeit ein GitHub-Token für GitHub CLI in die Sandbox injiziert.
• 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.
• learningMode: Steuert, ob Sandkastenbefehle auf unterstützten Windows-Hosts blockierten Zugriff protokollieren oder protokollieren und zulassen. Siehe sandbox.learningMode.
• userPolicy: Ein Objekt, das Dateisystem-, Netzwerk- und macOS-spezifische Seatbelt-Einschränkungen konfiguriert. Die unterstützten Eigenschaften werden in den folgenden Abschnitten beschrieben.

Auf einem nicht unterstützten CLI-Host kann die serververwaltete enabled: true Verwaltung abgelehnt werden, es sei denn, failIfUnavailable: true ebenfalls eine Erzwingung erfordert. Native MDM-, dateibasierte verwaltete Einstellungen und Policy-Helper-Einstellungen erzwingen enabled: trueweiterhin, sodass Sandbox-Befehle fehlschlagen, anstatt ohne Sandbox ausgeführt zu werden. Wenn sowohl enabled als auch failIfUnavailable erforderlich sind, blockiert das CLI-Modell und die Toolausführung, wenn die Erzwingung nicht hergestellt werden kann. Beheben Sie das gemeldete Host- oder Richtlinienproblem, und starten Sie dann eine neue Sitzung.

Für serververwaltete Überschreibungen von Enterprise-Teams das gesamte Sandbox-Objekt in overridable einschließen:

{
  "sandbox": {
    "overridable": {
      "enabled": true,
      "allowBypass": false
    }
  }
}

Der Wrapper muss die einzige Eigenschaft sein, die sich direkt in sandbox befindet. Einzelne Untereigenschaften, wie z. B. sandbox.enabled, können keine eigenen overridable-Wrapper verwenden. Das reguläre Sandbox-Objekt einer Enterprise-Teamdatei ersetzt die gesamte umhüllte Standardkonfiguration. Schließen Sie daher jede Einschränkung ein, die beibehalten werden soll. Beim Weglassen von sandbox bleibt der Unternehmensstandard erhalten.

sandbox.learningMode

Steuert die Zugriffsaufzeichnung für in einer Sandbox ausgeführte Befehle unter Windows. Diese Einstellung hat keine Auswirkung, wenn Sandboxing deaktiviert ist oder der Windows-Host keine Zugriffsaufzeichnung unterstützt.

• "deny" (default): Erzwingt Dateisystem- und Prozesseinschränkungen und protokolliert blockierte Zugriffe.
• "allow": Zeichnet auf und ermöglicht Dateisystem- und Prozesszugriff, der andernfalls blockiert würde. Netzwerkeinschränkungen bleiben bestehen. Dieser Modus bietet keinen normalen Dateisystem- und Prozessschutz.

Der "allow" Wert wird nur über die systemeigene Windows Geräteverwaltung wie Intune oder die Windows Registrierung akzeptiert. Es wird ignoriert in managed-settings.json. Ein "deny" Wert aus einer beliebigen verwalteten Quelle hat Vorrang.

sandbox.userPolicy.filesystem

Konfiguriert den Dateisystemzugriff für Sandkastenprozesse. Pfade sollten absolut sein. Listen mit verwalteten Zuweisungen 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 Pfadzuweisungen, 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 schränkt den lokalen Netzwerkzugriff ein. Die Auswirkungen auf in einer Sandbox ausgeführte Befehle unterscheiden sich je nach Betriebssystem. Windows Proxy- und Hostregeln erfordern lokalen Netzwerkzugriff, sodass eine Richtlinie, die sie mit false kombiniert, verhindert, dass diese Befehle gestartet werden.
• allowedHosts: Ein Array von Hostnamen oder IP-Adressen, die Sandkastenprozesse erreichen dürfen. Eine nicht leere Liste blockiert Hosts, die nicht übereinstimmen. Einträge können genaue Hostnamen, genaue IP-Adressen, *.example.com für Unterdomänen, aber nicht für die Stammdomäne, oder * für jeden Host sein. Fügen Sie keine URLs oder Ports ein. Benutzer- und verwaltete Allowlists werden restriktiv kombiniert. Wenn sie keine überlappenden Hosts haben, werden alle Hosts abgelehnt.
• blockedHosts: Ein Array von Hostnamen oder IP-Adressen, die sandkastenbasierte Prozesse nicht erreichen können. Blockierte Hosts haben Vorrang vor zulässigen Hosts, und das Blockieren einer Domäne blockiert auch ihre Unterdomänen.
• proxy: Ein Objekt, das sandkastenbasierten Netzwerkdatenverkehr über einen upstream-HTTP-Proxy leitet. Legen Sie proxy.url auf die Proxy-URL fest. Plattformunterstützung und Durchsetzung variieren.

In Copilot CLI, Hostregeln und Upstreamproxys verwenden einen integrierten lokalen Proxy. Unter macOS und Linux verhindert der Sandkasten, dass Programme den Sandkasten mit direkten Verbindungen umgehen. Unter Windows basiert die Sandbox darauf, dass Programme die Proxy-Einstellungen berücksichtigen. Daher bieten diese Steuerelemente in Windows nicht den gleichen Schutz vor direkten Verbindungen. Informationen zu Plattformanforderungen und -einschränkungen finden Sie unter Konfigurieren von Netzwerkeinstellungen.

sandbox.userPolicy.seatbelt

Konfiguriert macOS-spezifische Sitzgurtoptionen.

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

Erzwingung der Mindestversion des Clients für sandbox

Wenn Sie den sandbox Schlüsselnamen zu verwalteten Einstellungen hinzufügen, Copilot einen lokalen Sandkasten für alle Benutzer im Bereich erzwingt. Diese Benutzer müssen eine Copilot Clientversion verwenden, die die lokale Sandbox unterstützt. Bis ein Benutzer seinen Client mindestens auf die mindestens unterstützte Version aktualisiert, werden seine Verbindungen zu Copilot blockiert.

Unterstützter Client	Mindestversion
VS Code
1.141.0
Copilot CLI
1.0.93
GitHub Copilot App
1.1.26