GitHub expanded Copilot into several development surfaces during November 3–6, 2026. The changes include JetBrains Air, a public preview in Xcode’s built-in assistant, and general availability of @GitHub in Slack and Teams. The common direction is delegation from the place where a developer is already working.
Xcode has a new integration path
The November 4 announcement puts Copilot in Xcode’s built-in coding assistant, starting with Xcode 27.3 beta. GitHub identifies this as a public preview, separate from its existing Xcode extension. Setup is through Xcode’s Intelligence settings, with macOS Tahoe 26.6 or later required. GitHub says all Copilot plans are supported.
Air supports local and cloud tasks
GitHub’s November 3 JetBrains Air release uses the Agent Client Protocol and the developer’s Copilot subscription. Local tasks run through the IDE integration. Cloud tasks require an Air Teams-enabled business organization and administrator enablement in addition to a Copilot subscription.
The cloud environment is a Docker container on a fresh virtual machine, with proxied traffic and no state retained between tasks. GitHub also lists governance limits: Air’s analytics do not include Copilot usage, administrators cannot set Copilot spending limits within Air, and users cannot select a personal versus organization plan for an individual task.
Team conversations can start coding work
The November 6 Slack and Teams release lets users ask @GitHub to investigate a bug, create an issue, implement a change, or open a pull request. Repository recognition reduces setup steps. Created issues and pull requests carry attribution to the conversation and user.
GitHub also describes Canvas in Teams for reviewing plans and changes alongside discussion. A team-chat interaction can therefore become the starting point for a repository change, rather than remain a separate discussion someone later translates into a development task.
Evaluate the boundaries, not just the interface
Our engineering analysis is to test the same small task across the surfaces the team actually uses. Record which repository and branch were selected, what environment executed commands, how dependencies were supplied, and where the final patch can be reviewed.
A cloud task’s fresh environment can improve isolation while exposing hidden setup assumptions. If a build works only because of an unrecorded local dependency, that difference is useful evidence. Resolve it in the documented development process rather than copying a broad set of credentials into the remote environment.
For chat-launched work, make the requested outcome and reviewer explicit. A casual conversation can contain several competing suggestions, so a pull request should preserve the specific goal that was authorized. Review code and tests through the repository’s normal controls before merging.
The integrations add convenience, but they do not create identical administrative or billing behavior everywhere. The right adoption decision depends on the supported version, execution location, cost visibility, and review path of each surface.