GitHub Copilot arrives in JetBrains Air: delegate tasks without switching editors

The news in one sentence

On November 3, 2026, GitHub announced in its official Changelog that GitHub Copilot is now available as a coding agent inside JetBrains Air. In plain terms: you do not have to switch editors, and you do not have to buy a second AI allowance, to hand work to Copilot inside JetBrains' new agent environment. Tasks can run locally in your IDE or in an isolated cloud sandbox, billed against the Copilot plan you already have.

The announcement itself is short, but it deserves a full article, because it marks a shift: the coding assistant is moving from "a plugin for one editor" to "an agent you pick inside a neutral environment." Until now, choosing a tool often meant choosing an editor first and accepting whatever assistant came bundled with it. JetBrains Air turns that around: the environment is neutral, the assistant is pluggable, and Copilot is one option among others. For teams that have already standardized on Copilot, that one line in the changelog matters more than a model upgrade.

What actually changed

According to the GitHub Changelog entry dated November 3, 2026, the integration has three parts. First, you can select GitHub Copilot in Air's agent picker and use your existing Copilot subscription for coding tasks, instead of buying JetBrains AI credits. Second, it supports parallel work and in-context review: you can run several agent sessions side by side, give them project context and IDE tooling, and review changes next to your code. Third, cloud tasks run on your Copilot plan: through Air Teams, tasks run in isolated cloud environments, and the cost counts against your Copilot plan rather than JetBrains AI credits.

The technical foundation is worth a sentence, too. The integration uses the Agent Client Protocol (ACP), an open protocol that lets an editor talk to different AI agents through one interface. The point of ACP is that Air does not need a private integration for every assistant; any assistant that speaks ACP can appear in the picker. For users, that means the picker should only gain options over time, rather than locking you into one vendor.

One detail is easy to miss: this does not replace the existing GitHub Copilot plugin. GitHub's own wording is that you can use Copilot in Air alongside the Copilot plugin and choose the workflow that works best for you. In other words, Air is not here to kill the plugin. The plugin suits quick, in-the-flow help; Air suits handing over a whole task, running it in parallel, and reviewing it carefully.

Local tasks versus cloud tasks

Local tasks have a low bar. Install Air in your JetBrains IDE, pick GitHub Copilot in the agent picker, connect your GitHub Copilot account, and go. The task runs on your own machine, with project context and IDE tools at hand, and the changes land where you can see them. This fits everyday work: fixing a bug, adding a small feature, refactoring a module, where you can run the tests and roll back immediately afterwards.

Cloud tasks have a higher bar, and a more enterprise shape. You need a JetBrains account in an Air Teams-enabled business organization, a GitHub Copilot subscription, and Copilot enabled by your Air administrator. There are two ways to run them: in the browser, open Air, connect GitHub under Settings, pick a repository and a remote branch, select GitHub Copilot, and send your prompt; or in the IDE, use the Air plugin and select Cloud from the environment selector. A cloud task runs in a Docker container on a fresh virtual machine, all traffic passes through a proxy, and no state carries over between tasks. Copilot can build, test, and install packages without touching your local environment.

This is really a distinction between two ways of working. A local task is pairing: you sit at the machine, watch, and steer. A cloud task is delegation: you hand over a task sheet and come back to check the result. The first fits work that needs your live judgment; the second fits long, multi-step work that does not need you watching. Putting both in one picker matters because delegation finally has an official Copilot entry point inside the JetBrains world.

Four limits you must know before rolling out

The limits listed in the official Changelog are unglamorous, but they decide whether a rollout goes smoothly. First, connecting GitHub Copilot to Air does not request GitHub Copilot permissions; Air may only verify subscription or credit availability when the cloud environment starts. If your subscription or credits are unavailable, the task fails and an error appears in the session. Permissions do not get more complicated, but an allowance shortfall now fails at task start, not at code submission.

Second, you cannot choose per task whether it uses your personal Copilot plan or your organization's plan. There is no switch that says "this task on my plan, that task on the company's." Know which plan your current account carries before you start a task.

Third, Air's governance and analytics features do not include Copilot usage. Administrators can see Air's own governance data in Air, but what Copilot spent inside Air has to be checked on GitHub's side. If your team does cost accounting or usage audits, do not assume one Air dashboard covers everything.

Fourth, administrators can disable GitHub Copilot through a governance policy, but they cannot set Copilot spending limits inside Air. The control is an on/off switch, not a spending cap. If your company needs caps, they still have to be set on the GitHub Copilot side; Air can only decide whether Copilot is allowed at all.

Taken together, the picture is clear: this is a "get the road open first" integration, not a "finish all the governance" integration. The road is open; the ledgers, caps, and fine-grained controls still live in their own systems. Pilot with that expectation, and you will not be surprised at acceptance time.

