What are cloud coding agents (Copilot, Devin, Jules, Codex cloud)?

A cloud coding agent is a coding agent that works somewhere else. Instead of running in your editor or terminal, it starts a fresh computer in a data center, copies your project from GitHub or a similar service, and works on the task you gave it: reading code, editing files, installing what it needs and running tests. When it is done, it gives you a summary and a set of changes, most often as a pull request, a proposed change that you can read, discuss and then merge or reject.

The appeal is delegation. You can hand off a bug fix, a dependency update and a missing test at the same time, close your laptop, and come back to three pull requests. The cost is that you were not watching, so reviewing what comes back becomes the most important part of the job.

The main cloud agents in October 2026

GitHub's documentation describes a change arriving this week: from October 28, 2026, paid Copilot users get a new "Copilot in the cloud" experience in which a session started on the web can continue in the Copilot app, an editor or the CLI. The same docs list firm limits worth knowing: one branch and one pull request per task, a 59-minute cap on sessions that run on GitHub Actions, and support only for repositories hosted on GitHub. Codex's details come from OpenAI's Codex pricing page, which notes that cloud tasks may use more of your allowance than local work. Anthropic's Claude Code also runs on the web for long tasks in the same spirit.

A worked example: delegating one task well

Cloud agents can't ask you questions mid-task as easily as a local agent, so the instructions have to carry everything. A good task names the goal, the boundaries and how to check success:

In the repository shop-api, the /orders endpoint returns orders in random
order. Make it return them newest first. Only change files in src/orders/
and tests/orders/. Add a test that creates three orders and checks the
order of the results. Run the full test suite and include the output in the
pull request description. Don't add new dependencies.

Then, while it works, open the session log if the tool offers one. GitHub, for example, shows the steps and tools the agent used, though its documentation is clear that reading a log is no substitute for reviewing and testing the result yourself.

How do you review the work an agent hands back?

Start with the summary, then distrust it. Read the pull request description to learn what the agent claims it did, and then check each claim against the actual changes. Work through this list:

1. Scope. Open the list of changed files. Anything outside the folders you named is a warning sign. A two-line fix that touches twelve files needs an explanation.
2. Tests. Check that the agent added or updated tests, and that it did not delete or weaken existing ones to make them pass. Confirm the tests actually ran: in your continuous integration checks, not only in the agent's own report.
3. The diff, line by line. Read the changes as if a new colleague wrote them. Ask the agent, or a second agent, to explain any part you don't follow.
4. Dependencies and secrets. Look for new packages, changed configuration files, and anything that looks like a key or password.
5. Run it. Check out the branch and try the feature yourself, including one case the agent may not have thought of.

GitHub's own documentation warns that Copilot can produce incorrect code, including code with security vulnerabilities, and asks users to review and test before production; the same caution applies to every agent here. If a change is wrong, comment on the pull request with specific instructions and let the agent revise it, or close it and write a clearer task. Over time, the review notes you keep making are the best material for the project's instruction file, so the next task starts with them already in place.