Devin vs GitHub Copilot Cloud Agent

Devin and GitHub Copilot’s cloud agent do the same kind of work: you hand over a task, the agent works on a machine of its own, and you get back a pull request to review. The difference is how far each reaches beyond GitHub. Copilot’s cloud agent lives inside GitHub: it runs in a GitHub Actions environment, works on one GitHub repository per task, and cannot approve or merge its own pull request. Devin is a separate product from Cognition: it runs on its own virtual machine, works with GitHub, GitLab, Bitbucket and Azure DevOps, and is started as often from Slack, Linear or Jira as from a repository. Choose Copilot’s cloud agent if your team already lives on GitHub and wants delegation with GitHub’s own guard rails. Choose Devin if your code or your tickets live elsewhere, or you want one agent across several repositories and hosts. Both statements describe the vendors’ documentation as of September 30, 2026.

Two notes on names. GitHub renamed Copilot coding agent to Copilot cloud agent in 2026; the step-by-step from issue to pull request is in the GitHub Copilot coding agent. Devin is now a family of products, and the IDE formerly called Windsurf is Devin Desktop; what Devin is, and how it compares with a pairing agent, is in Devin vs Claude Code. This page compares the two delegated agents only.

Where each one works

• Copilot cloud agent: according to GitHub’s page about the cloud agent↗ (opens in a new tab), it works in its own ephemeral development environment powered by GitHub Actions, where it explores code, runs tests and linters, and stops after 59 minutes, a hard limit. A copilot-setup-steps.yml file installs your dependencies before it starts.
• Devin: Cognition’s environment setup page↗ (opens in a new tab) describes a Linux virtual machine with your repositories cloned, tools installed and secrets set, saved as a snapshot that every session boots from. Each organization has one active snapshot, and the quickest way to build it is to ask Devin to set up its environment for the repository. Windows and macOS machines are also documented for teams that need them.

The practical difference is setup cost against reach. Copilot’s environment is a workflow file in the repository, rebuilt for each task. Devin’s is a machine image your organization maintains once, which can hold several repositories and the credentials to reach them.

Where the code has to live

• Copilot cloud agent works only on repositories hosted on GitHub, changes only the repository named when the task starts, and opens one pull request per task on a branch whose name starts with copilot/.
• Devin connects to GitHub, GitLab, Bitbucket and Azure DevOps, opens pull requests or merge requests on each, and can split a large change into an ordered stack of smaller pull requests on GitHub.com.

If any of your code is outside GitHub, that settles it for that code: the Copilot cloud agent cannot reach it.

Where a task can start

• Copilot: assign an issue to Copilot, type a prompt in the agents panel, mention @copilot on a pull request, press Fix with Copilot on a failed job, or run it from VS Code, the GitHub CLI or an automation. It also works from Slack and Microsoft Teams, where research, planning and iterating are in public preview, and from Jira, Linear and Azure Boards, which only support creating a pull request directly.
• Devin: start a session from its web app, tag @Devin in Slack or Microsoft Teams, assign a Linear or Jira ticket or add a playbook label to it, comment /devin followed by a request on an open GitHub pull request, call the API, or set an automation that fires on a schedule, a webhook or an event in Slack, GitHub or Linear.

Both now start from a tracker. The gap is depth: from Jira or Linear, Copilot goes straight to a pull request, while Devin can also be asked only to scope a ticket first. Whichever you use, the ticket is the prompt, so the advice in how to write a task for an AI agent applies to both.

Guard rails, and who the agent acts as

This is the difference that matters most to a team lead. GitHub’s page on risks and mitigations↗ (opens in a new tab) sets fixed limits: only people with write access can start the agent; it pushes to a single branch; it cannot mark its pull request ready for review, approve it or merge it; your Actions workflows do not run on its pushes until someone with write access approves them; its internet access is restricted; and its commits are signed and link to the session log.

