GitHub Copilot

Copilot CLI is the surface most like the terminal agents Rohit already uses. Its documented basics ("GitHub Copilot CLI", read 27 October 2026), shown as commands that weren't run here:

copilot                                                  # interactive session; Shift+Tab cycles into plan mode
copilot -p "Summarise this week's commits" --allow-tool='shell(git)'   # one prompt, then exit
copilot --cloud                                          # the session runs in a cloud sandbox (public preview)

Where it shows up in practice. Most teams use several positions at once: completions all day, Chat for questions, agent mode for multi-file changes, code review on every pull request, and the cloud agent for a queue of small, well-specified issues. The trade-off on the dial is always the same: more autonomy saves your time while it works and costs your time when you review. Chapter 01's The developer's job with an assistant is the general version of that rule.

Path-specific instructions

Rules that apply only to some files go in .github/instructions/, each with an applyTo frontmatter of comma-separated globs. When Copilot works on a matching file, it uses that file and the repository-wide file. An optional excludeAgent keeps a file away from either "code-review" or "cloud-agent".

---
applyTo: "server/src/**/*.ts"
---
# REST API rules
- Every route validates its input with the zod schema next to it in `server/src/schemas/`.
- Errors use the RFC 9457 problem shape from `server/src/http/problem.ts`; never send stack traces.
- Changing a response shape is a breaking change: add a field, don't rename or remove one, and update `docs/api/openapi.yaml`.
- A route that changes device state (reboot, factory reset, firmware update) requires the `device:admin` scope.

---
applyTo: "server/src/routes/**,server/src/auth/**"
excludeAgent: "cloud-agent"
---
When reviewing changes here, check in this order:
1. Is every new route behind `requireAuth` and the right scope?
2. Can user input reach a device command, a file path or a shell without validation?
3. Are timeouts and retries bounded, so one slow device can't exhaust the server?
Report each problem with the line and a concrete fix.

// Which path-specific instruction files apply to which files? A model of the documented rule
// (docs.github.com, "Adding repository custom instructions", read 2026-10-27): each
// .github/instructions/**/*.instructions.md file has `applyTo` globs (comma-separated) and an optional
// `excludeAgent` ("code-review" or "cloud-agent"). Node's path.matchesGlob stands in for Copilot's matcher.
import { matchesGlob } from "node:path";

// 1. The glob examples GitHub's docs give, checked against the matcher (true = docs say it matches).
const documented = [
  ["src/*.py", "src/foo.py", true],
  ["src/*.py", "src/foo/bar.py", false],
  ["src/**/*.py", "src/foo/bar/baz.py", true],
  ["**/subdir/**/*.py", "deep/parent/subdir/nested/qux.py", true],
  ["**/subdir/**/*.py", "foo.py", false],
  ["*.py", "src/foo.py", false],
];
const wrong = documented.filter(([g, f, want]) => matchesGlob(f, g) !== want);
console.log(`documented examples: ${documented.length - wrong.length}/${documented.length} agree`);

// 2. Three instruction files from the example repository on this page (frontmatter only).
const instructionFiles = {
  "api.instructions.md": { applyTo: "server/src/**/*.ts" },
  "web.instructions.md": { applyTo: "web/src/**/*.ts,web/src/**/*.tsx" },
  "review-security.instructions.md": { applyTo: "server/src/routes/**,server/src/auth/**", excludeAgent: "cloud-agent" },
};

function applicable(file, agent) {
  return Object.entries(instructionFiles)
    .filter(([, fm]) => fm.excludeAgent !== agent)
    .filter(([, fm]) => fm.applyTo.split(",").some((glob) => matchesGlob(file, glob.trim())))
    .map(([name]) => name);
}

const changed = ["server/src/routes/devices.ts", "web/src/pages/Calls.tsx", "server/test/devices.test.ts", "README.md"];
for (const agent of ["cloud-agent", "code-review"]) {
  console.log(`\n${agent}:`);
  for (const file of changed) {
    const names = applicable(file, agent);
    console.log(`  ${file.padEnd(30)} copilot-instructions.md${names.map((n) => " + " + n).join("")}`);
  }
}

documented examples: 6/6 agree

