Skip to content

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.

The agent’s environment is customized through .github/workflows/copilot-setup-steps.yml. It’s the lever for the prep that happens before the agent starts working in that ephemeral checkout — the same kind of setup any Actions workflow does. A common knob is timeout-minutes, which caps how long the agent is allowed to run before its environment is torn down: raise it for a task you expect to take longer, keep it tight for work that shouldn’t sprawl.

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 supports MCP. The external reach you wired up in the Extending chapter is available here too, so the async agent can reach the same internal systems your IDE sessions can.

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.

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 — a setting decided above your own account. The cloud coding agent is available on all paid plans. But on Business and Enterprise plans, it has to be enabled by an administrator 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.

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.