Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions website/src/content/docs/learning-hub/automating-with-hooks.md
Original file line number Diff line number Diff line change
Expand Up @@ -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-06-25
lastUpdated: 2026-07-12
estimatedReadingTime: '8 minutes'
tags:
- hooks
Expand Down Expand Up @@ -390,7 +390,15 @@ Block dangerous commands before they execute. Use the `matcher` field to target
}
```

The `preToolUse` hook receives JSON input with details about the tool being called. Your script can inspect this input and exit with a non-zero code to **deny** the tool execution, or exit with zero to **approve** it.
The `preToolUse` hook receives JSON input with details about the tool being called. Your script can inspect this input and exit with a specific code to control what happens next:

| Exit Code | Behavior |
|-----------|----------|
| `0` | **Approve** — the tool call proceeds normally |
| `2` *(v1.0.70+)* | **Explicit deny** — the tool call is blocked; the agent receives a clear denial message |
| Non-zero (other) | **Deny** — the tool call is blocked |

Using exit code `2` is recommended for intentional denials because it signals to the agent that a deliberate policy decision was made (rather than an unexpected script error), allowing the agent to adapt its approach gracefully.

### Modifying Tool Arguments with preToolUse

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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-07
lastUpdated: 2026-07-12
estimatedReadingTime: '10 minutes'
tags:
- configuration
Expand Down Expand Up @@ -406,12 +406,24 @@ 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:
In addition to the main config file, GitHub Copilot CLI reads optional per-project files for repository-specific overrides:

- `.claude/settings.json` — committed project settings
- `.github/copilot/settings.json` *(v1.0.70+)* — repository-pinned settings committed to `.github/`. When Copilot trusts the repository, these settings can **pin the model, reasoning effort level, and context tier** for all sessions in that repo, and **extend the URL/MCP/skill deny lists**. This is the recommended way to enforce consistent model configuration for your team.
- `.claude/settings.json` — committed project settings (earlier format, still supported)
- `.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/`.
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 your global config.

**Example `.github/copilot/settings.json`** that pins a model and reasoning effort for all sessions:

```json
{
"model": "claude-sonnet-4.8",
"effortLevel": "high"
}
```

> **Trust requirement**: Repository-pinned settings in `.github/copilot/settings.json` only take effect in repositories you have explicitly trusted. This prevents untrusted repositories from silently overriding your model choices or injecting deny-list entries.

> **Important (v1.0.36+)**: Custom agents, skills, and commands placed in `~/.claude/` (the Claude Code user directory) are **no longer loaded** by GitHub Copilot CLI. Only `~/.claude/settings.json` is read for configuration. If you previously stored personal agents or skills in `~/.claude/`, move them to the supported locations: `~/.copilot/agents/` for user-level agents, `~/.copilot/skills/` or `~/.agents/skills/` for personal skills, or `.github/agents/` and `.github/skills/` in your repositories for project-level customizations.

Expand Down Expand Up @@ -544,6 +556,14 @@ The `/pr auto` command *(v1.0.66+)* starts a self-paced automation loop that dri

`/pr auto` is ideal when you have a PR with failing tests or linting errors — let it work through failures one at a time while you focus on other things. `/pr automerge` extends this further: it continues until all CI checks pass, required reviews are approved, and the PR is successfully merged. Both commands can be monitored and stopped from `/loop` or `/every`, which register the running automation as a scheduleable loop task.

The `/refine` command *(v1.0.70+)* rewrites a rough, stream-of-consciousness prompt into a clearer, more structured one. Use it when you have a vague idea of what you want but want help articulating it before sending:

```
/refine
```

After running `/refine`, the CLI presents a polished version of your prompt that you can edit further or send directly. This is useful when you know what you want to accomplish but are struggling to express it precisely — let Copilot help you craft a better question.

The `/share html` command exports the current session — including conversation history and any research reports — as a **self-contained interactive HTML file**:

```
Expand Down Expand Up @@ -672,6 +692,15 @@ Accepted values are `low`, `medium`, and `high`. You can also set a default via

### CLI Startup Flags