cloud-agent:
  server/src/routes/devices.ts   copilot-instructions.md + api.instructions.md
  web/src/pages/Calls.tsx        copilot-instructions.md + web.instructions.md
  server/test/devices.test.ts    copilot-instructions.md
  README.md                      copilot-instructions.md

code-review:
  server/src/routes/devices.ts   copilot-instructions.md + api.instructions.md + review-security.instructions.md
  web/src/pages/Calls.tsx        copilot-instructions.md + web.instructions.md
  server/test/devices.test.ts    copilot-instructions.md
  README.md                      copilot-instructions.md

AGENTS.md is a cross-tool format (the agentsmd/agents.md project): Copilot, OpenAI Codex and others read it. GitHub's docs say you can have several AGENTS.md files and "the nearest AGENTS.md file in the directory tree will take precedence", or "a single CLAUDE.md or GEMINI.md file stored in the root of the repository" ("Adding repository custom instructions", read 27 October 2026). That matters if you mostly use Claude Code, as Rohit does: a repository that already has a good CLAUDE.md or AGENTS.md gives the Copilot cloud agent and code review those instructions too, and Copilot's agent skills can live in .claude/skills as well as .github/skills ("Adding agent skills for GitHub Copilot", same date).

# Agent instructions (read by Copilot, Claude Code, Codex and other agents)

- Run `npm run typecheck && npm run lint && npm test` before you report a task as done, and paste the summary.
- Never commit secrets, `.env` files or captured device logs (they can contain room names and IPs).
- Don't change `docs/api/openapi.yaml` and the code in separate pull requests.
- Ask before adding a dependency; prefer the standard library and what is already in package.json.

Prompt files

A prompt file is a Markdown file ending in .prompt.md, stored in .github/prompts/ (or your user profile), that you run as a slash command. In VS Code (docs dated 21 October 2026) the optional frontmatter has description, name (the slash command; defaults to the file name), argument-hint, agent (ask, agent, plan or a custom agent), model and tools; the body can link other files with Markdown links or #file:, refer to tools with #tool:<name>, and use ${input:name} placeholders and ${selection}.

---
description: "Add a REST endpoint to the device API, with schema, tests and OpenAPI update"
name: add-endpoint
argument-hint: "METHOD /api/v1/path and what it should return"
agent: agent
tools: ['search/codebase', 'read/readFile', 'edit/editFiles', 'execute/runInTerminal', 'execute/testFailure', 'vscode/askQuestions']
---
Add the endpoint ${input:endpoint:GET /api/v1/devices/{id}/calls} to the device API.

Follow the existing pattern in [the calls route](../../server/src/routes/calls.ts) and its
[tests](../../server/test/calls.test.ts). Before writing code:
1. Find the closest existing route and say which one you are copying.
2. If the request or response shape is unclear, use #tool:vscode/askQuestions to ask me. Don't guess fields.

Then:
- Add a zod schema in `server/src/schemas/`, the route, and tests against the fake device (success, 400, 404, device timeout).
- Update `docs/api/openapi.yaml`.
- Run `npm run typecheck && npm test` and show me the summary. If a test fails, fix the code, not the test.

Copilot now has more customisation types than instructions and prompt files. GitHub's "Comparing Copilot customization features" (read 27 October 2026) separates them by what they are for:

A rule of thumb from the same page: keep instructions minimal, and move anything that applies to only one kind of task into a skill or a custom agent, so it doesn't ride along on every request.

When to use what. Start with a short .github/copilot-instructions.md (or AGENTS.md if the team uses several agents) containing versions, commands and the handful of non-obvious rules. Add path-specific files only when a folder has rules that would be noise elsewhere. Write a prompt file when you notice the same multi-step prompt being retyped. Review these files like code, because they are code that steers code.

VS Code (docs dated 21 October 2026) layers these controls for Copilot agent sessions:

Organisations can set these through enterprise-managed settings, including hiding Allow all and requiring the sandbox. VS Code warns that Allow all and Autopilot "skip confirmation for potentially destructive actions"; use them only in a workspace you trust, ideally in a container.

