GitHub Copilot Cloud Agent Explained

GitHub Copilot Cloud Agent ExplainedAgents, MCP & Agentic Development3Intermediate/github-copilot/agents/cloud-agent/

The previous lesson delegated a task. This one explains what was on the other end of that delegation — because the cloud agent’s constraints are architectural, and knowing where it runs tells you most of what it can and cannot do.

Key takeaways

• It runs on GitHub, in a GitHub Actions-powered environment, not on your machine and not in your editor.
• Its context is scoped to one repository by default — the one specified when the task started.
• Its output is a pull request, which is the reason it is the safest of the agent surfaces despite being the most autonomous.
• Its MCP support differs from your editor’s: configuration lives in repository settings, only tools are supported, and remote servers using OAuth are not currently supported.
• It will not ask before using MCP tools. GitHub states it uses available tools autonomously.

Where it runs

Agent mode runs inside your editor, against your working tree, with your local environment. The cloud agent runs on GitHub, in an ephemeral environment described in GitHub’s documentation as GitHub Actions-powered.

Almost every practical difference follows from that one fact.

It does not see your uncommitted work. Your working tree is on your machine. The agent has the repository as GitHub has it. Local changes you have not pushed do not exist as far as it is concerned.

Its environment is not yours. Your installed toolchain, your environment variables, your local services and your credentials are all absent. What it has is whatever the repository plus its environment configuration provides.

It is asynchronous by nature. You start it and go elsewhere. There is no interactive turn-taking, which is the property that makes the issue text carry so much weight.

It cannot touch anything on your machine. This is a genuine safety property and worth stating positively: whatever the agent gets wrong, it gets wrong on a branch on GitHub. No local file is at risk.

The environment, and why setup matters

Because the agent’s environment is built rather than inherited, a repository that is hard to set up is a repository the agent works badly in.

The practical guidance is stable even as the mechanism changes.

Pin your dependencies. An agent resolving versions itself will resolve them differently from your lockfile at some point, and the resulting failure will look like an agent mistake.

Make the test command obvious and single. npm test, pytest, make check. An agent that has to discover how to run your tests may not, and an agent that cannot run your tests cannot check its own work.

Do not require secrets for basic checks. If unit tests need production credentials, the agent cannot run them, and neither can a new contributor. That is a repository problem the agent merely exposes.

Keep setup in the repository, not in a wiki. The agent reads the repository.

The session, and what it tells you

A cloud agent session is not a black box, and reading one is the fastest way to develop intuition for what these agents actually do.

The draft pull request appears early, before the work is finished. That is deliberate: it gives you somewhere to watch. The session logs record the steps — what it read, what it changed, what commands it ran and what those commands returned.

Two things are worth looking for the first few times.

Where it decided what the task was. This happens in the first steps and almost never changes afterwards. If the interpretation is wrong, everything downstream is wasted, and you will save time by closing the pull request and rewriting the issue rather than reading a diff built on the wrong premise.

What it did after a failure. A failing test or a build error is the most informative moment in a session. An agent that reads the error and adapts is working well. An agent that tries progressively more elaborate ways to make the error go away has usually lost the thread, and the changes from that point on deserve particular scepticism.

What it can reach

Access is the question that decides whether this surface is appropriate for a given task, and GitHub’s defaults are conservative.

The repository you started in. GitHub states that by default Copilot can only access context in the repository specified when you start a task. Cross-repository work is not something that happens implicitly.

A read-only GitHub connection by default. For MCP, the default GitHub server connection uses a specially scoped token with read-only access to the current repository. That is a well-chosen default: the agent can read issues, code and pull requests without being able to change anything through that channel.

Whatever MCP servers a repository administrator configured. This is the part that widens access, and the part that deserves review.

Its own branch and pull request. The write path that matters is deliberately narrow: it produces a branch and a pull request, and that is how work reaches you.

MCP on this surface is different

If you have configured MCP in VS Code, most of what you know transfers except the parts that matter.

