Customizing the agent's environment

You have assigned an issue to the cloud coding agent (Copilot working the issue in its own ephemeral environment and handing the work back as a pull request for your review), reviewed the pull request, and merged it - all without once asking what that environment actually contained. For a small fix it did not matter; the default checkout had everything the agent needed. But a hungrier task - something needing a longer run, or a tool the default environment does not include - is 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 - the steps run in GitHub Actions before Copilot starts working. Two separate time limits are easy to conflate: timeout-minutes caps this setup job and accepts at most 59; and separately, each cloud-agent session has a maximum execution time of 59 minutes - a hard limit that cannot be extended or bypassed. Setting the knob to 59 does not grant the agent more working time, and work that needs longer has to be split into smaller sessions - the linked documentation’s own advice.

Two things the environment already gives you are worth naming, because they are 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 - the customization support matrix lists what the cloud coding agent applies - 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 in the Extending chapter, and likewise subject to the customization matrix’s cloud-agent row and your organization’s policy; a local IDE server is not automatically available on GitHub.

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

A realistic setup for a TypeScript/Node project:

copilot-setup-steps.yml

name: copilot-setup-steps
on: workflow_dispatch

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

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

      - run: npm ci

      - run: npm run build

One requirement is easy to miss: the workflow must contain a single job named copilot-setup-steps, and customization settings outside the documented set are ignored - rename the job or stray from the supported keys, and the file silently does nothing. The on: workflow_dispatch line lets you test-run the setup from the repository’s Actions tab; timeout-minutes and the steps shown are the documented customization surface. (Action versions above follow the documentation’s current examples.)

Who’s allowed to turn it on

There is a gate above this file, and it is 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 plans that include the cloud agent (organization plans especially), an administrator may need to enable it before anyone on the team can assign work to it.

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

Where this leaves you

That is the chapter’s work done: issues assigned, pull requests reviewed, merges made. What carried through is the loop this course has run everywhere - the agent proposes, a human decides - here with the agent working alone on GitHub and handing back a pull request that a human still reviewed and merged. The leash got as long as this course gives it, and the discipline held, because the surface was built to hold it.

You have now run the work 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.