Manage AI settings in enterprise environments

VS Code provides AI-powered development capabilities through GitHub Copilot, including agent mode, MCP servers, and chat tools. Organizations can centrally manage these features to control AI behavior, enforce security policies, and maintain compliance across their development teams.

This article covers the AI-related settings that IT admins can manage through enterprise policies.

Users can control the functionality and behavior of AI features through VS Code settings. Organizations can enforce specific configurations by deploying enterprise policies via device management solutions. These policies override user-configured settings on managed devices.

Learn how to deploy policies for VS Code to your organization's devices.

Deploy Copilot managed settings

Copilot managed settings are a centrally-managed governance layer that applies the same configuration across VS Code and GitHub Copilot CLI. Most managed settings map to a VS Code enterprise policy and override the corresponding user setting on managed devices. Runtime-owned settings, such as granular Agent Host permissions, are enforced directly by the Copilot runtime.

Managed settings differ from the VS Code enterprise policies that you deploy with ADMX templates or configuration profiles. Managed settings use Copilot-specific delivery channels and a Copilot-specific configuration shape, so a single definition governs both VS Code and Copilot CLI.

VS Code reads managed settings from three delivery channels. Choose the channel that fits how you manage devices:

• Native MDM - deliver settings through the Windows Registry or macOS managed preferences with an MDM solution such as Microsoft Intune.
• Server-managed - resolve settings from the developer's signed-in GitHub account, configured by your GitHub enterprise or organization admin.
• File-based - place a managed-settings.json file on disk, for use with configuration-management tools such as Chef, Puppet, or Ansible.

All three channels use the same managed setting keys and values. For the list of available keys and the VS Code settings they map to, see Available managed settings.

Precedence across channels

For most managed settings, VS Code resolves values per key. When multiple channels provide the same key, the value from the highest-precedence channel wins. Keys that the higher-precedence channel does not provide are filled in from lower-precedence channels.

The precedence order is:

1. Native MDM
2. Server-managed
3. File-based

For example, native MDM can configure permissions.disableBypassPermissionsMode while the server configures enabledPlugins. VS Code applies both keys. If native MDM also configures enabledPlugins, the native MDM value wins for that key.

The telemetry block is resolved atomically instead of per key. VS Code uses the complete block from the highest-precedence channel that supplies one and doesn't fill omitted fields from lower-precedence channels. For example, if native MDM supplies telemetry.enabled but omits telemetry.endpoint, a server-managed endpoint isn't applied.

Sandbox controls preserve restrictions from every managed channel instead:

• sandbox.enabled: true from any channel requires sandboxing, even if another channel supplies false.
• sandbox.allowBypass and sandbox.userPolicy.network.allowOutbound: false from any channel takes precedence over true from another channel.

After resolving these managed values, the runtime also accounts for developer preferences. See Configure agent sandboxing.

Precedence with VS Code device policies

Copilot managed settings and VS Code enterprise policies use separate delivery systems. A managed setting maps to a VS Code policy. If both systems provide the same policy, the Copilot managed setting takes precedence. The values are not merged.

For example, if the ChatAllowedMcpServers policy is configured through both the VS Code ADMX policy and the allowedMcpServers Copilot managed setting, VS Code uses the managed setting value. If allowedMcpServers is not configured through managed settings, the ADMX policy value remains in effect.

Deliver managed settings through native MDM

On Windows and macOS, VS Code reads Copilot managed settings from OS-level managed preferences. Deliver them through your MDM solution, the same way you deliver other device policies.

Scalar settings use their dot-separated key directly (for example, permissions.disableBypassPermissionsMode). Structured settings (for example, enabledPlugins) are provided as a JSON string value.

Deliver managed settings from a file

VS Code can read Copilot managed settings from a managed-settings.json file on disk. Use this option when your organization manages devices with configuration-management tools, such as Chef, Puppet, or Ansible, and does not use Mobile Device Management (MDM).

Place managed-settings.json in the well-known location for each operating system:

The file uses the Copilot managed settings shape. The following example configures permissions for Copilot sessions that use Agent Host:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "allow": ["Read(/src/**)", "Shell(git status)"],
    "ask": ["Write(/src/**)", "Shell(git push *)"],
    "deny": ["Read(~/.config/secret.txt)", "Write(/.github/workflows/**)"]
  }
}