GitHub's "Risks and mitigations for GitHub Copilot cloud agent" (read 27 October 2026) lists what's built in, and it is worth knowing well enough to explain:

• Only people with write access can trigger it, and comments from people without write access are never shown to it.
• It pushes to one branch: a new copilot/… branch, or the existing pull request's branch when you mention @copilot on it. Branch protection and required checks still apply, and it can't run git push itself.
• It opens a draft pull request and can't mark it ready, approve it or merge it. The person who asked for it can't approve it either, and when the PR is attributed only to Copilot's app identity one extra approval is required, as long as the repository already requires at least one (on by default in rulesets, always for branch protection rules).
• By default, GitHub Actions workflows don't run on its pushes until someone with write access clicks "Approve and run workflows", because workflows can hold secrets (an admin can configure them to run automatically, which removes this gate); look especially at any change under .github/workflows/.
• Its internet access goes through a firewall you can customise per organisation and repository, with a recommended allowlist for package registries. Know its limits: "Customizing or disabling the firewall" says it applies only to processes the agent starts with its Bash tool, not to MCP server processes or to your setup steps, and that sophisticated attacks may bypass it. An MCP server you add can reach whatever its own code reaches.
• Hidden text is filtered: for example, an HTML comment in an issue isn't passed to the agent (a defence against prompt injection; chapter 06 covers the attack).
• It checks its own work: CodeQL, the GitHub Advisory Database for new dependencies, secret scanning, and a Copilot code review pass, before it finishes.
• It's auditable: commits are authored by Copilot with the requester as co-author, signed, and linked to the session log.

Practical limits from "GitHub Copilot on GitHub.com": one repository per task, one branch and one pull request per task, and a hard 59-minute session limit. When you assign an issue, it receives the title, description, existing comments and your optional prompt; later comments on the issue aren't seen, so put corrections on the pull request, batched in one review so it works on them together.

The cloud agent figures out how to install dependencies by trial and error unless you tell it. A workflow file named .github/workflows/copilot-setup-steps.yml with a single job called copilot-setup-steps runs before the agent starts. Only steps, permissions, runs-on, services, snapshot and timeout-minutes (at most 59) are honoured; other job settings are ignored, and the file is used only from the default branch ("Configure the development environment", read 27 October 2026). The action versions follow GitHub's own example on that page (actions/checkout@v6, actions/setup-node@v7); the docs don't require a particular version, and the latest releases on 27 October 2026 were checkout v7.0.1 (20 July 2026) and setup-node v7.1.0 (8 October 2026), so actions/checkout@v7 should also work but wasn't tried. This one was checked with actionlint, not run on GitHub:

name: "Copilot Setup Steps"

# Runs automatically when this file changes (so you see it work), and manually from the Actions tab.
on:
  workflow_dispatch:
  pull_request:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  # The job MUST be called copilot-setup-steps or the agent won't use it.
  copilot-setup-steps:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    permissions:
      contents: read # the agent gets its own token for its work; keep this one minimal
    steps:
      - name: Check out the repository
        uses: actions/checkout@v6
      - name: Set up Node.js
        uses: actions/setup-node@v7
        with:
          node-version: "24"
          cache: "npm"
      - name: Install dependencies
        run: npm ci
      - name: Build the fake device used by the tests
        run: npm run build --workspace server/test/fake-device

A custom agent is a Markdown "agent profile" in .github/agents/NAME.agent.md: YAML frontmatter (description is required; name, tools, model, target, disable-model-invocation, user-invocable and, for the cloud agent only, mcp-servers are optional) and a prompt of up to 30,000 characters ("Custom agents configuration", read 27 October 2026). You pick it when assigning an issue or in the agents dropdown in the IDE, and the cloud agent can also choose it by itself from its description unless you turn that off. This profile is written to that format and wasn't loaded into Copilot:

---
name: api-contract-checker
description: Checks a change to the device REST API against docs/api/openapi.yaml and lists breaking changes. Read-only; never edits code.
tools: ["read", "search", "github/*"]
disable-model-invocation: true
---
You check REST API changes for contract problems. For the changed routes under server/src/routes/:
1. Compare each request and response shape with docs/api/openapi.yaml.
2. List every breaking change (removed or renamed field, new required parameter, changed status code).
3. List routes that change device state but don't require the device:admin scope.
Write the result as a checklist with file and line. Don't propose code; a person decides the fix.