Configuration is not a file in the repository. It is JSON entered in repository settings on GitHub, by someone with administrative access. There is no .vscode/mcp.json equivalent to commit.

Only tools are supported. MCP defines tools, resources and prompts. On this surface, tools are what work. A server whose value is its resources will disappoint here.

Remote servers using OAuth are not currently supported. GitHub states this directly. In an IDE, OAuth is often the recommended path; here it is not available, which changes which servers are usable.

There is no approval prompt. In the CLI you approve tool calls. Here you do not — the approval is the pull request review, after the fact.

The MCP guide covers the protocol in full and connecting servers covers per-client configuration including this one.

Cloud agent versus agent mode

They overlap enough to be confusing and differ enough that picking wrong wastes real time.

Cloud agent compared with editor agent mode

Capability	Agent mode (IDE)	Copilot cloud agent
Runs in	Your editor, on your local working tree	GitHub, in a GitHub Actions-powered environment
Reads the repository	Yes	Yes
Modifies files	Yes	Yes
Executes commands	Yes	Yes
Opens pull requests	No	Yes
Custom agents	Yes	Yes
Agent skills	Yes	Yes
MCP	Yes	Yes
Subagents	Not documented	Not documented
Per-action human approval	Yes	Partial

• Agent mode (IDE). Changes appear as a diff you review in the editor before they land.
• Copilot cloud agent. Approval is at the pull request, not per action. GitHub states Copilot uses available MCP tools autonomously and will not ask before use.

The decision rarely turns on capability. It turns on how you want to spend the next half hour.

Choose agent mode when you want to be involved. Exploratory work, anything where you will recognise the right answer when you see it, anything where you expect to redirect after the first attempt. The feedback loop is the point.

Choose the cloud agent when you want to be elsewhere. Well-specified work you would rather not context-switch into. Several independent tasks you want running at once. Anything you are happy to evaluate as a finished pull request.

Choose agent mode for uncommitted work. The cloud agent cannot see it.

Choose the cloud agent when the artefact should be a pull request anyway. Delegating work that would end in a pull request regardless costs nothing extra in process.

The pull request is the safety model

It is worth being explicit about why this surface — the one with the least interactive oversight — is also the one most teams should start with.

Every other agent surface produces changes in a place where review is optional. Agent mode edits your working tree; you can commit without reading carefully. The CLI edits files and runs commands; the approval prompts are per-action and easy to wave through. Both depend on your discipline in the moment.

The cloud agent produces a pull request. Review is not a discipline you have to supply — it is where the artefact already lives, in the process your team already runs, with the checks you already configured. Branch protection applies. Required reviewers apply. CI applies. Secret scanning applies.

1. 1Agent works on a branchNothing on your machine, nothing on main.
2. 2Pull request opensVisible, diffable, commentable.
3. 3Your existing checks runCI, linting, secret scanning, branch protection.
4. 4A human reviewsHuman judgementThe same review the team already does.
5. 5Merge or closeHuman judgementClosing costs nothing.

Steps marked Human judgement are the ones that do not get delegated — they are where you decide whether what Copilot produced is actually right.

This is the strongest argument for the cloud agent as a team’s first agentic step. The riskiest agent configurations are the ones that bypass review, and this one cannot.

Cost and concurrency

Cloud agent sessions are multi-step, and multi-step means multi-request. A session that reads twenty files, makes six edits and runs the test suite four times has done considerably more model work than a chat answer, and the billing reflects that.

Two habits keep this proportionate.

Delegate tasks worth a session. Something you could have done in two minutes in agent mode is not a good use of a delegation, independent of cost — the overhead of specifying and reviewing exceeds the work.

Run several at once deliberately, not accidentally. Parallel delegation is one of the genuine advantages of this surface: three independent, well-specified tasks running while you do something else is real leverage. Three vague tasks running simultaneously is three pull requests you will not review properly.

The request model lesson in Cluster 6 covers how premium requests are counted. The short version for planning purposes: budget for agent work in sessions rather than in messages, and measure your own usage rather than extrapolating from chat.

