What happened
On October 28, 2026, GitHub announced that GitHub Copilot SDK is becoming Microsoft Copilot SDK. GitHub frames the move as an expansion of the SDK’s role rather than a discontinuation: what began as an SDK for the GitHub Copilot harness is intended to become the programmable interface for the Microsoft Copilot harness. GitHub describes that harness as a shared agent foundation used across Microsoft and GitHub products.
The stated goal is to let developers build and customize agent experiences on the same core foundation that powers Microsoft’s and GitHub’s own products. GitHub says developers will retain control over their prompts, tools, policies, and application experiences. The announcement does not specify a new API, a new model, new pricing, or a feature that users can enable today. Its concrete message is about the direction and organizational scope of the SDK.
The transition has already started in limited operational form. GitHub says it has begun updating the SDK repository for an upcoming move to the Microsoft organization, and it has started updating branding and documentation. The migration will happen in phases. As a result, existing package names, namespaces, and some documentation may continue to use the GitHub Copilot SDK name during the transition. That coexistence is deliberate, not evidence that the transition has been reversed or completed.
For current users, GitHub’s instruction is notably conservative: no immediate changes are required. Support for the Copilot SDK remains the same. Teams using the SDK therefore have no source-grounded reason to rush a code migration now. They do, however, have a reason to treat the current GitHub-specific identity as transitional and to watch future repository, package, namespace, and documentation notices. The announcement establishes the destination—a Microsoft-level programmable interface around a shared harness—without yet publishing the full migration mechanics.
What the archive adds
This is a new fact on a known Copilot SDK story. Earlier coverage recorded the release of Copilot SDK 1.0.28 alongside CLI model-selection changes in GitHub Copilot CLI 1.0.105 lets users pick Copilot Fusion High or Max from long-context sessions; Copilot SDK 1.0.28 follows. That note concerned a version release; this announcement changes the SDK’s stated product and organizational direction.
Trend signal
The announcement supports Harness architecture outlives model choice. GitHub is presenting the SDK’s enduring surface not as access to one named Copilot product or model, but as a programmable interface to a harness shared across products. The evidence is directional rather than proof of technical unification: GitHub has not yet documented the final API or migration path.
Connections to other events
The same archive note on GitHub Copilot CLI 1.0.105 and Copilot SDK 1.0.28 shows that this branding transition arrived alongside active Copilot CLI and SDK releases. Separately, GitHub Copilot moves into Slack and Microsoft Teams described GitHub launching Copilot agent sessions from team communication tools. Together, these items point to Copilot being presented across more surfaces, while the SDK is positioned around a common underlying harness.
Why it matters
For teams embedding Copilot-style agent behavior in their own software, the news changes the strategic boundary to watch. A GitHub-branded SDK is being positioned as part of a broader Microsoft Copilot foundation. That may eventually make a common harness more relevant than the original product label when teams assess integration choices, ownership, support expectations, and internal abstractions.
The immediate operational consequence is modest. Do not rewrite integrations solely because of this post: GitHub says no immediate changes are required and support remains unchanged. Instead, avoid hard-coding assumptions that the repository, packages, namespaces, and documentation will permanently retain GitHub Copilot SDK branding. Keep those identifiers isolated in dependency configuration and internal integration notes, where a phased rename will be easier to manage and review.
Limits and uncertainty
The announcement does not establish when the repository move will occur, which packages or namespaces will change, whether compatibility layers will be supplied, or whether the SDK’s APIs will differ under the Microsoft Copilot name. It does not provide pricing, access requirements, supported products, model availability, migration tooling, or a deprecation schedule. “Shared agent foundation” is GitHub’s product description, not a published technical architecture. Builders should therefore distinguish the confirmed branding and directional transition from unannounced implementation details.
Skill to build now
This week, inventory the places where your application, deployment scripts, dependency manifests, and internal runbooks name GitHub Copilot SDK. Put those references behind a small configuration or integration boundary where practical. The work is not a migration; it is preparation for a phased rename whose final package and repository details have not yet been published.
Reader takeaway
GitHub Copilot SDK is not being dropped, and existing users do not need to act immediately. But it is being repositioned as Microsoft Copilot SDK: a programmable interface for a shared harness across Microsoft and GitHub products. Treat the current name and repository location as transitional, and wait for specific migration guidance before changing production integrations.
Open question
What compatibility guarantees, package names, repository timing, and migration tooling will Microsoft publish as the phased transition reaches existing SDK users?