How agents use MCP

Both agents get most of their reach from tools, and MCP (the Model Context Protocol, taught from zero in chapter 04) is how new tools are added. In the IDE you configure MCP servers per workspace or user, and agent mode asks before calling their tools unless you've approved them. In VS Code that's .vscode/mcp.json (top-level servers) or the portable .mcp.json (top-level mcpServers) that Copilot CLI-based sessions read; chapter 05's Connecting a server to a host covers those files and what happens at startup. This one, for the device tools used later in this course, wasn't loaded into VS Code:

{
  "inputs": [
    { "type": "promptString", "id": "device-lab-token", "description": "Device lab API token", "password": true }
  ],
  "servers": {
    "devices": {
      "type": "stdio",
      "command": "node",
      "args": ["${workspaceFolder}/tools/device-mcp/server.js"],
      "env": { "DEVICE_API_TOKEN": "${input:device-lab-token}" }
    }
  }
}

The cloud agent gets MCP servers from the repository's settings (Settings → Copilot → MCP servers), as JSON with a top-level mcpServers object. The GitHub MCP server (read-only, scoped to the repository) and the Playwright MCP server (localhost only) are on by default. The rules that matter, from "Configure MCP servers for your repository" (read 27 October 2026): every server needs tools (a list, or "*") and a type of local, stdio, http or sse; local servers need command and args, remote ones url; secrets come only from the repository's Agents secrets whose names start with COPILOT_MCP_, referenced as $VAR, ${VAR} or ${VAR:-default}; the agent calls these tools without asking; only tools are supported (not resources or prompts); and remote servers that need OAuth aren't supported. This model checks a configuration against those rules:

// Checks a repository MCP configuration for Copilot cloud agent against the rules in GitHub's docs
// ("Configure MCP servers for your repository", read 2026-10-27), then resolves its secret references.
// This is a model of the documented rules, not GitHub's validator.
const config = {
  mcpServers: {
    devices: {
      type: "local",
      command: "node",
      args: ["tools/device-mcp/server.js", "--base-url=${COPILOT_MCP_DEVICE_URL:-http://127.0.0.1:8080}"],
      env: { DEVICE_API_TOKEN: "$COPILOT_MCP_DEVICE_TOKEN" },
      tools: ["get_device_status", "list_call_logs"],
    },
    tracker: {
      type: "http",
      url: "https://tracker.example.com/mcp",
      headers: { Authorization: "Bearer $TRACKER_TOKEN" },
      tools: ["*"],
    },
    wiki: { type: "remote", url: "https://wiki.example.com/mcp" },
  },
};

const REF = /\$\{([A-Z0-9_]+)(?::-([^}]*))?\}|\$([A-Z0-9_]+)/g;
const problems = [];
for (const [name, s] of Object.entries(config.mcpServers)) {
  if (!Array.isArray(s.tools)) problems.push(`${name}: "tools" is required (list tools, or "*" for all)`);
  else if (s.tools.includes("*")) problems.push(`warning ${name}: tools ["*"] lets the agent call every tool without asking`);
  if (!["local", "stdio", "http", "sse"].includes(s.type)) problems.push(`${name}: type "${s.type}" is not local, stdio, http or sse`);
  if (["local", "stdio"].includes(s.type) && !(s.command && Array.isArray(s.args))) problems.push(`${name}: local servers need command and args`);
  if (["http", "sse"].includes(s.type) && !s.url) problems.push(`${name}: remote servers need url`);
  for (const [key, value] of Object.entries({ ...s.env, ...s.headers })) {
    for (const m of value.matchAll(REF)) {
      const ref = m[1] ?? m[3];
      if (!ref.startsWith("COPILOT_MCP_")) problems.push(`${name}: ${key} refers to $${ref}; only COPILOT_MCP_* secrets are passed in`);
    }
  }
}
console.log(problems.map((p) => (p.startsWith("warning ") ? "⚠ " + p.slice(8) : "✗ " + p)).join("\n") || "✓ no problems");

