S3DAT NEWS
· 19 stories RSS s3dat.com

JetBrains Air adds cloud tasks on existing Copilot subscriptions

JetBrains Air added Copilot cloud tasks on November 3, using existing subscriptions. The practical test for teams is whether unattended work produces changes that are worth reviewing.

Spec sheet

Cloud access
Air Teams business organization
Execution
1 fresh virtual machine per task
Secrets
Encrypted storage; environment-variable delivery

A cloud option alongside existing integrations

Cloud access requires a Copilot subscription, an Air Teams-enabled JetBrains business account, and administrator permission. Developers can start tasks in a browser or select the cloud environment inside their IDE. Copilot support in JetBrains IDEs predates this announcement: GitHub’s June update already described an integrated agent picker and earlier Agent Client Protocol support. November’s change concerns where the task runs and which subscription pays for it. A task cannot select personal versus organization Copilot billing.

The remote branch is the starting point

Air’s task list can hold Copilot alongside Claude, Codex and Junie. The integration runs the official Copilot command-line agent and offers its models. Changes must be pushed before the agent can work from them. The GitHub connection under Air’s version-control settings also authenticates the official Copilot command-line agent when its cloud machine starts. There is no separate cloud Copilot sign-in step. The authorization page does not mention Copilot, even though Air reuses the connection to authenticate both services. Tasks appear under their repository in both the IDE and browser, where developers can review the resulting changes. Work can continue after the laptop closes. Air also supports scheduled tasks and repository-triggered automations, including runs started by a new pull request. Selecting Copilot for those automations consumes the same Copilot plan. JetBrains warns that busy pull-request automation can consume credits faster than a weekly maintenance task. Exhausted credits cause runs to fail without an Air warning; usage tracking remains on GitHub.

Isolation has concrete boundaries

Air’s October architecture explanation describes each task as a Docker container inside a new virtual machine. The machine is treated as untrusted, not reused for later tasks, and given limited access to internal resources. Its proxy initially permits a preset set of source-control and package-registry domains. Administrators can add required destinations, allow all domains, or disable internet access. Secrets are encrypted at rest and delivered as environment variables. A teammate can use a shared secret without seeing its value, while personal secrets remain private. Repository access follows the developer’s own permissions. Compared with a Git worktree, which separates file changes on the same machine, this arrangement also separates execution from the developer’s host. These are existing Air isolation controls applied to the new integration, not newly announced sandbox technology.

Claim check

  • Confirmed Copilot spending limits cannot be set in Air. [1]
  • Confirmed Teammates can use shared secrets without seeing their values. [3]

Sources