You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/admin/managing-iam/provisioning-user-accounts-with-scim/managing-team-memberships-with-identity-provider-groups.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,6 +33,8 @@ When a change to an IdP group or a new team connection results in a user joining
33
33
34
34
Teams connected to IdP groups cannot be parents of other teams nor a child of another team. If the team you want to connect to an IdP group is a parent or child team, we recommend creating a new team or removing the nested relationships that make your team a parent team.
35
35
36
+
If you are managing a team's membership with an IdP group, you cannot assign the team maintainer role to a member of that team. For more information, see [AUTOTITLE](/organizations/organizing-members-into-teams/assigning-the-team-maintainer-role-to-a-team-member).
37
+
36
38
To manage repository access for any team in your enterprise, including teams connected to an IdP group, you must make changes on {% data variables.product.prodname_dotcom %}. For more information, see [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-team-access-to-an-organization-repository).
37
39
38
40
## Requirements for connecting IdP groups with teams
@@ -70,7 +72,7 @@ Any member of an organization can create a new team and connect the team to an I
70
72
71
73
## Managing the connection between an existing organization team and an IdP group
72
74
73
-
Organization owners {% ifversion ghes %}and team maintainers {% endif %}can manage the existing connection between an IdP group and a team.{% ifversion ghec %} If your enterprise does not use {% data variables.enterprise.prodname_managed_users %}, team maintainers can also manage the connection.{% endif %}
75
+
Organization owners can manage the existing connection between an IdP group and a team.
74
76
75
77
> [!NOTE]
76
78
> Before you connect an existing team on {% data variables.product.prodname_dotcom %} to an IdP group for the first time, all members of the team on {% data variables.product.prodname_dotcom %} must first be removed. For more information, see [AUTOTITLE](/organizations/organizing-members-into-teams/removing-organization-members-from-a-team).
Copy file name to clipboardExpand all lines: content/code-security/concepts/code-scanning/autofix-for-code-scanning.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
title: About autofix for code scanning
3
3
shortTitle: Autofix
4
4
allowTitleToDifferFromFilename: true
5
-
intro: 'Autofix provides targeted recommendations to help you fix {% data variables.product.prodname_code_scanning %} alerts and avoid introducing new security vulnerabilities.'
5
+
intro: 'Autofix automatically generates fixes for {% data variables.product.prodname_code_scanning %} alerts, helping you remediate existing vulnerabilities.'
6
6
product: '{% data reusables.rai.code-scanning.gated-feature-autofix %}'
Copy file name to clipboardExpand all lines: content/copilot/concepts/about-cloud-and-local-sandboxes.md
+2-4Lines changed: 2 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ To enable local sandboxing inside a {% data variables.copilot.copilot_cli_short
51
51
/sandbox enable
52
52
```
53
53
54
-
After you enable local sandboxing, the commands and tools that an agent runs on your behalf—shell commands, file search, and, by default, the MCP and language (LSP) servers the CLI starts—run inside an operating-system-level sandbox, limiting their access to your system. The CLI continues to use local sandboxing whenever you use the CLI in future—for programmatic as well as interactive use—until you run `/sandbox disable` to disable it.
54
+
After you enable local sandboxing, the commands and tools that an agent runs on your behalf—shell commands, file search, and, by default, the MCP and language (LSP) servers the CLI starts—run inside an operating-system-level sandbox, limiting their access to your system. The CLI continues to use local sandboxing whenever you use the CLI in future—for programmatic as well as interactive use—until you run `/sandbox disable` to disable it. If enterprise managed settings require sandboxing, you cannot disable it.
55
55
56
56
The CLI's built-in file tools—first-party commands that are part of the CLI, rather than shell commands like `sed`—run in-process in the CLI. Because the CLI itself is not sandboxed, the operating-system sandbox never sees the file operations these tools perform and cannot constrain them. Instead, the built-in tools are coded to check the sandbox policy themselves and honor your configured settings on a best-effort basis.
57
57
@@ -78,11 +78,9 @@ Local sandboxing is available on macOS and Linux, and on Windows Insiders builds
78
78
***Linux** uses the bubblewrap backend, which requires the `bwrap` command to be installed and available on your `PATH`. If `/sandbox` reports that sandboxing isn't supported on Linux, install bubblewrap.
79
79
***Windows** uses the ProcessContainer backend.
80
80
81
-
Because each platform uses a different backend, a few policy options behave differently. Most notably, on Windows the sandbox cannot block individual paths, so any denied-path rules you add are ignored there. Instead of denying a path on Windows, grant access only to the specific directories that {% data variables.product.prodname_copilot_short %} needs, rather than granting a broad directory and then trying to exclude part of it. This keeps a sensitive location out of the sandbox's reach even though denied paths aren't enforced. Denied paths are enforced on macOS and Linux.
82
-
83
81
### Enterprise policy enforcement
84
82
85
-
For organizations and enterprises, local sandbox policies can be centrally configured and enforced using Microsoft Intune and other MDM (mobile device management) platforms. This gives administrators control over how {% data variables.product.prodname_copilot_short %} interacts with local resources across managed devices. See [Deploying MDM-managed settings](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings#deploying-mdm-managed-settings).
83
+
Enterprises can require local sandboxing and enforce its configuration through server-managed, MDM-managed, or file-based managed settings. See [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings).
Copy file name to clipboardExpand all lines: content/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings.md
+41-10Lines changed: 41 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,9 +24,9 @@ The following clients are supported, although not every client supports every pr
24
24
* The {% data variables.copilot.github_copilot_app %}
25
25
* {% data variables.copilot.copilot_cloud_agent %}
26
26
27
-
These settings apply enterprise-wide and enterprises can customize specific keys to enterprise teams. For each supported key, the `{% data variables.copilot.managed_setting_file %}` value takes precedence over any file-based configuration a user sets in their client.
27
+
These settings apply enterprise-wide and enterprises can customize specific keys to enterprise teams. For most supported keys, the `{% data variables.copilot.managed_setting_file %}` value takes precedence over any file-based configuration a user sets in their client. In {% data variables.copilot.copilot_cli_short %}, managed `sandbox` settings instead define minimum restrictions that users can further tighten but cannot loosen.
28
28
29
-
Managed settings are loaded locally when the client starts, even if the device has no network connection. This means controls such as suppressing the `allow-all` permission options and restricting plugin configuration still apply before sign in or any server round trip, and remain active when users switch accounts.
29
+
MDM-managed and file-based settings are loaded from the device, so they can apply before sign in or a server round trip and remain active when users switch accounts. Server-managed settings are associated with the user's signed-in account.
30
30
31
31
## Defining settings
32
32
@@ -42,6 +42,8 @@ There are multiple ways to deploy enterprise managed settings. Use the following
42
42
***MDM-managed**: Best when IT teams need device-group targeting through existing MDM tooling on macOS and Windows. Local clients only.
43
43
***File-based**: Available on all platforms, and useful when server-managed and MDM-managed deployment are not available, including developer environments such as containers and {% data variables.product.prodname_codespaces %}. Local clients only.
44
44
45
+
In {% data variables.copilot.copilot_cli_short %}, if a request for server-managed settings fails and no cached response is available, the server-managed policy is unavailable for that session. For restrictions that must remain available without a server response, use MDM-managed or file-based settings.
46
+
45
47
There are additional considerations if you use a dedicated enterprise for {% data variables.copilot.copilot_business_short %}. See [Guidance for dedicated {% data variables.copilot.copilot_business_short %} enterprises](#guidance-for-dedicated-copilot-business-enterprises).
46
48
47
49
## Deploying server-managed settings
@@ -50,7 +52,7 @@ There are additional considerations if you use a dedicated enterprise for {% dat
50
52
1. In the repository, create or update `copilot/{% data variables.copilot.managed_setting_file %}`.
51
53
1. Add your enterprise policy keys and values in JSON format.
52
54
1. Commit and push your changes to the default branch.
53
-
1. Confirm that enterprise users are running a supported client. Updated settings are applied automatically within about an hour, or immediately after the client restarts or the user signs in again.
55
+
1. Confirm that enterprise users are running a supported client. Updated settings are applied automatically within about an hour. Restarting the client or signing in again triggers an immediate refresh.
54
56
55
57
## Overriding settings for specific teams
56
58
@@ -95,8 +97,29 @@ For example, to defer both `model` and `disableBypassPermissionsMode`:
95
97
96
98
## Deploying MDM-managed settings
97
99
98
-
1. Create or update your `{% data variables.copilot.managed_setting_file %}` payload using the same JSON schema used for server-managed settings.
99
-
1. Deploy the payload using your enterprise MDM platform and standard rollout process.
100
+
Native MDM delivery uses the same logical keys and values as server-managed settings, but it does not deploy a `{% data variables.copilot.managed_setting_file %}` file. Instead, your MDM platform deploys individual settings as operating-system-managed string values.
101
+
102
+
Native MDM delivery is available on Windows and macOS:
103
+
104
+
| Operating system | Native policy location |
105
+
| --- | --- |
106
+
| Windows | String (`REG_SZ`) values under `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\GitHubCopilot`|
107
+
| macOS | String values in forced managed preferences for the `com.github.copilot` preference domain |
108
+
| Linux | Native MDM delivery is not supported. Use file-based settings instead. |
109
+
110
+
All native MDM values must be strings. For nested settings, use a dot-separated key such as `permissions.disableBypassPermissionsMode` or `sandbox.enabled`. Store ordinary string values directly. Store booleans, arrays, and objects as JSON text within a string value.
1. Choose the settings you want to enforce. See [AUTOTITLE](/copilot/reference/enterprise-managed-settings-reference).
121
+
1. Convert each setting to the native key and string value representation.
122
+
1. Deploy the settings to the native policy location using your enterprise MDM platform and standard rollout process.
100
123
1. Assign the policy to the target device groups.
101
124
102
125
Clients do not need to restart, and check for updated policies on an hourly basis. In {% data variables.product.prodname_vscode_shortname %}, an administrator can force a check for testing by running the `Developer: Sync Account Policy` command.
@@ -105,17 +128,25 @@ For example, to defer both `model` and `disableBypassPermissionsMode`:
105
128
106
129
## Deploying file-based settings
107
130
131
+
Place `{% data variables.copilot.managed_setting_file %}` in the following location:
| Windows |`%ProgramFiles%\GitHubCopilot\managed-settings.json`|
137
+
| Linux |`/etc/github-copilot/managed-settings.json`|
138
+
108
139
1. Create or update a `{% data variables.copilot.managed_setting_file %}` file with the policy keys and values you want to enforce.
109
-
1. Distribute the file to managed machines using your standard device management process. Machines that don't receive the file are not restricted by this policy, so file-based deployment only provides coverage for the machines you actively distribute to.
110
-
1.Apply file permissions according to your enterprise security requirements.
140
+
1. Distribute the file to the platform-specific location using your standard device management process. Machines that don't receive the file are not restricted by this policy.
141
+
1.For {% data variables.copilot.copilot_cli_short %} on macOS and Linux, make the file a regular file owned by `root`, and ensure it is not group-writable or world-writable. Do not use a symbolic link. The CLI rejects files that do not meet these requirements.
111
142
1. Ask users to restart supported clients so the updated policy is loaded at startup.
112
143
1. Confirm the settings took effect. See [Verifying the configuration has applied](#verifying-the-configuration-has-applied).
113
144
114
145
## Verifying the configuration has applied
115
146
116
-
Once the configuration is committed, users on a supported client see the specified settings within about an hour, since clients periodically check the server for updated configuration. For server-managed deployments, this includes `copilot/{% data variables.copilot.managed_setting_file %}`, `copilot/{% data variables.copilot.team_mappings_file %}`, and files in `copilot/{% data variables.copilot.team_settings_directory %}`.
147
+
For server-managed deployments, users on a supported client see the specified settings within about an hour. This includes `copilot/{% data variables.copilot.managed_setting_file %}`, `copilot/{% data variables.copilot.team_mappings_file %}`, and files in `copilot/{% data variables.copilot.team_settings_directory %}`. Restarting the client or signing in again triggers an immediate refresh.
117
148
118
-
Restarting the client or signing in again applies the latest settings immediately.
149
+
For MDM-managed deployments, clients check for updated policies hourly. For file-based deployments, restart the client to load an updated file.
119
150
120
151
If a user does not see these settings, ensure they receive access to {% data variables.product.prodname_copilot_short %} through your enterprise or one of its organizations. If a user receives a license from multiple billing entities, ensure they have selected your enterprise in the "Usage billed to" dropdown in their [personal {% data variables.product.prodname_copilot_short %} settings](https://github.com/settings/copilot/features).
121
152
@@ -137,7 +168,7 @@ The main limitation of this method is the {% data variables.product.prodname_ent
137
168
138
169
### Using MDM-managed or file-based settings
139
170
140
-
If you don't want to add a {% data variables.product.prodname_enterprise %} license or create an organization, you can deploy the same settings through MDM (such as Intune or Jamf) or a file-based deployment. These methods use the same JSON schema and don't require an organization or `.github-private` repository. See [Deploying MDM-managed settings](#deploying-mdm-managed-settings) and [Deploying file-based settings](#deploying-file-based-settings). For {% data variables.product.prodname_vscode_shortname %}-specific guidance, see [Deploy Copilot managed settings](https://code.visualstudio.com/docs/enterprise/ai-settings#_deploy-copilot-managed-settings) in the {% data variables.product.prodname_vscode_shortname %} documentation.
171
+
If you don't want to add a {% data variables.product.prodname_enterprise %} license or create an organization, you can deploy the same logical settings through MDM (such as Intune or Jamf) or a file-based deployment. File-based delivery uses the JSON schema directly. Native MDM delivery uses flat keys and string-encoded values. Neither method requires an organization or `.github-private` repository. See [Deploying MDM-managed settings](#deploying-mdm-managed-settings) and [Deploying file-based settings](#deploying-file-based-settings). For {% data variables.product.prodname_vscode_shortname %}-specific guidance, see [Deploy Copilot managed settings](https://code.visualstudio.com/docs/enterprise/ai-settings#_deploy-copilot-managed-settings) in the {% data variables.product.prodname_vscode_shortname %} documentation.
Copy file name to clipboardExpand all lines: content/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ For a conceptual overview of cloud and local sandboxes for {% data variables.pro
31
31
32
32
## Configuring general settings
33
33
34
-
The **General** tab controls the top-level sandbox behavior.
34
+
The **General** tab controls the top-level sandbox behavior. When enterprise managed settings enforce a value, the dialog labels the setting as `(managed)` and prevents you from changing it.
35
35
36
36
| Setting | Description |
37
37
| --- | --- |
@@ -47,7 +47,7 @@ The **General** tab controls the top-level sandbox behavior.
47
47
48
48
The **Allow sandbox bypass** setting controls what happens when {% data variables.product.prodname_copilot_short %} can't run a command successfully inside the sandbox.
49
49
50
-
***On (default)**: If a command fails inside the sandbox, you are prompted to allow {% data variables.product.prodname_copilot_short %} to run the command outside the sandbox. Your response to this prompt applies to this specific attempt to run the command. Optionally, you can choose to disable the sandbox for the rest of the session, or you can enter an instruction for {% data variables.product.prodname_copilot_short %} to work on instead.
50
+
***On (default)**: If a command fails inside the sandbox, you are prompted to allow {% data variables.product.prodname_copilot_short %} to run the command outside the sandbox. Your response to this prompt applies to this specific attempt to run the command. Optionally, you can choose to disable the sandbox for the rest of the session (if permitted by your enterprise), or you can enter an instruction for {% data variables.product.prodname_copilot_short %} to work on instead.
51
51
***Off**: If {% data variables.product.prodname_copilot_short %} can't run a command successfully in the sandbox, it stops working on the task and reports the failure.
0 commit comments