Limits worth knowing

It is not fast. Sessions take real time. This is a background tool.

It does not ask questions. An ambiguity becomes a decision rather than a clarification request.

Its environment can diverge from yours. A change that passes in its environment and fails in yours is usually an environment configuration gap rather than a code problem.

Cross-repository work needs deliberate setup. The default single-repository scope is a security property, not an oversight, and working around it should be a considered decision.

Availability is policy-gated. Organisations control whether it is enabled and where. If it is not offered, that is the first thing to check.

Large tasks degrade rather than fail cleanly. A delegation that is too big produces a large, plausible pull request rather than an error, and large plausible pull requests are the ones least likely to be reviewed properly. Splitting work into several small delegations is almost always better than one ambitious one.

Enabling it, and who decides

Availability is not purely a function of your plan, which surprises people whose personal account has the feature and whose work account does not.

The plan sets the ceiling. Which Copilot plans include the cloud agent changes over time; check GitHub’s current documentation rather than a blog post.

The organisation sets the reality. For Business and Enterprise, an administrator enables the agent, and can scope which repositories it operates in. A developer cannot turn this on for themselves.

The repository carries the configuration. Environment setup, instruction files and MCP configuration all live at the repository level, which means the agent behaves differently in different repositories of the same organisation — usually because one has been prepared and the other has not.

This layering is worth understanding before troubleshooting. “Copilot is not offered as an assignee” is almost always a policy answer rather than a technical one, and the person who can fix it is an administrator.

What “ephemeral” costs you

The environment being created and discarded per task is mostly a virtue, and it has one consequence worth planning around: nothing carries over.

No warm caches. Dependency installation happens every time. A repository with a slow install spends part of every session on it, which is real time and real cost.

No accumulated understanding. A second delegation in the same area starts from the repository, not from what the first one learned. Anything worth carrying forward has to be in the repository — which is an argument for updating your instructions file after a session that went badly.

No leftover state to debug. The compensating benefit, and a large one. Each session is reproducible from the repository plus the issue, so a session that went wrong went wrong for a reason you can see rather than because of something that accumulated on a machine.

Watching it work

The parts of a session that repay attention, once you decide to look properly.

The first few steps. This is where the task gets interpreted, and the interpretation almost never changes afterwards. A session that has misread the issue in step two is going to produce a confident, coherent, wrong pull request, and you can know that within a minute rather than after reading a diff.

Its response to a failing command. A build error or a failing test is the richest signal available. An agent that reads the error and changes approach is working. An agent that tries progressively more elaborate ways to make the error stop is lost, and everything after that point deserves scepticism.

Files it touched that you did not expect. Visible in the pull request before you read a single line of the diff, and the cheapest signal there is.

How long it spent on setup. A session that used most of its steps installing dependencies and fighting the build has told you something about your repository rather than about the agent.

Common questions

Is “coding agent” the same thing? Yes. GitHub’s documentation has moved to “cloud agent”; the older term describes the same product.

Can it see my local branch? No. It works from the repository on GitHub. Push first.

Does it use my custom instructions? Repository instruction files are part of the repository, so yes. That makes them the most effective way to fix repeated mistakes.

Can it run in a private repository? Yes, subject to your plan and organisation policy.

Can I give it access to a second repository? Cross-repository context is something you arrange deliberately rather than something the default grants. Treat the request as a permission decision, because that is what it is.

Does it work on pull requests as well as issues? Mentioning @copilot in a pull request comment asks for changes on work already in flight, which is the iteration path covered in the previous lesson.

What identity does it act as? Work arrives as a pull request attributed to Copilot, in an environment with the access its configuration grants — by default, read-only access to the current repository through the built-in GitHub connection.

Next

Custom agents covers shaping what an agent is for and what it may touch. The MCP guide explains the protocol behind the external access described here. And if you want the opposite trade-off — full interactivity, per-tool approval, local execution — Cluster 5 covers Copilot CLI.