docs-bot · Oct 23, 2026 · Oct 23, 2026 · Oct 23, 2026 · Oct 23, 2026 · Oct 23, 2026
diff --git a/content/actions/concepts/about-actions-policies.md b/content/actions/concepts/about-actions-policies.md
@@ -35,15 +35,15 @@ When enforced, disallowed workflow runs will fail with an error. For example:
 Event 'workflow_dispatch' is not allowed to trigger Actions workflows. Workflow file: '.github/workflows/0-welcome.yml'.
 ```
 
-<!-- expires 2026-11-02 -->
+<!-- expires 2026-12-02 -->
 
 {% ifversion default-pull-req-target-policy %}
 
 > [!NOTE] {% data reusables.actions.workflows.pull-request-target-policy %}
 
 {% endif %}
 
-<!-- end expires 2026-11-02 -->
+<!-- end expires 2026-12-02 -->
 
 ### Available rules
 

diff --git a/content/actions/how-tos/administer/control-workflow-execution.md b/content/actions/how-tos/administer/control-workflow-execution.md
@@ -15,15 +15,15 @@ product: 'All public repositories, and private repositories on {% data variables
 
 {% data reusables.actions.actions-policies-about-body %} For more information, see [AUTOTITLE](/actions/concepts/about-actions-policies).
 
-<!-- expires 2026-11-02 -->
+<!-- expires 2026-12-02 -->
 
 {% ifversion default-pull-req-target-policy %}
 
 > [!NOTE] {% data reusables.actions.workflows.pull-request-target-policy %}
 
 {% endif %}
 
-<!-- end expires 2026-11-02 -->
+<!-- end expires 2026-12-02 -->
 
 ## Preparing to add protections
 

diff --git a/content/actions/reference/security/securely-using-pull_request_target.md b/content/actions/reference/security/securely-using-pull_request_target.md
@@ -61,7 +61,7 @@ To help protect your workflows from untrusted pull requests, {% data variables.p
 
 For public repositories that do not already have an applicable Actions event policy, GitHub adds a default policy that blocks workflows triggered by `pull_request_target`. For more information about policies, see [AUTOTITLE](/actions/concepts/about-actions-policies).
 
-<!-- expires 2026-11-02 -->
+<!-- expires 2026-12-02 -->
 <!-- default policy flips to active -->
 
 The default policy:
@@ -70,9 +70,9 @@ The default policy:
 * Does not replace an applicable event policy that you have already configured.
 * Currently runs in **evaluate** mode. In this mode, workflow runs continue, but you can use policy insights to identify runs that would be blocked after enforcement.
 
-On November 2, 2026, GitHub will enforce the default policy for affected repositories that were using the default `pull_request_target` policy before general availability.
+On December 2, 2026, GitHub will enforce the default policy for affected repositories that were using the default `pull_request_target` policy before general availability.
 
-<!-- end expires 2026-11-02 -->
+<!-- end expires 2026-12-02 -->
 
 ### Reviewing the impact before enforcement
 

diff --git a/content/apps/oauth-apps/using-oauth-apps/authorizing-oauth-apps.md b/content/apps/oauth-apps/using-oauth-apps/authorizing-oauth-apps.md
@@ -20,6 +20,8 @@ When an {% data variables.product.prodname_oauth_app %} wants to identify you by
 > [!TIP]
 > You must [verify your email address](/account-and-profile/how-tos/email-preferences/verifying-your-email-address) before you can authorize an {% data variables.product.prodname_oauth_app %}.
 
+If you see “This account is flagged, and therefore cannot authorize a third party application” while authorizing an {% data variables.product.prodname_oauth_app %} or choosing **Continue with {% data variables.product.github %}**, your account has a restriction or is under review. This message isn't caused by missing email verification, organization approval, or SAML reauthorization. Retrying the authorization flow won't resolve the error while the restriction remains. For next steps, see [AUTOTITLE](/free-pro-team@latest/site-policy/acceptable-use-policies/github-appeal-and-reinstatement).
+
 {% endif %}
 
 ## {% data variables.product.prodname_oauth_app %} access

diff --git a/...nd-interpret-data/analyze-organization-data/viewing-public-monitoring-alerts.md b/...nd-interpret-data/analyze-organization-data/viewing-public-monitoring-alerts.md
@@ -1,8 +1,8 @@
 ---
-title: Viewing public monitoring alerts
-shortTitle: View public monitoring alerts
+title: Viewing and managing public monitoring alerts
+shortTitle: View and manage public monitoring alerts
 allowTitleToDifferFromFilename: true
-intro: 'Find out which credentials your enterprise members have exposed in public repositories across {% data variables.product.github %}.'
+intro: 'Find and manage alerts for credentials your enterprise members have exposed in public repositories across {% data variables.product.github %}.'
 permissions: 'Enterprise owners can access the public monitoring page in security overview.'
 versions:
   feature: secret-scanning-public-monitoring
@@ -43,3 +43,29 @@ Public monitoring must be enabled for your enterprise. See [AUTOTITLE](/code-sec
    * Attribution details, including the committer's username and email
    * The file location where the secret was detected, with the secret highlighted in context
    * A **Recommendations** tab with suggested remediation steps
+
+## Dismissing and reopening alerts
+
+When you have reviewed an alert, you can dismiss it to remove it from the list of open alerts. If you need to revisit a dismissed alert later, you can reopen it. When you dismiss or reopen an alert, you can add an optional comment to record the reason for your decision.
+
+Dismissing alerts you have already triaged helps you manage a high volume of public monitoring alerts, keeping the active list focused on the exposures that still need attention.
+
+### Dismissing an alert
+
+{% data reusables.enterprise-accounts.access-enterprise %}
+{% data reusables.enterprise-accounts.security-and-code-quality-tab %}
+1. In the left sidebar, click **{% octicon "key" aria-hidden="true" aria-label="key" %} Public monitoring**.
+1. Click the alert you want to dismiss.
+1. Select the **Close as** dropdown menu, then click a reason for dismissing the alert.
+1. Optionally, in the comment field, add a dismissal comment.
+1. To confirm, click **Dismiss**.
+
+### Reopening an alert
+
+{% data reusables.enterprise-accounts.access-enterprise %}
+{% data reusables.enterprise-accounts.security-and-code-quality-tab %}
+1. In the left sidebar, click **{% octicon "key" aria-hidden="true" aria-label="key" %} Public monitoring**.
+1. To view closed alerts, click **Closed**, then click the alert you want to reopen. 
+1. Click **Reopen alert**.
+1. Optionally, in the comment field, type a reason for reopening the alert.
+1. To confirm, click **Reopen**.
diff --git a/content/copilot/concepts/enterprise/default-availability.md b/content/copilot/concepts/enterprise/default-availability.md
@@ -17,17 +17,9 @@ redirect_from:
 
 {% data reusables.copilot.default-availability-policies %}
 
-<!-- expires 2026-10-22 -->
-
 ## Default availability of features
 
-The **Default policy for new features** policy is available to configure but is **not** currently active. Starting from October 22, 2026, the value you have defined for this policy will be the default setting: it will apply to any new or existing GA feature that you have not explicitly configured.
-
-In your policy settings, you will see a banner showing how many eligible policies are currently unconfigured, so you can assess the impact of your global default and explicitly configure individual policies before October 22.
-
-This policy is enabled by default. If you don't take action, unconfigured features will be enabled on October 22.
-
-<!-- end expires 2026-10-22 -->
+The **Default policy for new features and clients** policy applies to any new or existing GA feature that you have not explicitly configured.
 
 ### When does the policy apply?
 
@@ -46,7 +38,7 @@ At the enterprise level, the policy has the following possible states.
 
 Policy state | Outcome
 ------------ | --------
-**Let organizations decide** | Any unconfigured, GA feature is automatically available for organizations to enable or disable. The default state of the feature _in each of those organizations_ is determined by the organization-level **Default policy for new features** policy.
+**Let organizations decide** | The "default availability" policy decision is delegated to organizations. An unconfigured feature is set to "Let organizations decide" if its policy supports that option; otherwise, it is disabled. For a feature delegated to organizations and not explicitly configured by an organization owner, the organization-level "default policy" for new features determines its availability.
 **Enabled everywhere** | Any unconfigured, GA feature is automatically enabled for all your {% data variables.product.prodname_copilot_short %} users, and organizations cannot disable it.
 **Disabled everywhere** | Any unconfigured, GA feature is automatically disabled for all your {% data variables.product.prodname_copilot_short %} users, and organizations cannot enable it.
 
@@ -80,7 +72,7 @@ Policy state | Outcome
 ------------ | --------
 **Enabled** | Any model labeled **Delegate to Default Policy** is automatically enabled for all your {% data variables.product.prodname_copilot_short %} users, and organizations or teams cannot disable it.
 **Disabled** | Any model labeled **Delegate to Default Policy** is automatically disabled for all your {% data variables.product.prodname_copilot_short %} users, and organizations or teams cannot enable it.
-**Let organizations decide** | Any model labeled **Delegate to Default Policy** is automatically available for organizations to enable or disable. In each organization, an eligible model follows the organization-level **Default availability for released models** policy if the organization has not explicitly configured it. This state is not available if you have enabled enterprise teams mode.
+**Let organizations decide** | (Not available in enterprise teams mode.) Any model labeled **Delegate to Default Policy** is automatically available for organizations to enable or disable. In each organization, an eligible model follows the organization-level **Default availability for released models** policy if the organization has not explicitly configured it.
 
 #### Policy states for models
 

diff --git a/content/copilot/how-tos/copilot-cli/set-up-copilot-cli/add-lsp-servers.md b/content/copilot/how-tos/copilot-cli/set-up-copilot-cli/add-lsp-servers.md
@@ -161,13 +161,28 @@ Within each server definition, the following fields are available/required:
   <tbody>
     <tr>
       <td nowrap><code>command</code></td>
-      <td nowrap>Yes</td>
-      <td>The command used to start the LSP server.</td>
+      <td nowrap>No</td>
+      <td>The command used to start the LSP server. At least one of <code>command</code>, <code>bash</code>, or <code>powershell</code> must be specified.</td>
+    </tr>
+    <tr>
+      <td nowrap><code>bash</code></td>
+      <td nowrap>No</td>
+      <td>A bash script to run instead of <code>command</code>, for servers that need shell features such as pipes or environment setup. Not used on Windows if <code>powershell</code> is also set.</td>
+    </tr>
+    <tr>
+      <td nowrap><code>powershell</code></td>
+      <td nowrap>No</td>
+      <td>A PowerShell script to run instead of <code>command</code>, used on Windows when set.</td>
     </tr>
     <tr>
       <td nowrap><code>args</code></td>
       <td nowrap>No</td>
-      <td>Arguments to pass to the command.</td>
+      <td>Arguments to pass to <code>command</code>. Ignored when the server is launched with <code>bash</code> or <code>powershell</code>.</td>
+    </tr>
+    <tr>
+      <td nowrap><code>cwd</code></td>
+      <td nowrap>No</td>
+      <td>The working directory to launch the server from. Defaults to the project root.</td>
     </tr>
     <tr>
       <td nowrap><code>fileExtensions</code></td>
@@ -199,6 +214,16 @@ Within each server definition, the following fields are available/required:
       <td nowrap>No</td>
       <td>The timeout for the server's startup handshake in milliseconds (default: 60 seconds). If a server needs more time for initial project analysis, increase this value.</td>
     </tr>
+    <tr>
+      <td nowrap><code>spawnTimeoutMs</code></td>
+      <td nowrap>No</td>
+      <td>The timeout for spawning the server process in milliseconds.</td>
+    </tr>
+    <tr>
+      <td nowrap><code>warmupTimeoutMs</code></td>
+      <td nowrap>No</td>
+      <td>The timeout for the server's warmup phase in milliseconds.</td>
+    </tr>
   </tbody>
 </table>
 

diff --git a/content/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle.md b/content/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle.md
@@ -54,10 +54,12 @@ You can share the content of the current session as a shareable link to the sess
 > [!NOTE]
 > You can use `/export` as an alias for `/share` in any of the commands below.
 
-To share the session to {% data variables.product.github %} and print a shareable link, type the following in an interactive session:
+Typing `/share` with no arguments opens a full-screen sharing menu where you can choose how to share the session. Opening this menu does not itself share or export anything.
+
+To share the session to {% data variables.product.github %} and print a shareable link directly, type the following in an interactive session:
 
 ```copilot copy
