docs(learning-hub): update pages with CLI v1.0.10-1.0.12 features (#1200)

- automating-with-hooks: add plugin hook env vars (CLAUDE_PROJECT_DIR,
  CLAUDE_PLUGIN_DATA, {{project_dir}}, {{plugin_data_dir}}); add
  .claude/settings.json as hooks config location
- copilot-configuration-basics: add /allow-all on/off/show subcommands;
  document .claude/settings.json and .claude/settings.local.json as
  per-repo config sources; add model picker full-screen and inline
  reasoning effort note
- understanding-mcp-servers: add MCP sampling (LLM inference) section;
  note that blocked servers are hidden from /mcp show

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: github-actions[bot]

website/src/content/docs/learning-hub/automating-with-hooks.md

@@ -3,7 +3,7 @@ title: 'Automating with Hooks'
 description: 'Learn how to use hooks to automate lifecycle events like formatting, linting, and governance checks during Copilot agent sessions.'
 authors:
   - GitHub Copilot Learning Hub Team
-lastUpdated: 2026-03-24
+lastUpdated: 2026-03-27
 estimatedReadingTime: '8 minutes'
 tags:
   - hooks
@@ -328,6 +328,34 @@ The `subagentStart` hook fires when the main agent spawns a subagent (e.g., via
 
 This is especially useful in multi-agent workflows where subagents may not automatically inherit context from the parent session.
 
+### Plugin Hook Environment Variables
+
+When hooks are defined inside a **plugin**, Copilot CLI automatically injects two extra environment variables so scripts can locate project-specific and plugin-specific directories:
+
+| Variable | Description |
+|----------|-------------|
+| `CLAUDE_PROJECT_DIR` | Absolute path to the working project directory |
+| `CLAUDE_PLUGIN_DATA` | Absolute path to the plugin's persistent data directory |
+
+You can also reference these paths as template variables in your hook configuration:
+
+```json
+{
+  "version": 1,
+  "hooks": {
+    "postToolUse": [
+      {
+        "type": "command",
+        "bash": "{{plugin_data_dir}}/scripts/format.sh {{project_dir}}",
+        "timeoutSec": 30
+      }
+    ]
+  }
+}
+```
+
+This is useful for plugins that bundle scripts or data files alongside their hooks, since `{{plugin_data_dir}}` always points to the correct installed location regardless of where the plugin is installed.
+
 ## Writing Hook Scripts
 
 For complex logic, use bundled scripts instead of inline bash commands:
@@ -377,6 +405,7 @@ echo "Pre-commit checks passed ✅"
 A: There are several supported locations, loaded in order of precedence:
 
 - **Repository-level** (shared with team): `.github/hooks/*.json` in your repository — all JSON files in this folder are loaded automatically
+- **Claude/Copilot project settings**: `.claude/settings.json` and `.claude/settings.local.json` — hooks defined here are applied to the current repository without committing them to `.github/`
 - **Global settings**: `settings.json` or `settings.local.json` (user-level CLI config)
 - **Legacy config**: `config.json` (also supported)
 

website/src/content/docs/learning-hub/copilot-configuration-basics.md

@@ -3,7 +3,7 @@ title: 'Copilot Configuration Basics'
 description: 'Learn how to configure GitHub Copilot at user, workspace, and repository levels to optimize your AI-assisted development experience.'
 authors:
   - GitHub Copilot Learning Hub Team
-lastUpdated: 2026-03-25
+lastUpdated: 2026-03-27
 estimatedReadingTime: '10 minutes'
 tags:
   - configuration
@@ -394,6 +394,17 @@ CLI settings use **camelCase** naming. Key settings added in recent releases:
 
 > **Note**: Older snake_case names (e.g., `include_gitignored`, `auto_updates_channel`) are still accepted for backward compatibility, but camelCase is now the preferred format.
 
+In addition to the main config file, GitHub Copilot CLI reads two optional per-project files for repository-specific overrides:
+
+- `.claude/settings.json` — committed project settings
+- `.claude/settings.local.json` — local overrides (add to `.gitignore` for personal adjustments)
+
+These files follow the same format as `config.json` and are loaded after the global config, so they can tailor CLI behaviour—including hook definitions—per repository without touching `.github/`.
+
+### Model Picker
+
+The model picker opens in a **full-screen view** with inline reasoning effort adjustment. Use the **← / →** arrow keys to change the reasoning effort level (`low`, `medium`, `high`) directly from the picker without leaving the session. The current reasoning effort level is also displayed in the model header (e.g., `claude-sonnet-4.6 (high)`) so you always know which level is active.
+
 ### CLI Session Commands
 
 GitHub Copilot CLI has two commands for managing session state, with distinct behaviours:
@@ -421,6 +432,16 @@ The `/cd` command changes the working directory for the current session. Each se
 
 This is useful when you have multiple backgrounded sessions each focused on a different project directory.
 
+The `/allow-all` command (also accessible as `/yolo`) enables a mode where the agent can execute tools without per-action confirmation. It now supports explicit subcommands:
+
+```
+/allow-all on      # Enable allow-all mode
+/allow-all off     # Disable allow-all mode
+/allow-all show    # Check whether allow-all mode is currently active
+```
+
+Path permissions granted via `/allow-all` persist across `/clear`, so if you've granted access to a directory in one session, that access carries into the new session.
+
 The `--effort` flag (shorthand for `--reasoning-effort`) controls how much computational reasoning the model applies to a request:
 
 ```bash

website/src/content/docs/learning-hub/understanding-mcp-servers.md

@@ -3,7 +3,7 @@ title: 'Understanding MCP Servers'
 description: 'Learn how Model Context Protocol servers extend GitHub Copilot with access to external tools, databases, and APIs.'
 authors:
   - GitHub Copilot Learning Hub Team
-lastUpdated: 2026-03-24
+lastUpdated: 2026-03-27
 estimatedReadingTime: '8 minutes'
 tags:
   - mcp
@@ -178,6 +178,20 @@ current data distribution.
 
 Without the MCP server, the agent would have to guess at database structure and performance characteristics. With it, the agent works with real data.
 
+## MCP Sampling (LLM Inference Requests)
+
+Some advanced MCP servers can request **LLM inference** from the Copilot model — a capability defined in the MCP specification as *sampling*. Instead of only receiving tool calls from the AI, these servers can ask Copilot to generate text or make decisions as part of their own logic.
+
+**How it works**:
+1. An MCP server sends a `sampling/createMessage` request to Copilot.
+2. Copilot shows a **review prompt** to the user, explaining what the server is requesting.
+3. The user approves or rejects the request.
+4. If approved, Copilot generates the response and returns it to the server.
+
+This enables sophisticated patterns like MCP servers that orchestrate multi-step reasoning, generate structured output, or build more complex AI pipelines — while keeping the user in control with an explicit approval step.
+
+> **Note**: Sampling requires explicit user approval every time a server requests inference. This is a security boundary — MCP servers cannot silently consume your AI quota or exfiltrate context without your knowledge.
+
 ## Finding MCP Servers
 
 The MCP ecosystem is growing rapidly. Here are key resources:
@@ -205,7 +219,7 @@ MCP server SDKs are available in [Python](https://github.com/modelcontextprotoco
 - **Document your servers**: Add comments or a README explaining which MCP servers your project uses and why.
 - **Version control carefully**: Commit `.mcp.json` or `.vscode/mcp.json` for shared server configurations, but use `.gitignore` for any files containing credentials.
 - **Test server connectivity**: Verify MCP servers start correctly before relying on them in agent workflows.
-- **Use the MCP allowlist (experimental)**: In high-security environments, the `MCP_ALLOWLIST` feature flag lets you validate MCP servers against a configured registry, blocking unrecognized servers from loading. This is an experimental feature for enterprise environments requiring strict control over which MCP servers are permitted.
+- **Use the MCP allowlist (experimental)**: In high-security environments, the `MCP_ALLOWLIST` feature flag lets you validate MCP servers against a configured registry, blocking unrecognized servers from loading. MCP servers that are blocked by the allowlist policy are **hidden from `/mcp show`** to avoid confusion — only permitted servers appear in that view. This is an experimental feature for enterprise environments requiring strict control over which MCP servers are permitted.
 
 ### Organization Policy for Third-Party MCP Servers