// Substitution as documented: $VAR, ${VAR} and ${VAR:-default}, from the repository's Agents secrets/variables.
const secrets = { COPILOT_MCP_DEVICE_TOKEN: "s3cr3t", COPILOT_MCP_DEVICE_URL: "https://lab-devices.internal" };
const resolve = (v, vars) => v.replace(REF, (_, braced, dflt, bare) => vars[braced ?? bare] ?? dflt ?? "");
const env = Object.fromEntries(Object.entries(config.mcpServers.devices.env).map(([k, v]) => [k, resolve(v, secrets)]));
const arg = config.mcpServers.devices.args[1];
console.log("\ndevices env      :", JSON.stringify({ DEVICE_API_TOKEN: env.DEVICE_API_TOKEN.replace(/./g, "*") }));
console.log("devices arg      :", resolve(arg, secrets));
console.log("arg, URL not set :", resolve(arg, { COPILOT_MCP_DEVICE_TOKEN: "s3cr3t" }));

⚠ tracker: tools ["*"] lets the agent call every tool without asking
✗ tracker: Authorization refers to $TRACKER_TOKEN; only COPILOT_MCP_* secrets are passed in
✗ wiki: "tools" is required (list tools, or "*" for all)
✗ wiki: type "remote" is not local, stdio, http or sse

devices env      : {"DEVICE_API_TOKEN":"******"}
devices arg      : --base-url=https://lab-devices.internal
arg, URL not set : --base-url=http://127.0.0.1:8080

When to use which. Agent mode for multi-file changes you want to watch, especially when the right answer needs your judgement mid-way. Plan first when the task is big or vague. The cloud agent for a backlog of small, clear issues (bugs with a reproduction, test coverage, docs, dependency bumps) where review is cheap. Neither for production incidents or security-critical design, where GitHub's own guidance says to work yourself.

Copilot code review reads the same instruction files as the agents. GitHub's example puts review rules in .github/copilot-instructions.md as plain sentences ("When performing a code review, apply the checks in the /security/security-checklist.md file"). For anything longer, a path-specific file with excludeAgent: "cloud-agent" keeps review checklists out of the agent's context, like review-security.instructions.md in Custom instructions and prompt files. Good review instructions are checks with a reason and an expected output ("Is every new route behind requireAuth? Report the line and a fix"), not adjectives ("be thorough").

The repository's MCP servers are shared by the cloud agent and code review, but code review is stricter: "each tool in the MCP server's tools/list response must set annotations.readOnlyHint to true" or it's excluded ("Configure MCP servers for your repository", read 27 October 2026). This model runs a real MCP server with the official TypeScript SDK and applies both documented filters to what the server lists:

// What Copilot code review and Copilot cloud agent would get from one MCP server, using the real SDK
// (@modelcontextprotocol/sdk 1.32.2) over an in-memory transport. The filters are GitHub's documented rules
// (docs.github.com, read 2026-10-27): the cloud agent gets the tools listed in the repository config's
// `tools`; code review also drops any tool whose annotations.readOnlyHint isn't true.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { InMemoryTransport } from "@modelcontextprotocol/sdk/inMemory.js";
import { z } from "zod";

const server = new McpServer({ name: "devices", version: "1.0.0" });
const ok = (text) => ({ content: [{ type: "text", text }] });
server.registerTool(
  "get_device_status",
  { description: "Read a room device's status.", inputSchema: { deviceId: z.string() }, annotations: { readOnlyHint: true } },
  async ({ deviceId }) => ok(`${deviceId}: online, firmware 4.2.1, in call`),
);
server.registerTool(
  "list_call_logs",
  { description: "List recent call logs for a device.", inputSchema: { deviceId: z.string() } }, // no annotations
  async ({ deviceId }) => ok(`${deviceId}: 3 calls today`),
);
server.registerTool(
  "reboot_device",
  { description: "Reboot a device.", inputSchema: { deviceId: z.string() }, annotations: { readOnlyHint: false, destructiveHint: true } },
  async ({ deviceId }) => ok(`${deviceId}: rebooting`),
);