-/share
+/share link
 ```
 
 To stop sharing the session, type `/share off`.
@@ -240,6 +242,7 @@ The simplest way to delete sessions is to use the `/session` slash command in an
 * `/session delete SESSION-ID` deletes a specific session. This shows a preview first; add `--yes` to confirm, for example `/session delete SESSION-ID --yes`.
 * `/session delete-all` deletes all of your local sessions except the current one. Add `--yes` to confirm: `/session delete-all --yes`. Sessions that are in use by another process are skipped.
 * `/session prune --older-than DAYS` deletes sessions older than the specified number of days. Add `--dry-run` to preview what would be deleted.
+* `/session cleanup` shows a storage summary of your other local sessions, grouped by age, and suggests commands for deleting old sessions. It does not delete local or synced sessions. Use `/session prune --older-than DAYS --dry-run` to preview deletions, then remove `--dry-run` to delete those local sessions.
 
 When you delete a session that has been synced to your account, `/session delete` asks whether you also want to delete the synced (remote) copy. Deleting the synced copy also removes the session from your `/chronicle` insights and query results. The `/session delete-all` and `/session prune` subcommands only affect local sessions and do not delete synced data. To remove synced data for those sessions, manually delete it from {% data variables.product.prodname_dotcom_the_website %}.
 

diff --git a/content/copilot/how-tos/copilot-cli/use-copilot-cli/steer-remotely.md b/content/copilot/how-tos/copilot-cli/use-copilot-cli/steer-remotely.md
@@ -37,7 +37,6 @@ This article explains how to enable and use remote control. For more conceptual
 You can enable remote control in several ways:
 
 * With a slash command during an interactive session.
-* With a command-line option when you start {% data variables.copilot.copilot_cli_short %}.
 * By configuring the CLI to enable remote control by default for all interactive sessions.
 * From JetBrains IDE settings before you start a session.
 
@@ -53,16 +52,6 @@ The CLI connects to {% data variables.product.prodname_dotcom_the_website %} and
 
 You can use the `/remote` slash command without an argument to check the current remote control status, or to redisplay the remote access details if remote control is currently enabled. If you want to end the remote connection for the current session, enter `/remote off`.
 
-### Using the `--remote` command-line option
-
-If you think you may want to access a session remotely, you can start the CLI with the `--remote` command-line option. This avoids the need to remember to use the `/remote` slash command during the session.
-
-```bash copy
-copilot --remote
-```
-
-Details for accessing the session remotely are displayed when the interactive session starts and can be displayed again at any time by using the `/remote` slash command.
-
 ### Configuring remote control to always be enabled
 
 If you always want your interactive CLI sessions to be remotely accessible, add the following to your {% data variables.product.prodname_copilot_short %} settings file (typically located at `~/.copilot/settings.json`):
@@ -73,15 +62,6 @@ If you always want your interactive CLI sessions to be remotely accessible, add
 }
 ```
 