Deliver managed settings from the server

When developers sign in with a GitHub account, VS Code resolves managed settings that your GitHub enterprise or organization admin configures in copilot/managed-settings.json. Because these settings travel with the account, they apply across the developer's devices without local device management.

Server-managed settings are configured on the GitHub side. For more information, see Manage Copilot for your enterprise in the GitHub documentation.

Configure Agent Host permissions

Use permissions.allow, permissions.ask, and permissions.deny to control file, shell, and network operations. These settings apply only to users who receive Copilot enterprise managed settings and to Copilot sessions that use Agent Host.

Permission rules use the following precedence:

• deny blocks a matching operation with no approval option.
• ask requires fresh human approval, even when another setting would automatically approve the operation.
• allow lets a matching operation proceed without a prompt.

The rules support Shell, Read, Edit or Write, and Domain selectors. For paths, / represents the workspace root, ~/ represents the user's home directory, and ** includes nested directories.

For the complete selector grammar, matching behavior, and configuration examples, see the GitHub Copilot enterprise managed settings reference.

Verify applied managed settings

You can verify the applied values with the Developer: Policy Diagnostics command. The report shows the effective policy value and its source. For managed settings, it also shows how each key resolves across the native MDM, server-managed, and file-based channels. The report shows only the effective VS Code policy value, not a device policy value that another source replaced. For more information, see Verify policy enforcement.

Restrict AI features to approved GitHub organizations

Organizations can require developers to be signed in to a GitHub account that belongs to an approved organization before AI features in VS Code are activated. This enables enterprises to ensure that account-level policies set by their GitHub organization (for example, Copilot content exclusions or model availability) are in effect before chat, agents, or inline suggestions become available.

To enable this restriction, set the ChatApprovedAccountOrganizations policy to a JSON array of GitHub organization logins. For example, ["contoso", "contoso-research"]. Use the wildcard value ["*"] to allow any signed-in GitHub account.

When the policy is set, AI features are gated until both of the following are true:

• The user is signed in to a GitHub account that is a member of one of the approved organizations.
• Account-level policy data has resolved.

When the policy is not set, AI features are not restricted by this gate.

This policy is fail-closed: if the user is not signed in, is signed in with a non-GitHub account, or is signed in to a GitHub account that does not belong to an approved organization, AI features remain disabled.

IT admins can verify the gate state at any time with the Developer: Policy Diagnostics command, which includes an Account Policy Gate section. For more information, see Verify policy enforcement.

Require a minimum version for AI features

An organization can require a minimum VS Code version before developers use AI features. This helps ensure that managed devices receive security or governance improvements, such as newer sandboxing protections, without blocking unrelated editor work.

When the installed version doesn't meet the requirement:

• Chat shows the required and installed versions and provides the appropriate update action.
• The editor window shows a banner even when Chat is closed. Other editor features remain available.
• The Agents window shows a blocking notice with an Open Editor Window action.

The update action reflects the current installation state, such as Check for Updates, Download Update, Install Update, or Restart to Update. If built-in updates are disabled by policy, the notice directs the developer to contact an administrator. AI features become available after the installed version meets the requirement.

Set a default chat model

Organizations can set a default model that applies to every new conversation, so developers start from an approved model without configuring it themselves.

To set the default model, set the ChatDefaultModel policy. This configures the chat.defaultModel Open in VS Code Open in VS Code Insiders setting in VS Code. You can also deliver it through Copilot managed settings with the model key.

The value accepts one of the following:

• auto - let Copilot pick the model.
• A model family name, such as opus or gemini - resolves to the latest available version in that family.
• A full model ID.

New conversations start at the configured model across the chat panel and the Agents window. Developers can still switch models within a conversation, and an explicit choice is never overridden by the configured default. Reopened conversations keep their own saved model. When the setting is not configured, model selection behavior is unchanged.

Set a default Auto tier

When the default model is Auto, set the autoTier Copilot managed setting to choose how new chats initially optimize model routing:

• efficiency favors lower AI credit consumption.
• balance balances capability and credit consumption.
• intelligence favors more capable models for complex tasks.

