Repo sync

content/copilot/reference/copilot-cli-reference/cli-plugin-reference.md

@@ -39,7 +39,7 @@ You can use the following commands in the terminal to manage plugins for {% data
 Non-interactively, `copilot plugins enable NAME --plugin`, `copilot plugins disable NAME --plugin`, and `copilot plugins remove NAME --plugin` provide the same enable, disable, and uninstall operations. `--plugin` is the default kind and can be omitted for these three commands. See [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-command-reference#using-copilot-plugins-list) for the non-interactive `--mcp` and `--skill` kinds, which extend these commands to MCP servers and skills.
 
 > [!NOTE]
-> A plugin or marketplace pinned by an organization or MDM managed policy (`enabledPlugins`, `extraKnownMarketplaces`) can't be re-enabled, disabled, or repointed locally—the managed value wins for that entry. The `/plugins` dashboard marks these rows with a `Managed` badge and refuses a conflicting toggle. See [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-config-dir-reference#mdm-managed-settings).
+> A plugin or marketplace pinned by an organization or MDM managed policy (`enabledPlugins`, `extraKnownMarketplaces`) can't be re-enabled, disabled, or repointed locally—the managed value wins for that entry. The `/plugin` dashboard marks these rows with a `Managed` badge and refuses a conflicting toggle. See [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-config-dir-reference#mdm-managed-settings).
 
 ### Plugin specification for `install` command
 
@@ -64,18 +64,23 @@ In addition to installing a plugin from a specification, `copilot plugins instal
 
 Installing a directory registers it as a custom skill source rather than copying it; installing a file or URL copies the skill's content into your personal or project skills directory.
 
-MCP servers install from a policy-configured registry, which requires authentication and interactive secret entry. Use the `/plugins` dashboard (Online mode) or the `/mcp` slash command to add MCP servers instead of `copilot plugins install`.
+MCP servers install from a policy-configured registry, which requires authentication and interactive secret entry. Use the `/plugin` or `/mcp` dashboard (Online mode) to add MCP servers instead of `copilot plugins install`.
 
 ### `copilot plugins update` options
 
 | Option    | Description                            |
 |-----------|-----------------------------------------|
 | `--all`   | Update every installed plugin           |
 
+> [!NOTE]
+> Path-sourced plugins in a local (directory-source) marketplace load live from their real directory—editing one takes effect on `/restart` or in a new session, with no `copilot plugin update` needed.
+
 First-party plugins—those installed from the built-in `copilot-plugins` and `awesome-copilot` marketplaces—automatically update at the start of each session in a trusted working directory. Disable this behavior with the `autoUpdate` setting (set to `false`) or the `COPILOT_AUTO_UPDATE=false` environment variable. Auto-update is also skipped by default in CI. See [AUTOTITLE](/copilot/reference/copilot-cli-reference/cli-config-dir-reference#configuration-file-settings).
 
 A marketplace you've added yourself can opt into the same session-start auto-update by setting `autoUpdate: true` on its `extraKnownMarketplaces` entry in your user settings. This opt-in applies only to interactive and `-p` sessions—SDK and server sessions don't auto-update. It is honored from your own user settings or from managed (MDM/server) settings, but a repository-level `autoUpdate` setting is accepted and ignored—it can't enable or redirect auto-update for a marketplace. On a same-name collision, a built-in first-party marketplace wins, then a managed entry (which replaces the whole same-named user entry, so a managed entry without `"autoUpdate": true` removes the user's opt-in), then the user's own entry. See [Repository settings](/copilot/reference/copilot-cli-reference/cli-config-dir-reference#repository-settings-githubcopilotsettingsjson).
 
+In interactive mode, `/plugin` flags an installed plugin or marketplace when a newer version is available upstream, and offers an **Update** action from the dashboard to pull it.
+
 ### `copilot plugins marketplace` subcommands
 
 Built-in default marketplaces ship with the runtime and can't be removed.
@@ -88,7 +93,7 @@ Built-in default marketplaces ship with the runtime and can't be removed.
 | `browse NAME [--json]`  | List the plugins offered by a marketplace's catalog                        |
 | `update [NAME]` (alias `refresh`) | Refresh the plugin catalog for one marketplace, or all if `NAME` is omitted |
 
-In interactive mode, run `/plugins marketplace update [NAME]` (alias `/plugins marketplace refresh`), or press `r` in the plugins dashboard's Marketplace tab, to refresh every registered marketplace's catalog.
+In interactive mode, run `/plugin marketplace update [NAME]` (alias `/plugin marketplace refresh`), or press `r` in the plugins dashboard's Marketplace tab, to refresh every registered marketplace's catalog.
 
 ## `plugin.json`
 

content/copilot/reference/hooks-reference.md

@@ -218,7 +218,7 @@ The table below lists every supported event. The **Cloud agent** column shows wh
 | `agentStop` | The main agent finishes a turn. | Yes — can block and force continuation. | Fires. `decision: "block"` forces another turn, which still counts against the job's timeout. |
 | `errorOccurred` | An error occurs during execution. | No | Fires. |
 | `notification` | Fires asynchronously when the CLI emits a system notification (shell completion, agent completion or idle, permission prompts, elicitation dialogs). Fire-and-forget: never blocks the session. Supports a `matcher` regex pattern (the value of the `matcher` field) on `notification_type`. | Optional — can inject `additionalContext` into the session. | **Does not fire.** Cloud agent does not surface notifications to a user (see the **Interactivity** row in the Cloud agent execution environment table above). |
-| `permissionRequest` | Fires before the permission service runs (rules engine, session approvals, auto-allow/auto-deny, and user prompting). If the merged hook output returns `behavior: "allow"` or `"deny"`, that decision short-circuits the normal permission flow. Supports a `matcher` regex pattern (the value of the `matcher` field) on `toolName`. | Yes — can allow or deny programmatically. | Tool calls are pre-approved, so this hook either does not fire or has no effect. Use `preToolUse` to make permission decisions instead. |
+| `permissionRequest` | Fires before the permission service runs (rules engine, session approvals, auto-allow/auto-deny, and user prompting). If the merged hook output returns `behavior: "allow"` or `"deny"`, that decision short-circuits the normal permission flow—except for a sandbox-bypass request (`requestSandboxBypass: true`), where an `allow` does not pre-approve the escape and only `deny` propagates (see the [`permissionRequest` decision control](#permissionrequest-decision-control) sandbox-bypass exception). Supports a `matcher` regex pattern (the value of the `matcher` field) on `toolName`. | Yes — can allow or deny programmatically. | Tool calls are pre-approved, so this hook either does not fire or has no effect. Use `preToolUse` to make permission decisions instead. |
 | `postToolUse` | After each tool completes successfully. | Yes — can modify the tool result or inject additional context for the model. | Fires. |
 | `postToolUseFailure` | After a tool completes with a failure. | Yes — can provide recovery guidance via `additionalContext` (exit code `2` for command hooks). | Fires. |
 | `preCompact` | Context compaction is about to begin (manual or automatic). Supports a `matcher` regex pattern (the value of the `matcher` field) to filter by trigger (`"manual"` or `"auto"`). | No — notification only. | Fires only with `trigger: "auto"`. There is no user to request manual compaction. |
@@ -699,6 +699,8 @@ The `permissionRequest` hook fires before the permission service runs—before r
 
 All configured `permissionRequest` hooks run for each request (except `read` and `hook` permission kinds, which short-circuit before hooks). Hook outputs are merged with later hook outputs overriding earlier ones.
 
+**Sandbox-bypass exception:** for any request that asks to escape the sandbox (`requestSandboxBypass: true` in `toolInput`), a hook `allow` does not pre-approve the request or short-circuit the user prompt—leaving the sandbox is a privilege escalation the user must always confirm interactively. This covers a shell command asking to run outside the sandbox and a `web_fetch` whose URL the sandbox network policy denies. Only `deny` still propagates (so a policy hook can block the escape); an `allow` (or no decision) falls through to the normal prompt.
+
 **Matcher:** Optional regex tested against `toolName`. The regex pattern is the value of the `matcher` field, anchored as `^(?:PATTERN)$`, and must match the full tool name. When set, the hook fires only for matching tool names.
 
 > [!NOTE]

src/content-pipelines/state/copilot-cli.sha

@@ -1 +1 @@
-db430d61ac5226363782e2e8480ec2a900a021bb
+745e8ea3bfaf5c1a004b802837bbe7c1ae444c2c

src/github-apps/lib/config.json

@@ -60,5 +60,5 @@
       "2022-11-28"
     ]
   },
-  "sha": "d77b7dde24f7b3a52b3532b1337d4be8a60fb34d"
+  "sha": "fee3373e1517aa7a3510c5db165154f47baf8d97"
 }