-To override this setting for a particular session, use the `--no-remote` option when you start the session:
-
-```bash copy
-copilot --no-remote
-```
-
-> [!NOTE]
-> The command-line options `--remote` and `--no-remote` always take precedence over the `remote` setting in the settings file.
-
 ### Using JetBrains IDE settings
 
 If you use {% data variables.copilot.copilot_cli_short %} from a JetBrains IDE, you can enable remote control from the IDE before you start a session.
@@ -163,10 +143,7 @@ On {% data variables.product.prodname_dotcom_the_website %}, a message tells you
 
 ## Preventing remote control
 
-Remote control is disabled by default, but may be enabled in your {% data variables.product.prodname_copilot_short %} settings file (typically `~/.copilot/settings.json`). You can ensure a session is not remotely controllable by:
-
-* **For a single session**: Start the CLI with `--no-remote` to prevent remote control for that session, regardless of your settings file value.
-* **Permanently**: Remove the `"remoteSessions": true` setting from `~/.copilot/settings.json`, or set it to `false`.
+Remote control is disabled by default, but may be enabled in your {% data variables.product.prodname_copilot_short %} settings file (typically `~/.copilot/settings.json`). You can ensure a session is not remotely controllable by removing the `"remoteSessions": true` setting from `~/.copilot/settings.json`, or setting it to `false`.
 
 Enterprise owners can also restrict remote control of sessions hosted on your device using enterprise managed settings, regardless of your personal settings. Depending on the configured policy, remote control of sessions on your device may be disabled entirely, or only available to a controlling client that is SSO-authorized for specific organizations. This doesn't affect your ability to remotely control your own sessions hosted on other devices. See [AUTOTITLE](/copilot/reference/enterprise-administrators/enterprise-managed-settings).
 

