docs: update Learning Hub with CLI v1.0.42-1.0.43 features (#1648)

- understanding-mcp-servers.md: add Troubleshooting section with MCP
  stderr diagnostics (v1.0.42+) and /mcp show usage guidance
- copilot-configuration-basics.md: document -C startup flag (v1.0.42+),
  Auto mode server-side model routing (v1.0.43+), and /statusline
  username toggle (v1.0.43+)
- agents-and-subagents.md: add rubber-duck agent experimental feature
  documentation (v1.0.42+)

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-05-08 12:26:48 +10:00
committed by GitHub
parent a4ca380b7c
commit 93acc6c6eb
3 changed files with 61 additions and 5 deletions
@@ -3,7 +3,7 @@ title: 'Agents and Subagents'
description: 'Learn how delegated subagents differ from primary agents, when to use them, and how to launch them in VS Code and Copilot CLI.'
authors:
- GitHub Copilot Learning Hub Team
lastUpdated: 2026-05-04
lastUpdated: 2026-05-07
estimatedReadingTime: '9 minutes'
tags:
- agents
@@ -134,6 +134,21 @@ The important behavior is different from a single chat turn:
That makes `/fleet` a practical way to launch subagents even if you are not authoring custom agent files yourself.
### Rubber-duck agent (experimental)
Available in `/experimental` (v1.0.42+), the **rubber-duck agent** applies a novel multi-model pattern: when you're working in a GPT-powered session, the rubber-duck agent internally routes certain requests through Claude to provide a second perspective. The idea is similar to rubber-duck debugging — talking through a problem with a different "listener" often surfaces assumptions or blind spots you didn't notice.
To try it, enable experimental features and then select the rubber-duck agent from the agent picker:
```
/experimental # toggle experimental features
/agent # open the agent picker and select rubber-duck
```
Because it runs as a sub-agent layer rather than replacing your primary model, you keep your current session model and context while the rubber-duck analysis runs in the background.
> **Note**: This is an experimental feature and may change. Provide feedback via `/feedback` if you find it useful.
## Orchestration patterns that work well
### Coordinator and worker
@@ -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-05-05
lastUpdated: 2026-05-07
estimatedReadingTime: '10 minutes'
tags:
- configuration
@@ -408,6 +408,8 @@ These files follow the same format as `config.json` and are loaded after the glo
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.
**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.
### CLI Session Commands
GitHub Copilot CLI has two commands for managing session state, with distinct behaviours:
@@ -527,12 +529,14 @@ The `/compact` command summarizes the conversation history to free up context wi
> **ACP sessions (v1.0.39+)**: The `/compact`, `/context`, `/usage`, and `/env` commands are now available in ACP (Agent Coordination Protocol) sessions, allowing remote ACP clients to surface session details and manage context from within their own automated workflows.
The `/statusline` command (with `/footer` as an alias) lets you control which items appear in the terminal status bar. You can show or hide individual indicators like the working directory, current branch, effort level, context window usage, and quota. The **changes** toggle shows a running count of added/removed lines for the session — useful when tracking the scope of an ongoing edit:
The `/statusline` command (with `/footer` as an alias) lets you control which items appear in the terminal status bar. You can show or hide individual indicators like the working directory, current branch, effort level, context window usage, quota, and **active account username** (v1.0.43+). The **changes** toggle shows a running count of added/removed lines for the session — useful when tracking the scope of an ongoing edit:
```
/statusline # show the statusline configuration menu
```
Toggle the **username** indicator to display which GitHub account is currently active in the footer — helpful when you work with multiple accounts or switch between personal and organization contexts.
The `/keep-alive` command prevents the system from sleeping while Copilot CLI is active. This is useful during long-running agent sessions on laptops or machines with aggressive sleep settings:
```
@@ -563,6 +567,13 @@ Accepted values are `low`, `medium`, and `high`. You can also set a default via
### CLI Startup Flags
The `-C <directory>` flag changes the working directory before starting, similar to `git -C` (v1.0.42+). This is useful for scripts or aliases that need to start Copilot CLI in a specific project directory without a separate `cd`:
```bash
copilot -C ~/projects/my-repo # start in a different directory
copilot -C ~/projects/my-repo -p "..." # combine with prompt mode
```
The `--mode` flag (along with its aliases `--autopilot` and `--plan`) lets you launch the CLI directly in a specific agent mode without waiting for the interactive session to start:
```bash
@@ -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-05-01
lastUpdated: 2026-05-07
estimatedReadingTime: '8 minutes'
tags:
- mcp
@@ -261,13 +261,43 @@ If your team has internal tools or proprietary APIs, you can build custom MCP se
MCP server SDKs are available in [Python](https://github.com/modelcontextprotocol/python-sdk), [TypeScript](https://github.com/modelcontextprotocol/typescript-sdk), and other languages. Browse the [Agents Directory](../../agents/) for examples of agents built around MCP server expertise.
## Troubleshooting MCP Connection Issues
When an MCP server fails to start or loses its connection, Copilot CLI surfaces a warning with actionable details to help you diagnose the problem quickly.
**Failure warnings include stderr output** (v1.0.42+): If your MCP server prints error messages to stderr (e.g., missing environment variables, connection refused, import errors), those messages are now included directly in the CLI warning. This means you usually see the root cause without needing to run the server manually.
For example, a PostgreSQL server that can't connect because `DATABASE_URL` is not set will show:
```
⚠ MCP server "postgres" failed to start
Error: connect ECONNREFUSED 127.0.0.1:5432
stderr: Error: DATABASE_URL environment variable is required
```
**Diagnosing connection problems with `/mcp show`**: Run `/mcp show` to see the current status of all configured MCP servers — which ones are running, which have failed, and their connection details. When an MCP server name contains whitespace, the failure warning also suggests a directly runnable `/mcp show <name>` command for quick inspection.
```
/mcp show # list all servers and their status
/mcp show postgres # inspect a specific server
```
**Common causes and fixes**:
| Symptom | Likely Cause | Fix |
|---------|--------------|-----|
| `ENOENT` on startup | Missing `npx` / `python` / command | Verify the executable is installed and in your PATH |
| Auth errors / 401 | Expired or missing API key | Update the `env` field in your config; check `/mcp auth` |
| Server starts then exits | Server crash | Check stderr output in the warning for the root cause |
| Server blocked | Organization policy | Contact your admin; switch to an approved server |
## Best Practices
- **Principle of least privilege**: Only give MCP servers the minimum access they need. Use read-only database connections for analysis agents.
- **Keep secrets out of config files**: Use `${input:variableName}` for API keys and connection strings, or load from environment variables.
- **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.
- **Test server connectivity**: Verify MCP servers start correctly before relying on them in agent workflows. Use `/mcp show` to check status and read stderr output in any failure warnings.
- **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