The managed tier applies to new chats in the Local harness and the Copilot Agent Host on the same machine. It appears as Default in the model picker's Optimize for menu.

The tier is a starting point rather than a restriction. Developers can select another tier, and VS Code preserves explicit and restored choices when the managed tier changes or is removed.

Enable or disable the use of agents

Agents enable the AI to autonomously perform tasks like editing files, running terminal commands, and using tools. Agents enable developers to provide a high-level requirement and have the AI assistant analyze, plan, and execute the necessary steps to achieve that goal.

To disable agents entirely, set the ChatAgentMode policy to false. This configures the chat.agent.enabled Open in VS Code Open in VS Code Insiders setting in VS Code.

The Agent option will not be available in the agents dropdown in the Chat view when this policy is applied. Developers can still use ask or edit for code explanations and file edits, but autonomous code generation and task execution are not available.

Control dictation data

Built-in dictation converts speech to text in chat, editors, and terminals. Organizations can use enterprise policies to control whether dictation audio and transcripts leave the developer's device.

To keep dictation audio on the device, set DictationModel to nemotron-3.5-asr-streaming-0.6b. Developers can continue using dictation on supported desktop platforms. In VS Code for the Web, where on-device transcription is not supported, this policy makes dictation unavailable.

To also prevent transcript text from being sent to a Copilot model, set DictationLLMCleanup to false. The final transcript does not receive language-model cleanup.

These policies help organizations meet data-handling requirements. For more information about local and cloud processing, see dictation privacy.

Enable or disable hooks

Hooks enable you to execute custom shell commands at key lifecycle points during agent sessions, such as before or after tool invocations, at session start, or when an agent stops. Hooks can automate workflows, enforce security policies, and control agent behavior.

To disable hooks in the Local harness, set the ChatHooks policy to false. This configures the chat.useHooks Open in VS Code Open in VS Code Insiders setting in VS Code. The Local harness then ignores hook configurations and does not execute hook commands.

ChatHooks applies only to the Local harness. Copilot sessions on Agent Host use the shared Copilot SDK hooks implementation, including Copilot Policy Hooks. See choose a hook implementation.

Use the SDK harness for Policy Hooks

Copilot Policy Hooks apply to sessions on the SDK harness, not to sessions that remain on Local. The SDK hooks implementation is generally available (GA), while the VS Code hooks surface remains in Preview during the transition.

To move new editor-chat sessions from Local to the SDK harness, set the ChatEditorPreferCopilotHarness device policy to true. This policy is available from VS Code version 1.134 and controls chat.editor.preferCopilotHarness Open in VS Code Open in VS Code Insiders (Experimental).

The preference selects Copilot when Local would otherwise be selected for a new editor-chat session. It does not migrate existing sessions or change explicit or remembered Claude and Codex selections. Check the session target during rollout rather than assuming that every session uses Copilot.

Before rollout, validate existing hook scripts, including scripts that depend on tool arguments or transcript formatting.

Deploy hooks through managed plugins

Use agent plugins to distribute reviewed hook scripts to developers while restricting hooks from other sources. Package the hook configuration and scripts in a plugin, publish it in your approved marketplace, and ensure the plugin is installed on the target devices.

Use these source restrictions instead of turning off hook execution or plugin integration.

Deliver the following configuration through a Copilot managed-settings channel, not through user settings or workspace plugin recommendations. Replace <your-org>/<plugin-marketplace> with your marketplace repository. The example assumes that the marketplace contains a plugin named security-hooks.

{
  "allowManagedHooksOnly": true,
  "enabledPlugins": {
    "security-hooks@company-marketplace": true
  },
  "extraKnownMarketplaces": {
    "company-marketplace": {
      "source": {
        "source": "github",
        "repo": "<your-org>/<plugin-marketplace>"
      }
    }
  },
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "<your-org>/<plugin-marketplace>"
    }
  ]
}

The controls serve different purposes:

• allowManagedHooksOnly: true allows hooks only from managed sources and plugins force-enabled by policy. Standalone user and workspace hooks, and hooks from plugins that are only user-enabled, are excluded. This setting does not itself enable or install a plugin.
• enabledPlugins["security-hooks@company-marketplace"]: true force-enables the plugin. A value of false force-disables it. An omitted plugin remains under normal user enablement, but its hooks are excluded when allowManagedHooksOnly is true.
• extraKnownMarketplaces makes the company marketplace available. It is not a source restriction by itself.
• strictKnownMarketplaces restricts plugin installation to the listed sources. It does not retroactively disable already-installed plugins. Pair source restrictions with plugin enablement and managed-hooks-only controls.

allowManagedHooksOnly is available from version 1.132. If you also need to block standalone skills, agents, instructions, and MCP servers, set strictPluginOnlyCustomization to true, also available from version 1.132. This setting accepts a Boolean, not a list of customization types. Omit it when you want to restrict hooks without blocking those other standalone customizations.

Machine-wide Policy Hooks are a separate managed hook source, not hooks installed by this plugin example. They require the SDK harness in VS Code. Plugin distribution does not give Local sessions access to SDK Policy Hooks.

Use Developer: Policy Diagnostics to verify the applied managed settings. In a test session on the intended harness, confirm that the approved plugin's hook runs and produces the expected decision, and that user, workspace, and non-managed plugin hooks do not run.

Enable or disable extension language tools

Agent tools extend the AI assistant's capabilities with specialized functions. These tools can come from built-in features, Model Context Protocol (MCP) servers, or third-party extensions.

Third-party extensions can contribute tools that integrate with chat by using the Language Model Tools API.

To prevent developers from using extension-contributed tools while still allowing built-in tools and MCP tools, set the ChatAgentExtensionTools policy to false. This configures the chat.extensionTools.enabled Open in VS Code Open in VS Code Insiders setting in VS Code.

Chat agents can also use browser tools to open and interact with web pages in the Integrated Browser. To disable browser tools for chat agents, set the BrowserChatTools policy to false. This configures the workbench.browser.enableChatTools Open in VS Code Open in VS Code Insiders setting in VS Code.

To disable agent plugin integration in chat, set the ChatPluginsEnabled policy to false. This configures the chat.plugins.enabled Open in VS Code Open in VS Code Insiders setting in VS Code.

Manage agent plugins and marketplaces

Agent plugins are prepackaged bundles of agent customizations that developers discover and install from plugin marketplaces. Organizations can centrally control which plugins and marketplaces are available, instead of having each developer configure them locally.

VS Code reads these policies from the same Copilot managed settings that drive enterprise plugin standards for Copilot CLI, so a single definition applies to both clients. You can deliver them through any of the Copilot managed settings channels.

The following policies are available:

• To force-enable or force-disable specific plugins, set the ChatEnabledPlugins policy. This configures the chat.plugins.enabledPlugins Open in VS Code Open in VS Code Insiders setting in VS Code. Keys use the plugin@marketplace form. Set a value to true to force-enable the plugin or false to force-disable it. Omitted plugins remain under normal user enablement. This policy is not an allowlist.
• To make additional plugin marketplaces available, set the ChatExtraMarketplaces policy. This configures the chat.plugins.extraMarketplaces Open in VS Code Open in VS Code Insiders setting in VS Code. This policy has no user-facing setting and can only be configured through policy.
• To restrict plugin installation to approved marketplace sources, set the ChatStrictMarketplaces policy to a list of source objects. This configures the chat.plugins.strictMarketplaces Open in VS Code Open in VS Code Insiders setting in VS Code. An empty list blocks installation from all marketplaces. The restriction does not retroactively disable already-installed plugins.

For an example that combines plugin activation, marketplace restrictions, and hook-source controls, see Deploy hooks through managed plugins.

Plugins that are blocked by policy remain visible in the Extensions view but appear disabled. Marketplaces that are managed by policy are tagged as such in the marketplace picker.

IT admins can verify the applied plugin policies with the Developer: Policy Diagnostics command, which includes a Managed Settings section. For more information, see Verify policy enforcement.

Configure MCP server access

Model Context Protocol (MCP) servers extend chat with external tools and services. Organizations can control which MCP servers developers can use through both GitHub organization settings and VS Code policies.

Restrict MCP server sources

The ChatMCP policy controls which sources MCP servers can be installed from. This configures the chat.mcp.access Open in VS Code Open in VS Code Insiders setting in VS Code.

The following values are supported:

Configure a custom MCP registry

You can host a private MCP server registry for your organization and configure VS Code to use it through the McpGalleryServiceUrl policy. This enables you to:

• Provide a curated list of approved MCP servers
• Host internal MCP servers for your organization
• Block access to the public GitHub MCP registry

When configured, developers see MCP servers from your custom registry in the Extensions view when they enter @mcp in the search field.

Organizations with GitHub Copilot Enterprise or Business can also configure MCP server access through GitHub organization settings.

Allow or deny individual MCP servers

Use Copilot managed settings or the corresponding VS Code enterprise policies to control individual MCP servers:

Match servers by configured name, remote URL, or local command invocation. URL entries support * wildcards. Command entries must include the exact command and arguments.

The following managed-settings.json example allows an internal server by name and another by URL, while blocking a specific local command:

{
  "allowedMcpServers": [
    {
      "serverName": "contoso-tools"
    },
    {
      "serverUrl": "https://mcp.contoso.com/*"
    }
  ],
  "deniedMcpServers": [
    {
      "serverCommand": ["/usr/local/bin/legacy-mcp", "--stdio"]
    }
  ],
  "allowManagedMcpServersOnly": true
}

Configure agent tool approvals

Agent tools can perform actions that modify files, run commands, or access external services. VS Code includes approval prompts for potentially risky operations. Organizations can enforce stricter approval requirements or disable auto-approval entirely.

Learn more about tool approval in VS Code.

Disable global auto-approval

The ChatToolsAutoApprove policy controls the global auto-approval setting. When enabled, the AI assistant can execute all tools without manual approval. This is not recommended for security reasons.

To prevent developers from enabling global auto-approval, set the ChatToolsAutoApprove policy to false. This configures the chat.tools.global.autoApprove Open in VS Code Open in VS Code Insiders setting in VS Code and also hides the Assisted permissions Assisted permissions is experimental and might change or be removed. and Allow all options from the permissions picker, and the Autopilot mode, in the Chat view.

Require manual approval for specific tools

The ChatToolsEligibleForAutoApproval policy controls which tools can be auto-approved. Tools set to false always require manual approval and cannot be auto-approved by users.

Configure this policy with a JSON object that lists tool names and their approval eligibility. This configures the chat.tools.eligibleForAutoApproval Open in VS Code Open in VS Code Insiders setting in VS Code.

The following JSON snippet shows an example configuration that requires manual approval for task execution, URL fetching, and terminal commands:

{
  "runTask": false,
  "fetch": false,
  "runInTerminal": false
}

Configure terminal auto-approval

The ChatToolsTerminalEnableAutoApprove policy specifically controls the rule-based auto-approval system for terminal commands. When enabled, VS Code applies a set of rules to automatically approve safe commands while prompting for potentially dangerous ones.

To disable terminal auto-approval entirely, set the policy to false. This configures the chat.tools.terminal.enableAutoApprove Open in VS Code Open in VS Code Insiders setting in VS Code.

Configure agent sandboxing

Use agent terminal sandboxing to restrict the files and network resources that agent-executed commands can access. Enforcing this boundary lets developers run commands within an approved scope, including when they use auto-approval or Autopilot. Sandboxing does not restrict built-in file tools or replace approval controls for other tools.

Choose the management mechanism for the sessions you need to govern:

Check the platform prerequisites and lifecycle status before deployment. The Copilot Agent Host built-in shell's sandbox support is Experimental.

Deploy Copilot managed sandbox settings

Deploy the following configuration through a Copilot managed settings channel. For file-based delivery, add this sandbox object to the managed settings file, preserving other organization settings. Use the nested JSON shape, not VS Code setting names.

{
  "sandbox": {
    "enabled": true,
    "allowBypass": false,
    "userPolicy": {
      "network": {
        "allowOutbound": false
      }
    }
  }
}

This example requires sandboxing in Copilot Agent Host sessions, prevents bypass, and blocks outbound network access from sandboxed commands. It does not block network access by other agent tools. Configure those tools separately.

These runtime-owned controls do not map directly to VS Code device policies. After resolving values across managed channels, they combine with developer preferences as follows:

Permitting bypass does not let developers directly switch off a required sandbox. A supported Allow in this Session approval must succeed first. See the developer guidance for organization-managed sandboxing.

These managed values do not overwrite saved user preferences. When you remove a restriction, the corresponding setting becomes editable and shows the developer's saved value. A new restriction also applies when a developer resumes an existing session and revokes any incompatible session-scoped bypass.

Configure VS Code sandbox policies

Use your existing device policy deployment mechanism to configure these policies:

Verify sandbox restrictions

1. After changing managed sandbox settings, fully quit and reopen VS Code, then start or resume a Copilot Agent Host session.
2. Run Developer: Policy Diagnostics to verify the delivered managed values and their sources.
3. Check the sandbox settings in the Settings editor. Enforced values show an organization-managed indicator. Managed restrictions do not overwrite saved preferences, and the editor does not display every runtime-composed file system rule.
4. In a Copilot Agent Host session, inspect the effective sandbox policy to confirm the session's actual state and file system and network restrictions.

If a sandbox configuration update conflicts with managed policy, the session continues with the last configuration that the runtime successfully applied. The rejected update does not take effect, and VS Code does not retry with weaker restrictions. Inspect the effective session policy rather than assuming a requested change was applied.

Configure agent network filtering

Network filtering restricts which domains the fetch tool and integrated browser can access during chat sessions. For terminal commands, domain filtering is available in Local sessions and the Agent Host custom terminal tool on macOS and Linux when sandbox network isolation is enabled.

The Copilot Agent Host built-in shell and the Windows terminal sandbox do not use domain allowlists or denylists. Their sandbox network control permits or blocks outbound access as a whole. See Configure sandbox network access.

Enable network filtering

The ChatAgentNetworkFilter policy enables network domain filtering for agent tools. This configures the chat.agent.networkFilter Open in VS Code Open in VS Code Insiders setting in VS Code.

When the policy is set to true, network access by agent tools is restricted according to the allowed and denied domain lists. When set to false (the default), no network filtering is applied.

When both domain lists are empty and the filter is enabled, all network access by agent tools is blocked.

For Local sessions on macOS and Linux, configure these policies to deny network access by default for the fetch tool, integrated browser, and sandboxed terminal commands:

Configure allowed domains

The ChatAgentAllowedNetworkDomains policy controls which domains agent tools are permitted to access. This configures the chat.agent.allowedNetworkDomains Open in VS Code Open in VS Code Insiders setting in VS Code.

Provide a list of domain patterns. Wildcards are supported, for example *.example.com. An empty list blocks all domains for tools with network filtering enabled and for terminal commands that use sandbox domain filtering.

Configure denied domains

The ChatAgentDeniedNetworkDomains policy controls which domains agent tools are blocked from accessing. This configures the chat.agent.deniedNetworkDomains Open in VS Code Open in VS Code Insiders setting in VS Code.

Use this policy to block exceptions to the allowed domain list. Denied domains always take precedence over allowed domains. Wildcards are supported, for example *.example.com. You do not need to specify denied domains when the allowed domain list is empty because all domains are already blocked.

Configure Copilot code review

Copilot code review enables AI-powered review of code changes. Organizations can control access to these features.

The CopilotReviewSelection policy controls whether developers can request code review for selected code in the editor. This configures the github.copilot.chat.reviewSelection.enabled Open in VS Code Open in VS Code Insiders setting in VS Code.

The CopilotReviewAgent policy controls access to the Copilot code review agent for reviewing pull requests and changed files. This configures the github.copilot.chat.reviewAgent.enabled Open in VS Code Open in VS Code Insiders setting in VS Code.

Configure next edit suggestions

Next edit suggestions (NES) propose a next edit based on recent changes, helping developers apply repetitive or related modifications more quickly.

To disable next edit suggestions, set the CopilotNextEditSuggestions policy to false. This configures the github.copilot.nextEditSuggestions.enabled Open in VS Code Open in VS Code Insiders setting in VS Code.

Enable or disable Claude Agent

Claude Agent sessions let developers start and resume agentic coding sessions powered by Anthropic's Claude Agent SDK directly in the editor, using their existing Copilot subscription.

To disable Claude Agent sessions, set the Claude3PIntegration policy to false. This configures the github.copilot.chat.claudeAgent.enabled Open in VS Code Open in VS Code Insiders setting in VS Code.