const [clientSide, serverSide] = InMemoryTransport.createLinkedPair();
const client = new Client({ name: "copilot-model", version: "1.0.0" });
await server.connect(serverSide);
await client.connect(clientSide);

const { tools } = await client.listTools();
for (const t of tools) console.log(`${t.name.padEnd(18)} annotations: ${JSON.stringify(t.annotations ?? null)}`);

const repoConfigTools = ["get_device_status", "list_call_logs", "reboot_device"]; // what the admin allowlisted
const cloudAgent = tools.filter((t) => repoConfigTools.includes(t.name));
const codeReview = cloudAgent.filter((t) => t.annotations?.readOnlyHint === true);
console.log("\ncloud agent sees:", cloudAgent.map((t) => t.name).join(", "));
console.log("code review sees:", codeReview.map((t) => t.name).join(", "));

const result = await client.callTool({ name: "get_device_status", arguments: { deviceId: "room-4b" } });
console.log("\ncall get_device_status →", result.content[0].text);
await client.close();

get_device_status  annotations: {"readOnlyHint":true}
list_call_logs     annotations: null
reboot_device      annotations: {"readOnlyHint":false,"destructiveHint":true}

cloud agent sees: get_device_status, list_call_logs, reboot_device
code review sees: get_device_status

call get_device_status → room-4b: online, firmware 4.2.1, in call

When it pays off. Large volumes of routine pull requests, distributed teams where the first human review can be hours away (a first pass is waiting when the reviewer wakes up), and codebases with written rules nobody applies consistently. It's weakest on design questions, product intent and cross-repository effects, which is where human review time should go.

Policies are set at the enterprise level first, and for most of them the enterprise can enable, disable or "let organizations decide". A person can hold seats from more than one place, and GitHub gives a general rule with exceptions: within one enterprise, the least restrictive setting usually applies; across different enterprises, the most restrictive "almost always" applies. This model applies only the general rule:

// Effective Copilot policy for a user with licenses from several places, per GitHub's general rule
// ("GitHub Copilot policies for enterprises and organizations", read 2026-10-27): across organizations in the
// SAME enterprise the least restrictive setting usually applies; across DIFFERENT enterprises the most
// restrictive almost always applies. The docs list per-policy exceptions; this model ignores them.
const seats = [
  { enterprise: "acme", org: "acme-platform", policies: { "Copilot CLI": "disabled", "MCP servers in Copilot": "enabled" } },
  { enterprise: "acme", org: "acme-devices", policies: { "Copilot CLI": "enabled", "MCP servers in Copilot": "disabled" } },
  { enterprise: "partner", org: "partner-labs", policies: { "Copilot CLI": "enabled", "MCP servers in Copilot": "disabled" } },
];

function effective(policy, seats) {
  const byEnterprise = Object.groupBy(seats, (s) => s.enterprise);
  const perEnterprise = Object.entries(byEnterprise).map(([name, list]) => {
    const anyOn = list.some((s) => s.policies[policy] === "enabled"); // least restrictive inside one enterprise
    return [name, anyOn ? "enabled" : "disabled"];
  });
  const allOn = perEnterprise.every(([, v]) => v === "enabled"); // most restrictive across enterprises
  return { perEnterprise: Object.fromEntries(perEnterprise), result: allOn ? "enabled" : "disabled" };
}

for (const scenario of [["acme only", seats.slice(0, 2)], ["acme + partner", seats]]) {
  console.log(scenario[0]);
  for (const policy of ["Copilot CLI", "MCP servers in Copilot"]) {
    const { perEnterprise, result } = effective(policy, scenario[1]);
    console.log(`  ${policy.padEnd(24)} ${JSON.stringify(perEnterprise).padEnd(46)} → ${result}`);
  }
}

acme only
  Copilot CLI              {"acme":"enabled"}                             → enabled
  MCP servers in Copilot   {"acme":"enabled"}                             → enabled
acme + partner
  Copilot CLI              {"acme":"enabled","partner":"enabled"}         → enabled
  MCP servers in Copilot   {"acme":"enabled","partner":"disabled"}        → disabled

