From 2ec9a5405614745b86a38963516a746a972cbdbf Mon Sep 17 00:00:00 2001 From: Thomas Chavas Date: Wed, 26 Aug 2026 18:35:38 +0000 Subject: [PATCH 1/5] Note that full-range IP allow list entries are not accepted (#62903) --- .../about-adding-ip-allow-list-entries.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/data/reusables/identity-and-permissions/about-adding-ip-allow-list-entries.md b/data/reusables/identity-and-permissions/about-adding-ip-allow-list-entries.md index d17ba8b17065..421c78b0676c 100644 --- a/data/reusables/identity-and-permissions/about-adding-ip-allow-list-entries.md +++ b/data/reusables/identity-and-permissions/about-adding-ip-allow-list-entries.md @@ -1,3 +1,5 @@ You can create an IP allow list by adding entries that each contain an IP address or address range. After you finish adding entries, you can check whether a particular IP address would be allowed by any of the enabled entries in your list. +You cannot add a range that covers the entire address space, such as `0.0.0.0/0` or `::/0`, because it would allow access from any IP address. To allow access from anywhere, disable the IP allow list instead. + Before the list restricts access to private assets owned by organizations in your enterprise, you must also enable allowed IP addresses. From 4390ed9abfffc6406737dd3e2abd19fbf058160f Mon Sep 17 00:00:00 2001 From: Evan Bonsignori Date: Wed, 26 Aug 2026 19:24:27 +0000 Subject: [PATCH 2/5] Remove divider under sidebar product title (#62867) --- src/frame/components/sidebar/SidebarNav.tsx | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/frame/components/sidebar/SidebarNav.tsx b/src/frame/components/sidebar/SidebarNav.tsx index 689582bf098a..210a435ff86a 100644 --- a/src/frame/components/sidebar/SidebarNav.tsx +++ b/src/frame/components/sidebar/SidebarNav.tsx @@ -52,9 +52,7 @@ export const SidebarNav = ({ variant = 'full', mobileOpen = false }: Props) => { aria-label="Documentation navigation" > {variant === 'full' && currentProduct && ( -
+
{showCurrentProductLink && (

Date: Wed, 26 Aug 2026 20:01:43 +0000 Subject: [PATCH 3/5] Default availability policy for models takes effect (#62888) Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Laura Coursen --- .../concepts/models/default-availability.md | 10 +---- .../manage-availability-of-default-models.md | 39 ++++++++++--------- .../manage-default-models.md | 12 ++---- .../model-autoenablement-excluded-models.md | 14 +------ .../reusables/copilot/model-autoenablement.md | 6 +-- 5 files changed, 28 insertions(+), 53 deletions(-) diff --git a/content/copilot/concepts/models/default-availability.md b/content/copilot/concepts/models/default-availability.md index 41aaed3cc99b..16ae99c2a74b 100644 --- a/content/copilot/concepts/models/default-availability.md +++ b/content/copilot/concepts/models/default-availability.md @@ -13,15 +13,7 @@ redirect_from: - /copilot/concepts/models/automatic-enablement --- -On {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %} plans, the **Default availability for released models** policy will control whether unconfigured generally available (GA) models default to enabled or disabled. If this policy is enabled, users will benefit from the latest models without the need for administrator intervention. - - - -To give you time to prepare, this policy can be configured but **does not currently affect model availability**. On August 26, 2026, new GA models and existing unconfigured GA models will automatically follow the default set in the policy. These models will be relabeled as "inherits default" in the UI. - -To prepare for this change, you can disable the policy or explicitly disable models you don't want to be enabled. - - +For enterprises with {% data variables.copilot.copilot_business_short %} or {% data variables.copilot.copilot_enterprise_short %} plans, the **Default availability for released models** policy controls whether unconfigured generally available (GA) models default to enabled or disabled. If this policy is enabled, users benefit from the latest models without the need for administrator intervention. ## Which models follow the policy? diff --git a/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-availability-of-default-models.md b/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-availability-of-default-models.md index c45915a1a1b5..a38911d23835 100644 --- a/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-availability-of-default-models.md +++ b/content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-availability-of-default-models.md @@ -12,21 +12,16 @@ allowTitleToDifferFromFilename: true As an enterprise owner, you can manage which {% data variables.product.prodname_copilot_short %} models are available to people in your enterprise. -An enterprise owner can enable or disable models for everyone in the enterprise. Alternatively, there are two different modes for controlling granular access to models: organizations and enterprise teams. +You can enable or disable models for everyone in the enterprise. On top of this baseline, there are two different modes for controlling additional granular access to models: through organizations, or through enterprise teams. -By default, models that are set to "optional" at the enterprise level are available for organizations to set to enabled or disabled. Enterprise owners can also create model rules to enable or disable models in organizations directly. - -> [!IMPORTANT] {% data reusables.copilot.model-autoenablement %} - -## About the enterprise teams model access preview - -As an opt-in preview, enterprises can switch to controlling granular model access exclusively through enterprise teams. This gives you more control over model access based on business needs, roles, or levels of training. +* In the default experience, enterprise owners can delegate decisions for each model to organizations. Organization owners can then set the model to enabled or disabled. Enterprise owners can also create model rules to enable or disable models in organizations directly. +* As an opt-in preview, enterprises can switch to controlling granular model access exclusively through enterprise teams. This gives you more control over model access based on business needs, roles, or levels of training. ## Setting a baseline for model access -Regardless of whether you are opted in to the preview, you should explicitly configure all models that should be either enabled or disabled for everyone. For example, everyone in your company might get access to vetted, low-cost models, whereas some models might be disabled everywhere for compliance reasons. +Regardless of whether you are opted in to the enterprise teams preview, you should explicitly configure all models that should be either enabled or disabled for everyone. For example, everyone in your company might get access to vetted, low-cost models, whereas some models might be disabled everywhere for compliance reasons. -This sets a baseline that you can add to with more granular controls. For models that only some people should get access to, set them to "optional." Then, you will be able to grant access to specific organizations or enterprise teams, depending on your settings. +This sets a baseline that you can add to with more granular controls. For models that only some people should get access to, you will delegate the model setting to organizations or enterprise teams, depending on which experience you're using. {% data reusables.enterprise-accounts.access-enterprise %} {% data reusables.enterprise-accounts.ai-controls-tab %} @@ -34,15 +29,23 @@ This sets a baseline that you can add to with more granular controls. For models {% data reusables.enterprise-accounts.configure-allowed-models %} 1. Select a status for each model in the list: - * **Enabled**: Enabled for everyone. - * **Disabled**: Explicitly disabled for everyone. - * **Optional**: You can choose whether to enable the model for specific organizations or enterprise teams. + * **Enabled** for everyone. + * **Disabled** for everyone. + * **Delegate** the decision to organizations or enterprise teams and apps. + +### Checking for unconfigured models + +{% data reusables.copilot.model-autoenablement %} + +These models are labeled as "Delegate to Default Policy" in your model settings. If the "Default availability" policy is enabled, these models will be available for everyone. + +If you are not happy with any of these settings, you can disable specific models, make them available only for specific organizations or teams, or disable the "Default availability" policy so unconfigured models default to disabled. ## Granting access to specific organizations (default) This section applies if you are **not** opted in to the enterprise teams model access preview. -To allow each organization to make its own decision about a model, set it to **Optional** in your enterprise's model list. Organization owners can then choose whether to enable or disable the model. If left unconfigured by an organization, the model will follow the organization's **Default availability for released models** policy setting. +To allow each organization to make its own decision about a model, select **Delegate to Organizations** in your enterprise's model settings. Organization owners can then choose whether to enable or disable the model. If left unconfigured by an organization, the model will follow the organization's **Default availability for released models** policy setting. As an alternative to delegating control to organizations, targeted model rules let you control exactly which models are available to specific organizations, giving you more granular control than the enterprise-wide availability settings. @@ -55,7 +58,7 @@ As an alternative to delegating control to organizations, targeted model rules l ## Granting access to enterprise teams (opt-in preview) -Once you are opted in to the preview, organization-level model settings will be deactivated. Organization owners can no longer manage model policies. Instead, individual models can be enabled for specific enterprise teams. +When you opt in to the preview, organization-level model settings are deactivated. Organization owners can no longer manage model policies. Instead, individual models can be enabled for specific enterprise teams. You can roll back from enterprise teams mode while the feature is in preview. This returns your enterprise to its previous policy state before you opted in. Any changes to enterprise-level model policies made after switching to enterprise teams mode will not be preserved after rollback. @@ -65,7 +68,7 @@ Model settings for enterprise teams are additive to your enterprise's model sett * If the enterprise has enabled a model, it is always enabled for teams. * A team can receive access to additional models on top of the enterprise baseline. * If a user belongs to multiple enterprise teams, they receive access to all models enabled by the enterprise and across all of their enterprise teams. As long as one of their enterprise teams enables a model, the user gets access to it. -* There is no option to explicitly set a model to "disabled" for a team in the team's settings. "Optional" in the team's settings means the model is not currently enabled for the team. +* There is no option to explicitly set a model to "disabled" for a team in the team's settings. By default, models that are delegated to teams are set to "Optional" in each team's settings, meaning the model is not currently enabled for the team. ### Preparing to migrate @@ -73,7 +76,7 @@ Before opting in to the preview, we recommend you create enterprise teams and be For each team, you can use the **default models** tab to configure the model access that the team will receive. These settings do not apply until you opt in to the preview. -Make sure your new setup will not cause regressions for users. Although models that are explicitly "enabled" or "disabled" at the enterprise level will keep those settings once you opt in to the preview, models that are "optional" or unconfigured will be unavailable by default until they are enabled for specific teams. Filter your enterprise's model policy page by status to identify these models and choose which teams will receive access to them. +Make sure your new setup will not cause regressions for users. Although models that are explicitly "Enabled" or "Disabled" at the enterprise level will keep those settings once you opt in to the preview, models that are currently delegated to organizations will be unavailable until they are enabled for specific teams. Filter your enterprise's model policy page by status to identify these models and choose which teams will receive access to them. For information on creating teams, see [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams). @@ -88,7 +91,7 @@ For information on creating teams, see [AUTOTITLE](/enterprise-cloud@latest/admi To grant access to an enterprise team: -1. Ensure models you want to enable for the team are set to "optional" in your enterprise's model policies. +1. Ensure models you want to enable for the team are set to **Delegate to Enterprise Teams/Apps** in your enterprise's model policies. 1. Access the settings for the team. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams). 1. Click the **Default models** tab. 1. For each model that the team should receive access to beyond the enterprise baseline, set the dropdown to **Enabled**. diff --git a/content/copilot/how-tos/administer-copilot/manage-for-organization/manage-default-models.md b/content/copilot/how-tos/administer-copilot/manage-for-organization/manage-default-models.md index 98c5a7372163..d0715e17454f 100644 --- a/content/copilot/how-tos/administer-copilot/manage-for-organization/manage-default-models.md +++ b/content/copilot/how-tos/administer-copilot/manage-for-organization/manage-default-models.md @@ -18,21 +18,15 @@ allowTitleToDifferFromFilename: true If your organization is part of an enterprise, the enterprise owner controls which {% data variables.product.prodname_copilot_short %} models are available and how they can be configured at the organization level. - - - When viewing the model settings for your organization, you may see the following statuses: * **Enabled** or **Disabled** with a {% octicon "shield" aria-label="shield" %} icon: The enterprise owner has enforced this setting. You cannot change the availability of this model. -* **Enabled**, **Disabled**, or **Unconfigured** in a dropdown menu: The enterprise owner has made this model optional. You can configure the availability for your organization. - -> [!IMPORTANT] {% data reusables.copilot.model-autoenablement %} - - +* **Enabled** or **Disabled** in a dropdown menu: The enterprise owner has made this model optional. You can configure the availability for your organization. +* **Delegate to Default Policy**: This model is available for you to configure, but no one has configured it in the organization. The model inherits the default set in the "Default availability" policy for your organization. See [AUTOTITLE](/copilot/concepts/models/default-availability). ## Configuring model availability for your organization -If the enterprise owner has set a model to **Optional**, you can enable or disable it for your organization. +If the enterprise owner has delegated a model to organizations, you can enable or disable it for your organization. {% data reusables.profile.access_org %} {% data reusables.profile.org_settings %} diff --git a/data/reusables/copilot/model-autoenablement-excluded-models.md b/data/reusables/copilot/model-autoenablement-excluded-models.md index 27b5e135a486..abd15457165d 100644 --- a/data/reusables/copilot/model-autoenablement-excluded-models.md +++ b/data/reusables/copilot/model-autoenablement-excluded-models.md @@ -1,17 +1,7 @@ - +The default policy applies to models that you have not explicitly configured. These models are indicated in your enterprise or organization's model settings with the **Delegate to Default Policy** label. When a new model is released, it inherits the default until you explicitly configure it. -New and existing unconfigured models will follow the default set in the policy. Unconfigured models are: +The following models are **not** in scope. They are disabled by default, regardless of your "Default availability" policy setting. - - -* At the enterprise level, models that have not been added to the models list on the models configuration page. -* At the organization level, models that have been made "optional" by an enterprise administrator, and that an organization owner has not explicitly enabled or disabled. (**Does not apply** if you are opted in to the enterprise teams model access preview.) - -When a new model is released, it is unconfigured by default. - -The following models are **not** eligible for default enablement, regardless of whether they are new or existing: - -* Models that have been explicitly disabled * Pre-GA models * Open weight models (DeepSeek, {% data variables.copilot.copilot_kimi_k27_code %}, {% data variables.copilot.copilot_kimi_k3 %}) * Models that are not covered by {% data variables.product.company_short %}'s data retention agreement ({% data variables.copilot.copilot_claude_fable_5 %}) diff --git a/data/reusables/copilot/model-autoenablement.md b/data/reusables/copilot/model-autoenablement.md index 5705e71f5483..ae612bff83db 100644 --- a/data/reusables/copilot/model-autoenablement.md +++ b/data/reusables/copilot/model-autoenablement.md @@ -1,5 +1 @@ - - -On {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %} plans, a new policy will control whether unconfigured generally available (GA) models default to enabled or disabled. For more information, see [AUTOTITLE](/copilot/concepts/models/default-availability). - - +For enterprises on a {% data variables.copilot.copilot_business_short %} or {% data variables.copilot.copilot_enterprise_short %} plan, a policy controls whether unconfigured generally available (GA) models are enabled or disabled by default. See [AUTOTITLE](/copilot/concepts/models/default-availability). From e46790247ff9fe23fa0b7d4dfb63af82ee71de5d Mon Sep 17 00:00:00 2001 From: Greg Padak Date: Wed, 26 Aug 2026 20:01:58 +0000 Subject: [PATCH 4/5] Document marketplace auto-update managed setting (#62925) Copilot-Session: bc13c488-bec8-4acc-b052-18cf2a20bed4 --- .../enterprise-managed-settings.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md index 741ffc89422e..e6d761fe8f3e 100644 --- a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md +++ b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md @@ -70,7 +70,8 @@ The following example shows these keys in one managed settings file. "source": { "source": "github", "repo": "OWNER/REPO" - } + }, + "autoUpdate": true } }, "strictKnownMarketplaces": [ @@ -127,7 +128,13 @@ Defines plugins that are automatically installed or blocked for all enterprise u ## extraKnownMarketplaces -Defines additional plugin marketplaces available to users. Each entry is a named marketplace object containing a `source` property. The following source types are supported: +Defines additional plugin marketplaces available to users. Each entry is a named marketplace object containing a `source` property and an optional `autoUpdate` boolean. + +Set `autoUpdate` to `true` to require clients to periodically refresh that marketplace and update installed plugins sourced from it. Set it to `false` to require automatic updates to remain disabled for that marketplace. If you omit `autoUpdate`, clients use their existing default or user-configured behavior. + +Because managed settings take precedence, users cannot override a defined `autoUpdate` value. The setting applies only to that marketplace, and any restrictions in `strictKnownMarketplaces` still apply before refresh and update operations. + +The following source types are supported: * `"github"` — requires `repo` in `OWNER/REPO` format; optional `ref` (branch, tag, or SHA) and `path` (subdirectory) * `"git"` — requires `url`; optional `ref` and `path` From d2be52124181b883703c754e546c3411741df514 Mon Sep 17 00:00:00 2001 From: Greg Padak Date: Wed, 26 Aug 2026 20:02:19 +0000 Subject: [PATCH 5/5] Document enterprise managed permission rules (#62926) Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com> --- .../enterprise-managed-settings.md | 49 +++++++++++++++++-- 1 file changed, 46 insertions(+), 3 deletions(-) diff --git a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md index e6d761fe8f3e..3e802ac7ae50 100644 --- a/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md +++ b/content/copilot/reference/enterprise-administrators/enterprise-managed-settings.md @@ -23,7 +23,10 @@ When multiple settings sources are present, settings earlier in this list take p 1. File-based settings 1. User-level settings -In {% data variables.copilot.copilot_cli_short %}, the `sandbox` key is an exception to these precedence rules. Managed sandbox restrictions from MDM-managed, server-managed, and file-based settings combine with one another and with the user's sandbox settings in the most restrictive direction. +As an exception, the following keys are composed in the most restrictive direction across different delivery methods: + +* `sandbox` +* `permissions.deny`, `permissions.ask`, and `permissions.allow` ## Supported keys @@ -32,6 +35,9 @@ In {% data variables.copilot.copilot_cli_short %}, the `sandbox` key is an excep | Key | Purpose | {% data variables.copilot.copilot_cli_short %} | {% data variables.product.prodname_vscode_shortname %} | {% data variables.copilot.github_copilot_app %} | {% data variables.copilot.copilot_cloud_agent %} | {% data variables.product.prodname_jetbrains_ides %} | | --- | --- | --- | --- | --- | --- | --- | | `permissions.disableBypassPermissionsMode` | Disables bypass or YOLO-style allow-all behavior | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | {% octicon "check" aria-label="Supported" %} | +| `permissions.deny` | Blocks specific operations | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | {% octicon "x" aria-label="Not supported" %} | +| `permissions.ask` | Requires a fresh human approval before specific operations can proceed | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | {% octicon "x" aria-label="Not supported" %} | +| `permissions.allow` | Permits specific operations to proceed without a prompt | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | {% octicon "x" aria-label="Not supported" %} | | `model` | Sets auto model selection as the default for new conversations | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "x" aria-label="Not supported" %} | | `enabledPlugins` | Enables or disables specific plugins by key | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | | `extraKnownMarketplaces` | Adds plugin marketplaces that users can access | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | {% octicon "check" aria-label="Supported" %} | @@ -44,11 +50,13 @@ In {% data variables.copilot.copilot_cli_short %}, the `sandbox` key is an excep {% endrowheaders %} +In {% data variables.product.prodname_vscode_shortname %}, managed permission rules are supported through the {% data variables.product.prodname_copilot_short %} SDK-based Agent Host. Support for legacy permission policies and other execution paths isn't yet at full parity. + ## Applying different settings to enterprise teams For server-managed deployments, the enterprise can apply different governance to groups of users based on their enterprise team membership. The enterprise defines all settings—team membership only determines which users receive a given set of values. -To make a key eligible for team-specific values, mark it as overridable in `{% data variables.copilot.managed_setting_file %}` using the `{ "overridable": }` syntax. An overridable key uses the team's value when set, or falls back to your enterprise default when the team leaves it unset. The `{ "overridable": }` syntax applies to the `model`, `permissions.disableBypassPermissionsMode`, `allowedMcpServers`, and `deniedMcpServers` keys. Keys not marked overridable remain an enterprise-level decision that teams can't modify. +To make a key eligible for team-specific values, mark it as overridable in `{% data variables.copilot.managed_setting_file %}` using the `{ "overridable": }` syntax. An overridable key uses the team's value when set, or falls back to your enterprise default when the team leaves it unset. The `{ "overridable": }` syntax applies to the `model`, `permissions.disableBypassPermissionsMode`, `permissions.deny`, `permissions.ask`, `permissions.allow`, `allowedMcpServers`, and `deniedMcpServers` keys. Keys not marked overridable remain an enterprise-level decision that teams can't modify. `enabledPlugins` and `extraKnownMarketplaces` work additively. The enterprise `{% data variables.copilot.managed_setting_file %}` sets a baseline, and an enterprise team file can add more plugins and marketplaces on top of it. For the full setup steps, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings#overriding-settings-for-specific-teams). @@ -60,7 +68,23 @@ The following example shows these keys in one managed settings file. { "model": "auto", "permissions": { - "disableBypassPermissionsMode": "disable" + "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 @@ -167,6 +191,25 @@ Sets auto model selection as the default for new conversations. See [AUTOTITLE]( ## permissions +### deny, ask, allow + +The `permissions.deny`, `permissions.ask`, and `permissions.allow` keys use **deny > ask > allow** precedence. If an MDM-managed, server-managed, or file-based source defines any permission rule—or if any applicable source declares an `allow` list—an unmatched supported operation defaults to requiring approval. Otherwise, it follows the ordinary permission flow. + +* `deny` blocks specific operations, regardless of whether they also match an `ask` or `allow` rule. A deny rule set by any managed settings source blocks the operation for all users regardless of rules in the other sources. +* `ask` requires fresh, one-time approval before a specific operation can proceed, even if the operation would otherwise be allowed. A managed `ask` rule can't be satisfied by bypass mode (also known as allow-all or YOLO mode), an auto-approval setting, a hook or other approval shortcut, or a grant persisted from an earlier approval. The same operation prompts again the next time it's requested. +* `allow` permits a specific operation to proceed without a prompt. The effective allowlist is the intersection of all sources that declare one, not the union. A source that doesn't declare an `allow` list places no restriction of its own on this key. + +Rules use the following selectors: + +| Selector | Matches | +| --- | --- | +| `Shell(...)` | Shell commands. Use ` *` (for example, `git push *`) to match a command prefix; otherwise the rule matches exact text. `Bash(...)` is a compatibility alias for `Shell(...)`. `PowerShell(...)` uses the same selector family with case-insensitive command matching. | +| `Read(...)` | File read and view paths. Supports glob patterns and these roots: `//` for the filesystem root, `/` for the workspace root, `~/` for the home directory, and `./` for the current working directory.| +| `Edit(...)` | File write and edit paths, matched the same way as `Read(...)`. `Write(...)` is an alias for `Edit(...)`. | +| `Domain(...)` | Network origins. A bare host defaults to HTTPS, and host matching is case-insensitive. Use `*.` to include subdomains; for example, `*.example.com` matches both example.com and its subdomains. | + +Each subkey is overridable for enterprise teams. Set the enterprise value to `{ "overridable": }`, replacing `` with the rule array. Then use the regular syntax to define replacement rules in each team's file. + ### disableBypassPermissionsMode Prevents users from enabling bypass mode (also known as "YOLO mode"). Bypass mode lets an agent run commands, access files, and fetch URLs without asking for approval.