Configure organization-level AI customizations

GitHub Copilot supports defining custom instructions and custom agents at the GitHub organization level. These customizations are automatically available to all organization members when they work in VS Code on repositories owned by the organization.

Organization-level custom instructions

Organization administrators can define custom instructions that apply to all repositories in their organization. These instructions ensure consistent AI behavior across teams, such as enforcing coding standards, security guidelines, or documentation requirements.

When developers have github.copilot.chat.organizationInstructions.enabled Open in VS Code Open in VS Code Insiders set to true, VS Code automatically detects and applies organization-level instructions to all chat requests. The instructions appear in the Chat Instructions menu alongside personal and workspace instructions.

Learn how to add custom instructions for your organization in the GitHub documentation.

Organization-level custom agents

Organizations can also define custom agents that are shared across all repositories. These agents provide specialized AI personas with specific tools and instructions tailored to your organization's workflows.

When developers have github.copilot.chat.customAgents.showOrganizationAndEnterpriseAgents Open in VS Code Open in VS Code Insiders set to true, organization-level agents appear in the Agents dropdown alongside built-in and personal agents.

Learn how to create custom agents for your organization in the GitHub documentation.

Configure telemetry export with OpenTelemetry

Organizations can mandate where Copilot sends OpenTelemetry (OTel) data, so that telemetry flows to an approved collector without each developer setting OTEL_* environment variables. Managed telemetry configuration applies to both the Copilot Chat extension and the agent host process.

Deliver these settings through the telemetry block in Copilot managed settings. Each field maps to a VS Code policy and, where applicable, a product setting:

Identity capture is off by default and independent of content capture. When enabled, Local harness sessions add user.name to agent invocation spans, including subagent and inline chat spans, and add process.user.name and host.name as resource attributes.

The managed identity value takes precedence over COPILOT_OTEL_CAPTURE_IDENTITY and user settings. When a managed value denies identity capture, later exports omit identity without requiring a reload, including identity attributes that were configured explicitly as resource attributes.

For other telemetry fields, managed values override user settings. In the Copilot Chat extension, OTel environment variables can still override managed values, except that managed telemetry.resourceAttributes take precedence over OTEL_RESOURCE_ATTRIBUTES. Remove other conflicting OTel environment variables from managed devices to ensure that the enterprise configuration takes effect.

For chat sessions that use the Local harness, if an enterprise-managed OTel configuration enables export after Copilot Chat starts, VS Code automatically attempts to restart the extension hosts for the current window once. The restart can interrupt work in other extensions. If the restart is blocked or doesn't apply the configuration, VS Code offers Reload Window. Later policy changes and policy removal also require a manual reload.

The agent host computes its telemetry configuration when it starts. If a managed telemetry value changes after the agent host has started, reload VS Code to apply it.

Security considerations

AI-powered development features can autonomously perform actions with user-level permissions. Refer to the security documentation for a comprehensive overview of AI security considerations and best practices.

For environments where agents operate with elevated autonomy (auto-approval or Autopilot mode), recommend that developers use agent terminal sandboxing or work inside a dev container to limit the impact of unintended or malicious actions.

Agent deployment options and data residency

Agents can run on different infrastructure depending on the agent type, and each option has different data residency and access control characteristics:

• Local agents and the Copilot agent run on the developer's machine and process data locally.
• Cloud agents run on GitHub's infrastructure. Code and conversation data are subject to the GitHub Copilot data handling policies.

For GitHub Copilot's security, privacy, compliance, and transparency information, see the GitHub Copilot Trust Center FAQ.

Available managed settings

The following managed settings are available. Most keys map to a VS Code policy and the setting it controls. For full details on each policy's accepted values and behavior, see the enterprise policy reference.

Related resources

• Enterprise policies reference - Complete list of enterprise policies
• Use tools with agents - Learn how tools work in VS Code chat
• MCP servers in VS Code - Configure and use MCP servers
• Custom instructions - Define custom instructions for AI responses
• Custom agents - Create custom AI personas and workflows
• AI security considerations - Security best practices for AI features
• GitHub Copilot Trust Center FAQ - Security, privacy, and compliance information