diff --git a/...copilot-billing/request-based-billing-legacy/github-copilot-premium-requests.md b/...copilot-billing/request-based-billing-legacy/github-copilot-premium-requests.md
@@ -91,6 +91,21 @@ You can set a budget in your personal billing settings to receive alerts when yo
 * **Bundled premium request budget** - Combines all premium requests into a single budget (Recommended for most users)
 * **Individual SKU budgets** - Set separate budgets for each AI product (Copilot, {% data variables.product.prodname_spark_short %}, {% data variables.copilot.copilot_cloud_agent %})
 
+To prevent paid premium-request overages while keeping your annual {% data variables.product.prodname_copilot_short %} subscription:
+
+{% data reusables.user-settings.access_billing_settings_url %}
+
+1. Click **Budgets and alerts**.
+1. Create or edit a bundled premium request budget covering all premium-request SKUs, or individual SKU budgets covering every applicable premium-request SKU.
+1. Set each budget to **$0 USD**, enable **Stop usage when budget limit is reached**, and save your changes.
+
+This blocks additional paid premium requests after your included monthly allowance is exhausted without canceling your subscription. 
+
+> [!NOTE]
+> Deleting a budget is not a substitute for this configuration and can remove spending limits.
+
+For configuration steps, see [AUTOTITLE](/billing/how-tos/set-up-budgets#managing-budgets-for-your-personal-account).
+
 ## Monitoring usage
 
 * Track your monthly usage in your IDE, in {% data variables.product.prodname_copilot_short %} settings on {% data variables.product.prodname_dotcom %}, or by downloading a usage report.

diff --git a/content/copilot/reference/copilot-cli-reference/acp-server.md b/content/copilot/reference/copilot-cli-reference/acp-server.md
@@ -52,6 +52,8 @@ copilot --acp --port 3000 --effort=max --available-tools="bash,view"
 
 Every session the connected client opens against that server inherits those settings. Because the values are fixed when the server starts, a client cannot change them per session through `session/new`.
 
+Sessions also honor saved sandbox settings and the `--sandbox` and `--no-sandbox` options, including when a session is resumed. An enterprise-managed policy that enforces sandboxing will override `--no-sandbox`.
+
 ### stdio mode
 
 stdio mode is inferred by default when you start the ACP server. You can also use the `--stdio` option for disambiguation.