The "MCP servers in Copilot" policy is disabled by default and governs only Copilot Business and Enterprise users ("Model Context Protocol (MCP)", read 27 October 2026); Free, Pro, Pro+ and Max users aren't governed by it. GitHub recommends enabling it and restricting servers to an approved list. Two ways exist ("MCP server usage in your company"): an allowlist in the enterprise's managed-settings.json, generally available, matching servers securely by name, URL or stdio command, which users can't override; or a self-hosted MCP registry, in public preview, matching by name or ID only, which "users can bypass … by editing configuration files". Note too that this policy "does not control access and permissions for the GitHub MCP server in third-party host applications" such as Cursor or Claude.

• Training: "GitHub does not use Copilot Business or Copilot Enterprise customer data to train AI models", which GitHub's Data Protection Agreement prohibits without authorisation. For Copilot Free, Pro, Pro+ and Max, starting 24 April 2026, "GitHub may use your interactions … including inputs, outputs, code snippets, and associated context—to train and improve AI models", with an opt-out ("Allow GitHub to use my data for AI model training" → Disabled) in personal Copilot settings ("Managing GitHub Copilot policies as an individual subscriber", read 27 October 2026; announced in GitHub's changelog on 25 March 2026). The practical point: company code should be worked on with a company seat, not a personal plan.
• Public code matching: with "Block" set, suggestions are checked with about 150 characters of surrounding code against public code on GitHub and matches aren't shown; with "Allow", matches come with references to the source repositories and their licences. GitHub says matches occur in under one percent of suggestions. For seat holders the organisation sets this.
• Session data: cloud agent sessions run in an environment destroyed at the end, but their logs stay on GitHub and are visible to anyone with access to the repository. CLI and Copilot app sessions are stored locally under ~/.copilot/session-state/ and synced to your GitHub account by default (for Business and Enterprise only if the "Store local sessions in the Cloud" policy allows it); syncing doesn't give administrators access ("About GitHub Copilot session data").
• Retention of IDE prompts and suggestions is described in GitHub's Copilot Trust Center, which couldn't be read for this page (the site renders with JavaScript), so no retention figures are given here; check it before quoting one.
• Audit: policy changes and agent activity appear in the enterprise audit log; cloud agent commits are signed, co-authored by the requester and linked to the session log.

Where this shows up in the role. On a device platform the sensitive material is concrete: device credentials and provisioning files, customer room names and IP addresses in logs and captures, partner SDKs under licence. A lead who can say which control covers which of those, and where the gaps are, is answering the question the security team will ask.

Each of these is a workflow, not a story: what you do, which Copilot feature, and the check. Adapt them to tasks you've really done (with Claude Code or Copilot), naming the tool you used.

1. A new REST endpoint, planned then built in agent mode. Plan agent: "Add GET /api/v1/devices/{id}/calls, copying the calls route pattern; list the files you'd change and your questions." Answer the questions, then Start Implementation. The check is the agent running npm run typecheck && npm test against the fake device, then you reading the diff, especially error handling and the OpenAPI change. The limit: it copies patterns well and invents fields when the contract is vague, so the contract comes first.

2. A small backlog for the cloud agent. Pick issues with a reproduction or acceptance criteria (a flaky test, missing pagination, a docs gap). Assign them to Copilot with a one-line prompt pointing at the pattern to copy. Check: the session log (did it run the tests?), CI after "Approve and run workflows", and a normal human review. Measure how many of its PRs merge with few changes. The limit: anything ambiguous or cross-repository comes back wrong or not at all, and later issue comments aren't seen.

3. Tests first, then the change. Ask for failing tests that describe the behaviour (edge cases: device offline, timeout, 404), review the tests yourself, then let the agent make them pass with "fix the code, not the tests". This is chapter 03's Tests first with an assistant. The check is that the tests failed first and pass now, and that none were weakened.

4. Code review as a first pass for a distributed team. Automatic Copilot review on every PR, a security checklist in a path-specific instructions file, a human approval still required. For a team across time zones the benefit is that the first round of comments is waiting when the author's day starts. Measure time to first review and how many Copilot comments lead to a change.

5. Shared instructions and prompt files as onboarding. Commit .github/copilot-instructions.md, AGENTS.md and two or three prompt files (/add-endpoint, /write-tests) so a new developer, for example on the India-based team, gets the same conventions and the same best prompts on day one. Review changes to them like code. Chapter 08's Helping a distributed team use AI tools well goes further.

