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

Official Sources

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.

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:

1. 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.
2. The Rust SDK bundles the CLI binary by default. Other languages expect the CLI to be present. This is a real deployment detail: your container or CI runner needs the Copilot CLI available, not just a package from a registry.

If your mental model was "call a chat endpoint," recalibrate. You are running a local agent process and driving it programmatically.

A Minimal Session

The shape of a basic call looks like a chat completion, which makes the on-ramp gentle. The following is illustrative of the documented client pattern rather than a verbatim quote from the reference docs, so check the getting started guide before you copy it into production:

import { CopilotClient } from "@github/copilot-sdk";

const client = new CopilotClient();

const response = await client.chat({
  messages: [
    { role: "user", content: "Add Stripe checkout to my Next.js app" },
  ],
});

console.log(response.content);

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 registration looks roughly like this (again, illustrative of the pattern, confirm against the docs):

from github_copilot_sdk import CopilotClient, Tool

def query_analytics(query: str) -> dict:
    """Query the analytics database."""
    return {"users": 1523, "conversions": 234}

analytics_tool = Tool(
    name="query_analytics",
    description="Query analytics database for metrics",
    parameters={
        "type": "object",
        "properties": {
            "query": {"type": "string", "description": "SQL query"},
        },
        "required": ["query"],
    },
    function=query_analytics,
)

client = CopilotClient(tools=[analytics_tool])

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.

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 illustrative of the documented client and tool patterns and should be checked against the current SDK reference before production use.