Customizing the agent's environment

You’ve assigned an issue, reviewed the draft, and merged it - all without once asking what that ephemeral environment actually contained. For the threshold fix it didn’t matter; the default checkout had everything the agent needed. But the audit-report endpoint still on the backlog is a little hungrier: it may need a longer run, or a tool the default environment doesn’t include. That’s when you reach for the one file that shapes how the cloud agent runs.

`copilot-setup-steps.yml`

The agent’s environment is customized through .github/workflows/copilot-setup-steps.yml, which must be merged into the repository’s default branch before the cloud agent uses it. It is the lever for the prep that happens before the agent starts working in its checkout. A common knob is timeout-minutes, which can shorten the run; the hard maximum for a cloud-agent session is 59 minutes and cannot be extended.

Two things the environment already gives you for free are worth naming, because they’re why the agent’s output fits without extra configuration:

It reads your custom instructions. The conventions you wrote in the Rules chapter travel into the cloud environment, so the agent’s first draft matches your repo the same way it does in the IDE.
It can use repository cloud-agent MCP configuration. This is separate from the local .vscode/mcp.json connection you wired up in the Extending chapter. A local IDE server is not automatically available on GitHub; configure and authorize a repository/cloud-agent MCP server separately, subject to your organization’s policy.

So copilot-setup-steps.yml isn’t where you teach the agent your conventions - that’s already handled. It’s where you shape the machine it runs on: what’s installed, and how long it gets.

A realistic setup for a TypeScript/Node project:

name: copilot-setup-steps
on: workflow_dispatch

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci

      - run: npm run build

Who’s allowed to turn it on

There’s a gate above this file, and it’s the same kind of gate you met in the very first chapter and again in Rules - availability depends on plan, repository, and organization policy. On Business and Enterprise plans, an administrator may need to enable the cloud agent before anyone on the team can assign work to it.

If you’re in one of the Copilot-gated shops this course is written for, that’s not a footnote - it’s the difference between this chapter being available to you and not. The capability is real and it ships with your plan; whether it’s switched on is an org decision, and if the Agents panel isn’t there, that’s the conversation to have with whoever owns your Copilot setup.

Act 2 closes

That’s the backlog cleared and the async surface fully in hand. Step back and notice what carried through: the proposes-you-decide loop you ran on a one-line bug in chapter one ran unchanged when the agent worked alone on GitHub and handed back a draft PR. The leash got as long as it gets - and the discipline held, because the surface was built to hold it.

You’ve now run the same two-repo job across every surface Copilot has in VS Code and on GitHub. The next chapter takes that exact work and shows it in a different editor entirely - Beyond VS Code: the same work in JetBrains.