The detail that matters most is that there are two execution paths with different requirements and different gaps in administrative control. Teams that treat them as one feature will probably hit surprises with billing and monitoring.
What's new
GitHub lists three changes:
- Copilot in Air's agent picker. You select GitHub Copilot and use your existing Copilot subscription for coding tasks.
- Parallel work and in-context review. You can track multiple agent sessions, use project context and IDE tools, and review changes next to your code.
- Cloud tasks on your Copilot subscription. Copilot runs in isolated cloud environments through Air Teams, from the IDE or a browser. These tasks draw on your Copilot plan rather than JetBrains AI credits.
GitHub says Copilot in Air is meant to be used alongside the GitHub Copilot plugin, not instead of it. You pick whichever workflow suits the job.
It wasn't impossible before
Copilot in Air is not entirely new. JetBrains' July Air release added support for ACP-compatible agents, including GitHub Copilot. That route connected Air to the Copilot CLI in its ACP server mode. It let people use company-managed Copilot access in Air, with the CLI running the agent and supplying models, and Air adding parallel workspaces and its review workflow.
That setup was manual. A JetBrains Air guide said Air did not yet download or configure the agent for you, and that a browsable ACP registry was planned for later. Developers edited an acp.json file to register the agent. The same guide noted that resuming an existing Copilot session through Air was not yet supported.
The November announcement turns that workaround into a named option in the agent picker. It also adds the cloud path. I could not verify from the sources whether the session-resume limitation has changed, so I won't claim it has.
Local tasks
GitHub's local setup is short:
- Install Air in your JetBrains IDE.
- Select GitHub Copilot in the agent picker.
- Connect your GitHub Copilot account.
JetBrains' quickstart explains the run environments you can choose for a task. These are the general Air options, and the announcement doesn't say which ones apply to Copilot.
- Local Workspace. The agent runs on your machine and writes directly to your working copy.
- Git Worktree. The agent works in a separate worktree on its own branch, so your main working copy is untouched until you apply the result.
- Docker. The agent runs in an isolated container with its own filesystem.
JetBrains' guidance on applying changes follows from this. With a Local Workspace task, the edits land in your working copy directly, so review the diff before committing. With the isolated modes, Air can copy the changes in as uncommitted edits or check out the task branch.
Cloud tasks
Cloud tasks have stricter prerequisites. You need all three of these:
- A JetBrains account in a business organization with Air Teams enabled.
- A GitHub Copilot subscription.
- Copilot enabled by your Air administrator.
There are two ways to start a cloud task:
- Browser. Open Air in your browser and connect GitHub under Settings > VCS Providers. Create a task, choose your repository and remote branch, select GitHub Copilot, and send your prompt.
- IDE. Use the Air plugin in your JetBrains IDE and choose Cloud from the environment selector.
Where the work happens
GitHub says a Copilot cloud task runs in a Docker container on a fresh virtual machine. All traffic goes through a proxy, and no state carries over between tasks. Copilot can build, test, and install packages without changing your local environment.
JetBrains' October explanation of Air's cloud sandboxing gives more general detail:
- Each task starts a VM in the cloud, and the agent runs in a Docker container inside it.
- The VM is treated as untrusted and isn't reused between tasks.
- By default, the proxy allows only a preset list of trusted source-control and package-registry domains. Administrators can add domains, allow all domains, or turn internet access off.
- Secrets are stored encrypted and passed to tasks as environment variables.
- Each task uses the developer's own repository permissions, so it can't see repositories that developer can't already reach.
This describes Air's cloud architecture in general. GitHub's announcement independently confirms only the proxy routing and the lack of state between tasks for the Copilot integration.
Isolation limits the damage an agent can do to your machine. It doesn't make the code correct or ready to merge. Review the diff the same way you would a colleague's pull request.
Limits administrators should know about
GitHub lists several considerations for cloud tasks:
- Subscription checks. Connecting Copilot to Air doesn't request GitHub Copilot permissions. Air may check subscription or credit availability only when the cloud environment starts. If either is unavailable, the task fails and an error appears in the session.
- Plan selection. You can't choose whether a given task uses your personal Copilot plan or your organization's plan.
- Usage visibility. Air's governance and analytics features don't include Copilot usage.
- Spending controls. Administrators can disable Copilot through a governance policy but can't set Copilot spending limits inside Air.
Taken together, a task can bill to a plan the user didn't pick, and Air won't report on it. Administrators also can't cap spending from Air. The only lever there is the on/off policy.
The announcement doesn't say which external tools cover that gap, so check your own Copilot administration for usage monitoring and spending controls before you enable the feature. That is my reading of the gap, not guidance from GitHub or JetBrains.
A failed task is also a practical troubleshooting signal. If a cloud task errors at startup, GitHub's description points first at whether the Copilot subscription or credits are available.
Where it fits among the Copilot entry points
GitHub's documentation describes three entry points in JetBrains IDEs: the Copilot plugin, Copilot in JetBrains AI Assistant, and the Copilot CLI in the integrated terminal. GitHub calls the plugin the most comprehensive way to use Copilot and its recommended choice. Its listed capabilities include inline and next edit suggestions, chat, agentic features, code review, and commit message generation.
Copilot in JetBrains AI Assistant provides chat and agentic tasks and model selection. A June 30 GitHub changelog covered that integration, which let you pick Copilot models in the AI chat. That is a separate surface from Air.
JetBrains' own comparison page for Air shows the trade-off from its side. For Copilot, it contrasts working in your JetBrains IDE and using JetBrains diffs, inspections, and line comments with the Copilot plugin's own diff experience. It also says local sessions don't require a JetBrains AI plan.
Who should care
- Developers using JetBrains IDEs who want to run several agent sessions in parallel and review diffs with IDE tooling.
- Organizations standardized on Copilot that want Air's multi-session workflow without buying separate AI credits.
- Administrators who need to settle billing attribution and usage monitoring before turning on cloud tasks.
The announcement's own comparison and FAQ page wasn't accessible when this was researched, so the changelog is the primary source for the terms above. Check it for any later changes to the limitations.