The `--sandbox` and `--no-sandbox` flags *(v1.0.70+)* toggle the OS-level shell sandbox **for the current session only**, without permanently changing your saved sandbox setting. This is useful with `-p` (prompt mode) when you need to temporarily allow or disallow shell access without affecting your normal interactive sessions:

```bash
copilot --no-sandbox -p "run npm install and then build" # disable sandbox for this one-shot task
copilot --sandbox # force sandbox on for this session
```

The `--sandbox`/`--no-sandbox` flags override the persisted sandbox setting for the duration of the session. When the session ends, your saved setting is restored. For permanent changes to the sandbox setting, use `/settings` inside an interactive session.

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
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: 'Creating Effective Skills'
description: 'Master the art of writing reusable, shareable skill folders that deliver consistent results across your team.'
authors:
- GitHub Copilot Learning Hub Team
lastUpdated: 2026-06-30
lastUpdated: 2026-07-12
estimatedReadingTime: '9 minutes'
tags:
- skills
Expand Down Expand Up @@ -270,6 +270,7 @@ Use this skill when:
- **Name descriptively**: Use clear, action-oriented names: `generate-tests`, not `helper`
- **Keep assets lean**: Bundled files should be under 5 MB each
- **Test thoroughly**: Verify skills work with different inputs and codebases
- **Let Forge help** *(v1.0.70+)*: Copilot automatically creates draft skills when it detects repeatable workflow patterns in your sessions. Review and accept these drafts via `/chronicle skills review` to grow your skill library organically from real usage patterns.

### Writing Style Guidelines

Expand Down Expand Up @@ -405,7 +406,7 @@ A: Yes, for clarity. Show examples of desired output format, patterns to follow,

**Q: How do I review agent-proposed skill changes?**

A: In v1.0.66+, the agent can propose draft skill additions or improvements as it discovers reusable patterns during a session. Review each draft interactively with:
A: In v1.0.66+, the agent can propose draft skill additions or improvements as it discovers reusable patterns during a session. In v1.0.70+, Copilot **automatically creates draft skills** when it detects a clear, repeatable workflow pattern — even without you asking. Review each draft interactively with:

```
/chronicle skills review
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +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-06-24
lastUpdated: 2026-07-12
estimatedReadingTime: '8 minutes'
tags:
- plugins
Expand Down Expand Up @@ -182,6 +182,25 @@ Or from an interactive session:

Browse to the plugin via `@agentPlugins` in the Extensions search view or via **Chat: Plugins** in the Command Palette, then click **Install**.

### The `/plugins` Dashboard *(v1.0.69+)*

Inside an interactive Copilot CLI session, run `/plugins` to open a dashboard for managing your installed plugins without leaving the session:

```
/plugins
```

The `/plugins` dashboard shows all installed plugins, their versions, and their included components (agents, skills, hooks, MCP servers). From here you can:

- **Browse** installed plugins and see what each one provides
- **Enable or disable** individual plugins without uninstalling them
- **Update** plugins to newer versions
- **Uninstall** plugins you no longer need

The `/plugins` dashboard is the recommended way to manage plugins during an interactive session — no need to open a separate terminal window or remember CLI subcommands.

You can also run `/plugin list` to get a quick list of installed plugins while the agent is working (both `/plugins` and `/plugin list` can run mid-turn without interrupting the agent).

## Managing Plugins

Once installed, plugins are managed with a few simple commands:
Expand All @@ -200,6 +219,24 @@ copilot plugin marketplace update
copilot plugin uninstall my-plugin
```

### Pinning Plugins to an Exact Commit *(v1.0.70+)*

For reproducible environments, you can pin a plugin to a specific commit SHA using the `sha` field in your plugin source configuration. This ensures your team always uses an exact, immutable version of a plugin regardless of what gets published to the marketplace:

```json
{
"source": "github/awesome-copilot",
"sha": "a1b2c3d4e5f6..."
}
```

Pin by SHA when:
- You need **reproducible builds** (CI or controlled environments)
- A plugin update introduced a breaking change and you want to stay on a known-good version
- You're sharing a configuration across a team and want everyone on the same version

Unlike version tags (which can be overwritten), a commit SHA is immutable — the pinned plugin will never change without you explicitly updating the SHA.

### 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:
Expand Down