Interviewers often ask "how much faster are you?". The honest answer separates adoption (are people using it?), activity (how much code does it produce?) and outcomes (do PRs merge faster, with fewer defects?). GitHub's usage metrics cover the first two well: total and daily active users, agent adoption, acceptance rate, languages and models, lines-of-code metrics GitHub itself calls "directional", plus pull request lifecycle metrics. Their dashboard "primarily reflect[s] activity in supported IDEs" and doesn't include Copilot Chat on GitHub.com, Mobile, code review or the CLI ("Measuring the success of a GitHub Copilot trial", read 27 October 2026). Outcomes need your own before/after comparison, and that's where most claims go wrong. The data below is made up for illustration:

// Reading a before/after comparison honestly. The numbers are ILLUSTRATIVE (made up for this page), shaped
// like a team's pull request export: hours from opening to merge, and whether the change was reverted later.
const before = {
  hours: [5, 7, 8, 9, 10, 11, 12, 14, 15, 16, 18, 20, 22, 24, 26, 30, 34, 40, 52, 70],
  reverted: 1,
};
const after = {
  hours: [3, 4, 4, 5, 6, 6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 22, 30, 48, 96, 160],
  reverted: 3,
};

const sorted = (xs) => [...xs].sort((a, b) => a - b);
const pct = (xs, p) => sorted(xs)[Math.ceil((p / 100) * xs.length) - 1]; // nearest-rank percentile
const mean = (xs) => xs.reduce((a, b) => a + b, 0) / xs.length;

console.log("               median   p90    mean   reverted");
for (const [name, d] of [["before", before], ["after", after]]) {
  console.log(
    `${name.padEnd(14)} ${String(pct(d.hours, 50)).padStart(5)}h ${String(pct(d.hours, 90)).padStart(4)}h ${mean(d.hours).toFixed(1).padStart(6)}h   ${d.reverted}/${d.hours.length}`,
  );
}
const change = (a, b) => `${(((b - a) / a) * 100).toFixed(0)}%`;
console.log(`\nmedian ${change(pct(before.hours, 50), pct(after.hours, 50))}, mean ${change(mean(before.hours), mean(after.hours))}, p90 ${change(pct(before.hours, 90), pct(after.hours, 90))}`);

               median   p90    mean   reverted
before            16h   40h   22.1h   1/20
after             10h   48h   24.4h   3/20

median -38%, mean 10%, p90 20%

Published research points both ways, which is itself a good interview point. A 2022 controlled experiment by researchers from Microsoft Research, GitHub and MIT (Peng, Kalliamvakou, Cihon and Demirer, arXiv 2302.06590, February 2023) found developers with Copilot finished one task, writing an HTTP server in JavaScript, 55.8% faster (GitHub's September 2022 blog post rounds it to 55%). A randomised trial by METR published in July 2025, with 16 experienced open-source developers on 246 tasks in their own large repositories (mostly using Cursor with Claude models), found AI assistance made them 19% slower, while the developers believed it had made them about 20% faster. Neither settles the question for your team: tools, tasks and developers differ. Chapter 08's Measuring whether it helps treats this properly.

Naming limits makes the rest of an answer more credible. Ones you can back with GitHub's own documentation: it "may not always follow your custom instructions"; the cloud agent works in one repository for at most 59 minutes and doesn't see issue comments added after assignment; code review "is not guaranteed to spot all problems"; content exclusion doesn't apply to agent mode; terminal auto-approval "is a best-effort convenience, not a security boundary"; and GitHub's own guidance keeps security-sensitive, ambiguous and production-critical work with humans. From general experience with assistants (chapter 01): plausible but wrong APIs, tests weakened to pass, and confident explanations of code it hasn't read.

What to prepare. Two or three true workflows in the four-part shape (task, workflow, check, result and limit); the agent mode versus cloud agent explanation; one sentence each on instructions, prompt files and MCP in Copilot; one on content exclusion's limits; and one on how you'd measure impact. The review questions in chapter 09's GitHub Copilot questions let you practise them out loud.