GitHub Copilot Arrives in JetBrains Air: Cloud Tasks Use the Copilot Plan and Run in Docker on a Fresh VM, but Air Shows No Copilot Usage and Sets No Spending Limits

On November 3, 2026, GitHub announced in its changelog that GitHub Copilot is now available in JetBrains Air. JetBrains Air is an agentic development environment, and the integration uses the Agent Client Protocol (ACP). Developers can delegate coding tasks, guide execution and review results with Copilot inside Air, either on tasks that run in their JetBrains IDE or on tasks that run in the cloud. GitHub says Copilot in Air can be used alongside the existing GitHub Copilot plugin, so teams can pick the workflow that suits them.

Three changes are listed. Copilot appears in Air's agent picker, and tasks use the developer's existing Copilot subscription. Air can track several agent sessions at once, use project context and IDE tools, and show changes next to the code for review. And cloud tasks run in isolated cloud environments through Air Teams, from the IDE or the browser, on the Copilot plan instead of JetBrains AI credits. The last point matters for budgets: cloud usage is billed through the Copilot subscription.

Setup differs for the two modes. For local tasks, a developer installs Air in the JetBrains IDE, selects GitHub Copilot and connects a Copilot account. For cloud tasks, three things are needed: a JetBrains account in a business organization with Air Teams enabled, a GitHub Copilot subscription, and Copilot enabled by the Air administrator. In the browser, the user connects GitHub under Settings and VCS Providers, creates a task, picks a repository and remote branch, selects Copilot and sends a prompt. In the IDE, the user picks Cloud in the environment selector.

On where cloud tasks run, the changelog says Copilot works in a Docker container on a fresh virtual machine, all traffic passes through a proxy, and no state carries over between tasks, so Copilot can build, test and install packages without changing the local environment. A JetBrains blog post from October 14 gives more detail on the same design. The virtual machine is treated as untrusted and is not reused between tasks. By default the proxy allows connections only to a preset list of trusted source control and package registry domains, such as npm, and admins can add domains, allow all domains or turn internet access off. Secrets are stored encrypted and exposed to a task as environment variables, and each task acts within the developer's own repository permissions. That post also says the cloud agents were a preview, available to organizational users, with a wider release for individuals planned later, and that microVMs were still "coming soon."

The "Cloud task considerations" section is the most useful for administrators, because it lists limits. Connecting Copilot to Air does not request Copilot permissions, and Air may only check subscription or credit availability when the cloud environment starts, so a task can fail at that point with an error in the session. A developer cannot choose per task between a personal Copilot plan and an organization plan. Air's governance and analytics features do not include Copilot usage. Air administrators can disable Copilot through a governance policy but cannot set Copilot spending limits inside Air.

Put together, these limits mean Air excludes Copilot usage from its analytics and cannot set Copilot spending limits; corresponding reporting and controls on GitHub's side need separate confirmation, and the plan used for a task is not a per-task choice. Teams that need cost control or usage reports should decide where that control will live before enabling it. The changelog also does not state which Copilot plans qualify, what models run, or how much a typical task costs, and it gives no performance or quality results. It is a feature announcement with a feedback channel, through in-product feedback, a feedback repository and a private survey, so the details may change as the integration is used.