What it means for three kinds of people

For individual developers, the benefit is immediate: you already pay for Copilot, and now JetBrains' agent environment can use the same subscription, with no second allowance to buy just to try Air. Start with local tasks, pick a small task you know well — adding tests for a utility function, for example — and compare the agent's changes in Air with what you get from the plugin. Then decide whether longer tasks are worth handing over.

For team leads, the key word is consolidation. Where a team once had some people on VS Code plus Copilot and others on JetBrains plus JetBrains AI, with two separate bills, the JetBrains side can now run on Copilot too, and the bill can become one. But remember the limit above: usage reporting does not live in Air, so before merging the books, confirm that GitHub-side usage reports cover tasks run inside Air, or the month-end reconciliation will contain a charge nobody can explain.

For platform vendors and tool authors, the signal is longer term. Once an open protocol like ACP becomes the base of the picker, competition moves from "whose editor is better" to "whose agent is worth picking." Editor vendors can no longer retain users by bundling an assistant, and assistant vendors can no longer win by monopolizing an editor. Users benefit: the more options in the picker, the lower the switching cost, and the harder vendors have to work on actual results to keep you.

My judgment: pilot local tasks first, wait on cloud governance

My advice is concrete. In week one, run only local tasks, limited to work where changes are reviewable, tests are runnable, and rollback is possible, and record the share of agent changes you have to fix by hand. That share is your team's real adoption cost, not a number from a vendor's marketing page. Second, try cloud tasks with one or two long tasks that have clear acceptance criteria written into the task sheet — for example, "upgrade this batch of dependencies and get the tests green" — and judge only the test report and the diff, not the process description. Third, enterprise users should confirm allowance and cap policies on the GitHub side before promoting anything, rather than discovering an allowance mismatch after a batch of Air tasks has failed.

One more caution: a cloud sandbox that shares no state between tasks sounds clean, but it also means every task pays a cold-start cost — installing dependencies, reading the repository, understanding the project structure. Short tasks may not be worth sending to the cloud at all; long tasks are where that cost pays off. Work that arithmetic out during the pilot, rather than in a post-mortem.

Put the three routes side by side and the choice becomes practical, not ideological. The plugin fits work at hand, where the assistant completes, explains, and edits a small piece while you type. Air local tasks fit "one task, one block of time," where the agent works across files, runs tests, and fixes a round itself, while you review. Air cloud tasks fit "hand it over and check later," where long, multi-step, independent tasks run in parallel without occupying your machine. Three routes coexisting is not waste; it is division of labor — and GitHub's own note that the plugin and Air are meant to be used together says the vendor sees it the same way.

A pilot checklist, to copy: run three tasks in each of three categories — bug fix, small feature, dependency upgrade — and record first-pass rate, the share of lines you edit by hand, and total time from task to green tests. Set review rules before opening permissions: agent changes must carry test results, large diffs must be split into multiple commits, and changes touching auth, payments, or data migration get line-by-line human review. Set a cost definition before talking about rollout: Copilot allowance, cloud sandbox time, and your review time together make up the true cost of a task. And settle the rollback path before touching anything production-adjacent: local rollback is just git, but cloud rollback depends on whether the output returns as a branch push, a pull request, or a diff for you to merge — different merge paths carry different risks.

Finally, the responsibility question. Code the agent writes is signed by you, merged by you, and owned by you when it breaks — "the AI wrote it" changes none of that. If anyone on the team starts treating agent output as vendor-guaranteed code, review will slacken, and slack review fails eventually, not occasionally. So the most important pilot rule is not technical at all: whoever merges owns it; the agent is the pen, not the owner. Tasks where a mistake is costly but cheap to catch — bulk formatting, test coverage, dependency upgrades with tests — are ideal for agents, because the tests catch the error immediately. Tasks where a mistake is costly and expensive to review — auth logic, billing rules, migration scripts — need smaller slices, written acceptance criteria, and human review before merge, not after.

And the bottleneck nobody sells a tool for: the task sheet itself. "Build this feature" and a sheet that states inputs, outputs, edge cases, and what counts as passing are very different amounts of work. In the agent era, writing the task sheet is writing the requirements document, except the reader is a model. If your team keeps complaining that the agent "doesn't understand," check first whether the sheet only said half the job — a model cannot read minds; it can only work with what you gave it.

All in all, Copilot in Air is not a model launch; it is a change of position, from the plugin bar into the agent picker. Positions change how people work. For JetBrains users, this is the cheapest moment to try it: the subscription is already paid for, the environment is already there, and all that is missing is a task sheet worth handing over.