GitHub Copilot SDK Hits GA: Embed the Copilot Agent Runtime in Your Own Apps

TL;DR
GitHub Copilot SDK is generally available: embed the Copilot agent runtime in your apps across six languages. What changed at GA and what it means for builders.
Last updated: October 19, 2026
Updated October 19, 2026: The two code samples in the original post were labelled illustrative, and both were wrong. The TypeScript client has no client.chat() method: you start a CopilotClient, create a session with createSession() and send prompts to it. The Python package github-copilot-sdk imports as copilot, not github_copilot_sdk, and tools are passed to create_session() rather than to the client constructor. Both samples are now adapted from the official Node.js and Python READMEs and checked against @github/copilot-sdk and github-copilot-sdk 1.0.22. The CLI-bundling detail was also backwards: per the repository README, the Node.js, Python and .NET SDKs bundle the Copilot CLI, while Go, Java and Rust expect it on PATH.
Official Sources#
| Resource | URL |
|---|---|
| Copilot SDK GA changelog | github.blog/changelog/2026-06-02-copilot-sdk-is-now-generally-available |
| Copilot SDK repository | github.com/github/copilot-sdk |
| Copilot app announcement | github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience |
| Model Context Protocol | modelcontextprotocol.io |
What GitHub Shipped#
On June 2, 2026, alongside Microsoft Build, GitHub announced that the Copilot SDK is now generally available. The pitch is straightforward: instead of building your own agent orchestration layer, you embed the same runtime that powers GitHub Copilot directly into your own applications, services, and developer tools, with a stable API and production support.
This is the same engine GitHub uses internally. Per GitHub's own framing, the SDK "exposes the same agentic runtime that powers the Copilot app." The desktop app, the refreshed CLI, and your custom integration all sit on one foundation. That is the part worth paying attention to, because it changes what "build an agent" means for a lot of teams.
If you have been following the GitHub side of the agent race, this slots in next to the work we covered in GitHub Copilot Coding Agent and CLI. The coding agent was about Copilot doing autonomous work inside GitHub. The SDK is about you taking that same autonomy and pointing it at your own product.
Six Languages, One Runtime#
At GA the SDK supports six officially maintained language bindings. Rust and Java are new at GA; the rest graduated from public preview.
| Language | Install |
|---|---|
| Node.js / TypeScript | npm install @github/copilot-sdk |
| Python | pip install github-copilot-sdk |
| Go | go get github.com/github/copilot-sdk/go |
| .NET | dotnet add package GitHub.Copilot.SDK |
| Rust | cargo add github-copilot-sdk |
| Java | Maven / Gradle (com.github:copilot-sdk-java) |
The repository is MIT licensed, which matters if you are embedding it into a commercial product.
How it actually works under the hood#
The architecture is worth understanding before you commit to it, because it is not a thin HTTP wrapper around an inference API. GitHub's repo describes the data path as:
Your Application -> SDK Client -> JSON-RPC -> Copilot CLI (server mode)
The SDK is a client that talks over JSON-RPC to the Copilot CLI running in server mode. The CLI is the agent. That has two practical consequences:
- You inherit the CLI's first-party tools. GitHub notes the SDK "exposes the Copilot CLI's first-party tools, similar to running the CLI with
--allow-all." So file reads, edits, grep, and shell-style actions are available out of the box. That is powerful and also exactly the surface you need to sandbox. - Whether the CLI ships with the SDK depends on the language. Per the repository README, the Node.js, Python and .NET SDKs bundle the Copilot CLI as a dependency, so a package install is enough. For Go, Java and Rust you install the CLI yourself or make sure
copilotis onPATH(Go and Rust also offer application-level bundling; the GA changelog described the new Rust SDK as bundling the CLI by default). Either way, a real CLI process runs next to your app.
If your mental model was "call a chat endpoint," recalibrate. You are running a local agent process and driving it programmatically.
A Minimal Session#
A basic call is a session, not a single chat completion. This is adapted from the Node.js SDK README quick start, using its sendAndWait() helper:
import { CopilotClient, approveAll } from "@github/copilot-sdk";
const client = new CopilotClient();
await client.start();
// approveAll auto-approves every tool call - fine for a demo, not for production
const session = await client.createSession({
model: "gpt-5",
onPermissionRequest: approveAll,
});
// The default wait is 60 seconds; agent tasks often need longer
const reply = await session.sendAndWait(
{ prompt: "Add Stripe checkout to my Next.js app" },
10 * 60_000,
);
console.log(reply?.data.content);
await session.disconnect();
await client.stop();
For streaming, subscribe to session events instead (session.on("assistant.message", ...) and session.on("session.idle", ...)) and call session.send().
The difference from a plain model call is that "Add Stripe checkout to my Next.js app" is not answered with prose. The agent plans, reads your files, and proposes edits, using the CLI's tool surface. Streaming and multi-turn sessions are first-class, so you can wire the token stream into your own UI and keep a session alive across turns.
What Is New at GA#
The preview already had sessions and streaming. GA added the pieces you need to actually ship and operate this in production.
Custom tools and MCP#
You can register your own tools that the agent invokes autonomously, and you can connect to Model Context Protocol servers. You can also override built-in tools. That last point is underrated: if you do not want the agent shelling out or editing arbitrary files, you can replace edit_file or grep with your own constrained implementation.
A custom tool in Python uses the @define_tool decorator with a Pydantic model for its parameters, and the tool is attached to a session. Adapted from the Python SDK README:
from pydantic import BaseModel, Field
from copilot import CopilotClient, define_tool
from copilot.session import PermissionHandler
class AnalyticsQuery(BaseModel):
query: str = Field(description="SQL query")
@define_tool(description="Query analytics database for metrics")
async def query_analytics(params: AnalyticsQuery) -> str:
return await run_readonly_query(params.query) # your own code
async with CopilotClient() as client:
async with await client.create_session(
on_permission_request=PermissionHandler.approve_all,
model="gpt-5",
tools=[query_analytics],
) as session:
...
The README also documents a low-level form (copilot.tools.Tool with a hand-written JSON schema and a handler) if you would rather not use Pydantic.
If you have built tools for the OpenAI Agents SDK or Codex SDK, the JSON-schema tool definition will feel familiar. MCP support means you can also reuse servers you already run instead of rewriting integrations per SDK. For context on which MCP servers are worth your time, see 271 MCP Servers: The Top 5 That Matter.
A hook system#
GA introduced hooks to intercept agent behavior at defined points: pre and post tool use, session start, MCP tool calls, and permission requests. This is the governance layer. If you are putting an autonomous agent in front of your filesystem and shell, the permission-request hook is where you enforce "ask a human before deleting files" or "never touch infra/." Treat it as a requirement, not a nicety.
Production plumbing#
GA also added the operational details that separate a demo from a service:
- OpenTelemetry tracing with W3C trace-context propagation, so agent runs show up in the same observability stack as the rest of your services.
- Flexible authentication: GitHub OAuth, GitHub Apps, environment tokens, and bring-your-own-key. BYOK is the notable one, because it means non-Copilot users can use the SDK with their own model keys.
- Cloud and remote sessions, so a session can be backed by a GitHub-hosted environment or driven through a remote session URL rather than always running locally.
- Fine-grained system-prompt customization, letting you modify specific prompt sections independently instead of replacing the whole thing.
- Slash commands and interactive prompts now consistent across all six SDKs.
Pricing and Access#
The SDK is available to all existing GitHub Copilot subscribers, "including Copilot Free for personal use, and to non-Copilot users via BYOK." In plain terms: if you already pay for Copilot, the SDK is included. If you do not, you can still use it by supplying your own model key. The SDK itself is not a separate paid product.
One thing to verify against your own usage: agent runs consume Copilot capacity the same way the rest of the product does. If you are on a metered plan, autonomous tool loops can burn requests faster than interactive chat. We walked through that dynamic in the Copilot usage-based billing guide and the premium requests explainer, and it applies double to anything you script.
How This Compares#
This is not the first "agent runtime as an SDK." OpenAI shipped the Codex SDK and the Agents SDK on a similar premise, and Anthropic has leaned into the SDK-as-plumbing approach. The differentiator for the Copilot SDK is distribution and parity: it is the literal runtime behind a product millions of developers already use, it ships in six languages at GA, and it reuses GitHub's existing identity and billing instead of asking you to provision a new account. For shops already standardized on GitHub, that lowers the integration tax meaningfully.
The tradeoff is the CLI dependency. Because the agent is the Copilot CLI in server mode, your deployment story includes shipping and updating that binary, not just pinning a package version. For a serverless function that wants one quick completion, that is friction. For a long-running internal tool or CI assistant, it is fine.
Should You Use It#
Reach for the Copilot SDK if:
- You are already a GitHub and Copilot shop and want to embed agentic coding into internal tools, CI assistants, or a customer-facing feature without building orchestration from scratch.
- You need MCP, custom tools, and hook-based governance as first-class features rather than bolt-ons.
- You want one runtime behind your terminal, your cloud sessions, and your own app.
Be more cautious if:
- You need a stateless, low-dependency call into a model. The CLI-in-server-mode architecture is heavier than a single HTTP request.
- You are not on GitHub for identity and billing, in which case the BYOK path works but you lose part of the integration advantage that makes this SDK compelling.
The honest summary: GA is the moment this stops being a preview toy and becomes infrastructure you can build a product on. The custom tools, MCP, hooks, OpenTelemetry, and stable API are exactly the boxes a platform team checks before adopting. Just go in clear-eyed about the runtime model. You are not calling an endpoint, you are embedding an agent.
For where this fits in the broader landscape, see our best AI coding tools of 2026 roundup and the evolution of agent SDKs.
FAQ#
Is the Copilot SDK free to use?#
It is included with an existing GitHub Copilot subscription, including Copilot Free for personal use. Non-Copilot users can access it through bring-your-own-key (BYOK) with their own model provider credentials. See the usage-based billing guide and the premium requests explainer for how metered plans are affected by autonomous tool loops.
Does the Copilot SDK support MCP servers?#
Yes. GA added support for connecting to Model Context Protocol servers alongside custom tool registration, so existing MCP servers can be reused instead of rewritten per SDK. For a shortlist of servers worth installing, see 271 MCP Servers: The Top 5 That Matter.
How is the Copilot SDK different from the Codex SDK?#
Both expose an agent runtime as an embeddable SDK rather than a chat endpoint. The Copilot SDK's differentiator is that it is the literal runtime behind the Copilot CLI and app, ships in six languages at GA, and reuses GitHub identity and billing. See Codex SDK vs CLI vs GitHub Action for the OpenAI-side comparison.
Do I need the Copilot CLI installed to use the SDK?#
It depends on the language. The SDK always talks to the Copilot CLI running in server mode over JSON-RPC. Per the repository README, the Node.js, Python and .NET SDKs bundle the CLI, so the package install is enough; for Go, Java and Rust you install the CLI or put copilot on PATH. This is a heavier deployment model than a stateless HTTP call to a model endpoint.
Note on Claims#
Install commands, supported languages, the GA feature list, the JSON-RPC architecture, and pricing in this post are drawn from GitHub's GA changelog and the official repository. The code snippets are adapted from the official Node.js and Python SDK READMEs and were checked against version 1.0.22 of each package.
Continue Reading#
Get the next deep dive like this in your inbox
One email a week on GitHub Copilot and the rest of the AI dev stack. Free.
Read next on AI coding tools
GitHub Copilot Coding Agent and CLI: Why GitHub Is Back in the Agent Race
GitHub Copilot is moving from autocomplete into asynchronous coding agents, terminal workflows, MCP, skills, and model choice. Here is what changed in 2026.
8 min readCodex SDK vs CLI vs GitHub Action: Which Surface Should You Build On?
Codex SDK vs Codex CLI vs the Codex GitHub Action: when to use each surface, and how to avoid building the same agent loop three times.
8 min readOpenAI Agents SDK Evolution: What Ships in Production
Sandbox agents, file-based memory and Codex-style filesystem tools in the OpenAI Agents SDK: what the docs actually ship, with code adapted from OpenAI's own examples.
9 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.








