docs: update Learning Hub for Copilot CLI v1.0.76-1.0.78 features (#2541)

- copilot-configuration-basics.md:
  - Add Grok 4.5 model (v1.0.76) to model family aliases section
  - Update /rewind docs: no longer requires git, adds conversation-only
    vs conversation+files rollback choice (v1.0.78)
  - Add /new-worktree experimental command (v1.0.78)
  - Add /permissions command for switching approval modes (v1.0.78)
  - Add directable queue manager feature (v1.0.76)
  - Add Sessions Sidebar experimental feature (v1.0.76)
  - Add allowDevToolCaches sandbox setting (v1.0.78)

- installing-and-using-plugins.md:
  - Add /plugins enable/disable controls for plugin components (v1.0.76)
  - Update best practices: first-party plugins auto-update (v1.0.78)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
github-actions[bot]
2026-08-05 04:05:23 +00:00
committed by GitHub
parent 14a9bbf248
commit 940cf68164
2 changed files with 47 additions and 10 deletions
@@ -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-07-28
lastUpdated: 2026-08-04
estimatedReadingTime: '10 minutes'
tags:
- configuration
@@ -447,7 +447,7 @@ The model picker opens in a **full-screen view** with inline reasoning effort ad
**Auto mode and server-side model routing** (v1.0.43+): When you select **Auto** as your model, the CLI uses server-side model routing for real-time model selection. Instead of locking in a single model at session start, Auto mode evaluates each request and routes it to the most appropriate model dynamically. This means straightforward questions can be handled by a faster model while complex reasoning tasks are automatically escalated — without you needing to switch models manually.
**Model family aliases** (v1.0.64+): Instead of typing a full model name, you can use short family aliases in the model setting: `opus`, `sonnet`, `haiku` (Anthropic), and `gpt`, `gemini` (Google/OpenAI). The CLI resolves the alias to the latest available model in that family. This is especially useful in scripts or configuration files where you want to track the best model in a family without hardcoding a version string. Recent models available include **Claude Opus 5** (v1.0.75+), the latest in Anthropic's Opus family for the most demanding tasks.
**Model family aliases** (v1.0.64+): Instead of typing a full model name, you can use short family aliases in the model setting: `opus`, `sonnet`, `haiku` (Anthropic), and `gpt`, `gemini` (Google/OpenAI). The CLI resolves the alias to the latest available model in that family. This is especially useful in scripts or configuration files where you want to track the best model in a family without hardcoding a version string. Recent models available include **Claude Opus 5** (v1.0.75+), the latest in Anthropic's Opus family for the most demanding tasks, and **Grok 4.5** (v1.0.76+) from xAI.
**Plan mode model** *(v1.0.74+)*: When using plan mode (which blocks file mutations and keeps changes in a planning phase), you can assign a *separate* model specifically for planning — different from your regular session model. This lets you use a fast, cost-effective model for plan drafting while keeping a more capable model on standby for the implementation phase:
@@ -517,12 +517,22 @@ You can also press **x** on a highlighted session in the session picker (`--resu
In the session picker, press **`s`** to cycle the sort order: relevance, last used, created, or name. The picker also shows the branch name and idle/in-use status for each session.
The `/rewind` command opens a timeline picker that lets you roll back the conversation to any earlier point in history, reverting both the conversation and any file changes made after that point. You can also trigger it by pressing **double-Esc**:
**Sessions Sidebar** *(v1.0.76+, experimental)*: The Sessions Sidebar is a persistent panel for managing multiple concurrent sessions — switch between them, spawn new ones, and see their status at a glance, all without leaving your current session. Enable it with `/experimental on`, then toggle it on:
```
/experimental on
```
With the sidebar open, you can see all running and backgrounded sessions in a split-view panel alongside your active conversation. Sessions are listed with their name, working directory, and running status. Click or keyboard-navigate to switch sessions instantly. Use this when you regularly juggle several parallel workstreams and want a persistent view of all your sessions rather than accessing them through the `/resume` picker.
The `/rewind` command opens a timeline picker that lets you roll back the conversation to any earlier point in history. You can also trigger it by pressing **double-Esc**:
```
/rewind
```
When you select a point to roll back to, `/rewind` presents a choice: roll back the **conversation only** (leaving your files as-is) or roll back **both the conversation and file changes** (restoring files to the state they were in at that point). Since v1.0.78, `/rewind` no longer requires git — it restores only the files Copilot changed, skipping any file whose contents no longer match what Copilot last wrote.
Use `/rewind` when you want to branch off from a different point in the conversation, rather than just undoing the most recent turn.
The `/undo` command reverts the last turn—including any file changes the agent made—letting you course-correct without manually undoing edits:
@@ -567,6 +577,14 @@ This creates a branch named from your task description and begins working on it
After the command runs, the session is inside the new worktree. Use this when you want to work on a second task in parallel without stashing changes or opening a new terminal. In v1.0.64+ you can also use the experimental `--worktree` flag at startup (`copilot -w [name]`) to create or reuse a worktree under `<repo>.worktrees/` before the session begins.
The `/new-worktree` command *(v1.0.78+, experimental)* creates a new worktree and starts a **fresh conversation** in it — without inheriting the current session's history. This is useful when you want a completely clean slate for a new task in a parallel branch:
```
/new-worktree my-feature-branch
```
Unlike `/worktree` (which keeps the current conversation), `/new-worktree` is the equivalent of opening a new terminal, switching to a worktree, and starting fresh — all in one step.
The `/every` command (also available as `/loop` since v1.0.64) schedules a recurring prompt to run automatically at a specified interval. The companion `/after` command runs a prompt once after a specified delay. Both are useful for self-paced automation — polling for results, periodically summarizing progress, or triggering other slash commands on a timer:
```
@@ -637,6 +655,8 @@ Use `/diagnose` when a session is behaving unexpectedly — it inspects session
**Keyboard shortcuts for queuing messages**: Use **Ctrl+Q** or **Ctrl+Enter** to queue a message (send it while the agent is still working). **Ctrl+D** no longer queues messages — it now has its default terminal behavior. If you have muscle memory for Ctrl+D queuing, switch to Ctrl+Q.
**Directable queue manager** *(v1.0.76+)*: While the agent is working, you can manage your queued messages before they are sent. Open the queue manager to **reorder**, **edit**, **remove**, or **repeat** queued messages — even send one immediately out of turn. This is useful when you think of a better follow-up mid-run or want to reprioritize what the agent works on next.
**Background running tasks**: Press **Ctrl+X → B** to move the current running task or shell command to the background. The task continues executing while you can type a new message or review earlier output. This is useful for long-running commands where you want to interact with the agent while waiting for the result.
**Shell command history in normal mode** (v1.0.65+): The **↑/↓** arrow keys and **Ctrl+R** reverse search now include past shell commands (commands run with `!`) while you are in normal (non-shell) input mode. Previously you had to type `!` to enter shell mode before history worked. Now you can recall and re-run a shell command without switching modes first — useful for quickly repeating a build, test, or diagnostic command from earlier in the session.
@@ -727,6 +747,14 @@ Use `/autopilot` when you want to flip between supervised and unsupervised opera
> **Read-only `gh` CLI commands (v1.0.46+)**: Read-only `gh` commands — such as `gh issue list`, `gh pr view`, `gh run status`, and other commands that don't write to GitHub — are **automatically approved** without a permission prompt. Only commands that write to GitHub (like creating issues, merging PRs) still require explicit approval. This reduces friction during exploratory sessions where you frequently check issue or PR status.
The `/permissions` command *(v1.0.78+)* opens an interactive picker for switching between approval modes mid-session. Instead of typing `/allow-all on` or `/autopilot`, `/permissions` gives you a visual overview of available modes — interactive, autopilot, auto (LLM-judged), and plan — and lets you switch with a single keypress:
```
/permissions
```
Use `/permissions` as a quick mode switcher when you want to change how the agent handles tool approvals without remembering individual command names.
The `--effort` flag (shorthand for `--reasoning-effort`) controls how much computational reasoning the model applies to a request:
```bash
@@ -771,6 +799,8 @@ copilot --no-sandbox -p "Set up development environment with system tools"
These flags apply only to the current invocation — your persisted sandbox preference remains unchanged.
**`allowDevToolCaches` sandbox setting** *(v1.0.78+, on by default)*: When the sandbox is enabled, this setting grants sandboxed builds access to toolchain caches, registries, and installs (npm cache, pip cache, Go module cache, etc.) so builds work without extra setup. Set it to `false` in `/settings` to opt out if you want a stricter sandbox that blocks all toolchain cache access.
The `--attachment` flag (available in prompt mode, `-p`) lets you attach files — images or native documents — to the initial prompt in non-interactive mode:
```bash
@@ -3,12 +3,7 @@ title: 'Installing and Using Plugins'
description: 'Learn how to find, install, and manage plugins that extend GitHub Copilot CLI with reusable agents, skills, hooks, and integrations.'
authors:
- GitHub Copilot Learning Hub Team
lastUpdated: 2026-07-28
estimatedReadingTime: '8 minutes'
tags:
- plugins
- copilot-cli
- fundamentals
lastUpdated: 2026-08-04
relatedArticles:
- ./building-custom-agents.md
- ./creating-effective-skills.md
@@ -222,6 +217,18 @@ copilot plugin marketplace update
copilot plugin uninstall my-plugin
```
> **Auto-update for first-party plugins** *(v1.0.78+)*: Plugins sourced from the official `copilot-plugins` marketplace automatically update to their latest version at the start of each session. You do not need to run `copilot plugin update` for first-party plugins — updates are applied silently on startup. Community plugins from `awesome-copilot` and other marketplace registries still require a manual `copilot plugin update` command.
### Enabling and Disabling Plugin Components
*(v1.0.76+)* The `/plugins` command (or `copilot plugin list` in non-interactive mode) now includes **enable/disable toggles** for individual plugin components. You can turn off specific agents, instructions, hooks, LSP servers, or entire plugins without uninstalling them:
```
/plugins
```
This opens an interactive list where each installed plugin and its components are shown with a toggle. Disabling a component hides it from Copilot without removing it from disk — useful for temporarily deactivating a hook that is too noisy, or turning off a plugin's instructions when working on a different type of project. Re-enable the component at any time from the same `/plugins` menu.
### Loading Plugins from a Local Directory
You can load plugins directly from a local directory without installing them from a marketplace, using the `--plugin-dir` flag when starting Copilot:
@@ -298,7 +305,7 @@ This is useful for plugins that bundle dedicated tooling (for example, a databas
- **Start with a marketplace plugin** before building your own — there may already be one that fits your needs
- **Keep plugins focused** — a plugin for "Rails development" is better than a plugin for "everything"
- **Check for updates regularly** — run `copilot plugin update` to get the latest improvements
- **Check for updates regularly** — run `copilot plugin update` for community plugins; first-party plugins update automatically at session start
- **Review what you install** — plugins run code on your machine, so inspect unfamiliar plugins before installing
- **Use plugins for team standards** — publish an internal plugin to ensure every team member has the same agents, skills, and hooks
- **Remove unused plugins** — declutter with `copilot plugin uninstall` to keep your environment clean