Devin works as a GitHub App your organization installs, with read and write access to contents, pull requests, checks and workflows. Its GitHub integration page↗ (opens in a new tab) says Devin uses the permissions granted at the organization level, not those of the person running the session, and recommends branch protection on your main branch so required checks pass before Devin can merge. An admin can also have pull requests opened under the linked user’s own GitHub account instead of as Devin.

So the limits sit in different places. Copilot’s are built into the product and the same for everyone. Devin’s are yours to set: branch protection in GitHub, and in Devin, security profiles↗ (opens in a new tab) that restrict a session’s network destinations, which MCP servers it may use, and its git access, applied as an organization default, per automation or per session.

Standing instructions and reusable know-how

• Copilot reads repository custom instructions and AGENTS.md, which surfaces read which is in does GitHub Copilot support AGENTS.md?. Custom agents give it a specialist persona per kind of task; see GitHub Copilot custom agent examples. It also runs hooks and skills, and Copilot Memory, in public preview on some plans, lets it keep what it learns about a repository.
• Devin reads AGENTS.md too, and its documentation says it injects up to 16 KiB from the start of each file automatically, so keep the rules that matter near the top. Playbooks hold reusable prompts attached with a macro such as !plan, and skills, SKILL.md files in your repository, carry procedures such as how to test or deploy.

Tools over MCP

Both agents reach other systems through MCP, with one important difference. GitHub’s MCP configuration page↗ (opens in a new tab) says the cloud agent uses a configured server’s tools autonomously, without asking for approval, and does not currently support remote servers that sign in with OAuth; it recommends allowlisting specific read-only tools. The GitHub and Playwright servers are on by default. Devin takes servers from Customize, MCPs, over stdio, SSE or Streamable HTTP, with no authentication, an auth header or OAuth, and its marketplace installs common ones as plugins.

Which fits which team

• Everything is on GitHub, you already pay for Copilot, and you want fixed guard rails nobody has to configure: the Copilot cloud agent.
• Your code is on GitLab, Bitbucket or Azure DevOps, or spread across hosts: Devin.
• Most work arrives as Jira or Linear tickets and you want the agent to scope as well as build: Devin has more ticket-side options; Copilot opens a pull request.
• You want to try other vendors’ agents without another contract: GitHub also runs Anthropic Claude and OpenAI Codex as third-party agents beside its own. Devin is not one of them.
• Tasks that need a desktop and a browser to test the change, or more than an hour of work: Devin, whose own rule of thumb is a task you could do in about three hours. Copilot’s sessions stop at 59 minutes, so split the work instead.

Either way, the review is still yours. Delegation saves attention while the work happens and spends it at the end; verifying AI-generated work has the checks to run before you merge.

One board for both

A GitHub issue and a Devin session each record one change. Neither shows the plan the change belongs to, work in other repositories, or tasks that are not code. fenbs holds that list for people and assistants, and both agents reach it as an MCP server at https://fenbs.ai/api/mcp. Because the Copilot cloud agent cannot sign in with OAuth, issue a token by hand under Settings, “Connect an AI assistant”, with a name, only the scopes it needs and an optional expiry, and use it as a header in both. Every comment and move is then recorded in History under the assistant’s name, on your behalf, and revoking the token stops it at once.

Copilot: repository Settings, Copilot, MCP servers
{ "mcpServers": { "fenbs": {
    "type": "http", "url": "https://fenbs.ai/api/mcp",
    "headers": { "Authorization": "Bearer $COPILOT_MCP_FENBS_TOKEN" },
    "tools": ["fenbs_get_item", "fenbs_search", "fenbs_comment"] } } }

Devin: Customize, MCPs, Add custom MCP
  Transport: HTTP   URL: https://fenbs.ai/api/mcp
  Authentication: Auth Header   Value: Bearer <token from fenbs Settings>

Be clear about what fenbs does not do. It has no assignee field and no due dates, so nothing on the board starts either agent. Put the board reference, such as BUG-031, in the issue or ticket; the agent reads that task, comments with the pull request link and what it tested, and a person moves the task to Completed after the merge.