Task 2.3: Integrate agents within development environments

• AAdd an on: copilot_agent trigger so the workflow knows when to run

  Incorrect

  There is no such trigger; Copilot runs the copilot-setup-steps job itself when a session starts.

• BMove the steps into the repository's custom instructions as a setup section

  Incorrect

  Instructions guide the model; the setup steps file installs tools deterministically before the agent starts.

• CAdd contents: write to the job's permissions so Copilot can read the installed tools

  Incorrect

  Job permissions don't decide whether Copilot uses the steps; the job name and the branch the file is on do.

• DRename the job to copilot-setup-steps and merge the file into the default branch

  Correct

  The job must be called copilot-setup-steps, and the workflow won't trigger unless it is on the default branch.

To customize Copilot's environment, create .github/workflows/copilot-setup-steps.yml containing a single job named copilot-setup-steps. Its steps run in GitHub Actions before Copilot starts working, and the workflow won't trigger unless the file is on the default branch.

• AUse macOS runners so the agent can build the iOS client too

  Incorrect

  Cloud agent supports Ubuntu x64 and Windows 64-bit runners, not macOS.

• BRegister the runners with the reserved label copilot, which the agent picks up without any runner setting

  Incorrect

  There is no reserved label: runs-on in the copilot-setup-steps job, or an organization's labeled-runner default, chooses the runners.

• CUse ephemeral, single-use runners that aren't reused for other jobs

  Correct

  GitHub recommends only ephemeral, single-use runners for cloud agent.

• DDisable cloud agent's integrated firewall and apply network controls on the runners

  Correct

  The firewall isn't compatible with self-hosted runners, and use is blocked until it is disabled; network security is then yours to configure.

• EGive the runners open internet access so the agent can download dependencies

  Incorrect

  GitHub says to make sure the agent doesn't have open access to your network or the public internet.

You can run Copilot cloud agent on self-hosted runners. GitHub recommends ephemeral, single-use runners, usually through ARC or the Runner Scale Set Client, with network controls that prevent open access while allowing the required GitHub and Copilot hosts. The integrated firewall must be disabled because it isn't compatible with self-hosted runners. Only Ubuntu x64 and Windows 64-bit runners are supported.

• AAdd copilot-requests: write and turn on the policy that charges Copilot CLI usage to the org

  Correct

  GITHUB_TOKEN authentication needs that permission and the "Allow use of Copilot CLI billed to the organization" policy.

• BStore the GITHUB_TOKEN as COPILOT_GITHUB_TOKEN in Actions secrets so it lasts across runs

  Incorrect

  GITHUB_TOKEN is generated for each run; storing it as a secret isn't how this works.

• CAssign a Copilot seat to the github-actions bot account

  Incorrect

  With GITHUB_TOKEN, the workflow authenticates as an installation with no user, and usage is metered to the organization.

• DUse a GitHub App installation token, which the CLI prefers over GITHUB_TOKEN

  Incorrect

  The documented options are a personal access token or the built-in GITHUB_TOKEN.

Copilot CLI can authenticate in GitHub Actions with a personal access token, billed to that user's seat, or with the built-in GITHUB_TOKEN. With GITHUB_TOKEN in an organization-owned repository, usage is metered to the organization; the workflow must grant copilot-requests: write, and the "Allow use of Copilot CLI billed to the organization" policy must be enabled.

• ACopilot runs one agent session for each entry in the matrix, in parallel

  Incorrect

  Matrix isn't among the settings you can customize.

• BThe workflow fails validation and Copilot stops

  Incorrect

  Other settings are ignored rather than failing the job.

• CCopilot picks the first matrix entry

  Incorrect

  The setting is ignored, not interpreted.

• DIt is ignored, because only some job settings can be customized

  Correct

  Only a short list of job settings, such as steps, permissions and runs-on, can be set; other changes are ignored.

In copilot-setup-steps.yml you can customize only a short list of settings of the copilot-setup-steps job, such as steps, permissions, runs-on and services; strategy is not among them. If you try to customize other settings, your changes are ignored.

• AIt overrides it, so the agent can roll back commits when asked

  Correct

  The fetch-depth value is overridden to allow rollback on request while mitigating security risks.

• BIt keeps the value, so the agent always works on a shallow single-commit clone

  Incorrect

  The value is overridden, not kept.

• CIt rejects the workflow until fetch-depth is removed

  Incorrect

  The value is overridden quietly; the workflow isn't rejected.

• DIt applies it only to Copilot code review

  Incorrect

  The override applies to the setup steps used by the agent.

Any value set for the fetch-depth option of actions/checkout in copilot-setup-steps.yml is overridden, allowing the agent to roll back commits upon request while mitigating security risks.

• AA codeReview job inside copilot-setup-steps.yml

  Incorrect

  The setup steps file has a single copilot-setup-steps job; code review gets its own file.

• BNothing; code review always runs in exactly the same environment as cloud agent

  Incorrect

  Code review can be given its own environment file.

• CA separate copilot-code-review.yml file for code review's environment

  Correct

  By default code review reuses copilot-setup-steps.yml, but a dedicated copilot-code-review.yml configures it independently.

• DAn excludeAgent setting in copilot-setup-steps.yml

  Incorrect

  excludeAgent is an instructions-file setting, not an environment option.

Copilot code review also runs in an ephemeral development environment that you can customize in the same ways as cloud agent's. By default it reuses your copilot-setup-steps.yml file, but you can create a dedicated copilot-code-review.yml file to configure code review's environment independently.

• AOnly the Copilot CLI policy, since /delegate starts from the command line

  Incorrect

  The cloud agent policy is also needed, because /delegate hands work to cloud agent.

• BBoth the Copilot CLI and Copilot cloud agent policies enabled

  Correct

  Both policies must be enabled for /delegate to work.

• CThe MCP servers in Copilot policy

  Incorrect

  That policy governs MCP servers, not delegation.

• DAn IDE-specific policy for the terminal

  Incorrect

  IDE-specific policies don't affect Copilot CLI.

Not every AI control applies to Copilot CLI. Among those that do, both the Copilot CLI policy and the Copilot cloud agent policy must be enabled for users to use /delegate. IDE-specific policies do not affect Copilot CLI.