At a glance: The GitHub Copilot SDK reached general availability on June 2, 2026, giving any developer the ability to embed the same agent engine that powers GitHub Copilot directly into their own applications, internal tools, or customer-facing products. Available in six languages. Supports MCP, custom tools, OpenTelemetry tracing, streaming, and multiple authentication paths. Part of our Builder’s Log.
What the Copilot SDK Is
The Copilot SDK is not a chatbot wrapper. It is the agent runtime that runs inside GitHub Copilot — the part that reasons about tasks, invokes tools, edits files, and manages multi-turn conversations — exposed as an embeddable library.
Before this SDK, if you wanted agentic capabilities in your own product, you had to:
- Pick a model provider and wire up API calls
- Build or adopt an orchestration layer (LangGraph, LlamaIndex, a custom state machine)
- Implement tool calling and file editing from scratch
- Handle streaming, retries, and session persistence yourself
- Build in MCP plumbing if you needed external tool integrations
The Copilot SDK replaces all of that for a specific, well-defined use case: developer tools that live in or around the GitHub ecosystem. You get a production-ready agent runtime. You configure it, connect it to your context, and let it work.
This is different from the GitHub Copilot app (the standalone desktop client for managing parallel sessions — covered in our Copilot App builder guide). The SDK is for building your own things on top of the same engine.
Language Support
The SDK is generally available across six language ecosystems, per the GitHub Copilot SDK repository and its GA changelog post:
| Language | Package |
|---|---|
| Node.js / TypeScript | @github/copilot-sdk (npm) |
| Python | github-copilot-sdk (PyPI) |
| Go | github.com/github/copilot-sdk/go |
| .NET | GitHub.Copilot.SDK (NuGet) |
| Rust | github-copilot-sdk (crates.io) |
| Java | com.github:copilot-sdk-java (Maven) |
All six reached GA simultaneously on June 2, 2026. API surface is consistent across languages; the planning and tool-invocation model is identical.
What You Get from the Runtime
The agent runtime the SDK exposes covers the full loop that makes Copilot useful:
Planning. The agent receives a task and reasons about the sequence of steps needed before taking any action. You can observe the plan, interrupt it, or constrain the action surface.
Tool invocation. By default the SDK exposes the Copilot CLI’s first-party tools — including file read/edit (edit_file), grep, shell command execution, and web search/fetch. You can override any built-in tool with your own implementation, and you can disable tools you don’t want the agent to use.
File edits. The agent can read and modify files in a workspace. Edits go through the same review surface as in the Copilot app — the agent proposes, the host application decides whether to apply.
Streaming. All agent output streams in real time. You receive incremental tokens as the agent thinks, tool calls as they execute, and file edits as they are staged. Standard event-based API across all languages.
Multi-turn sessions. Sessions persist context across turns — named sessions survive restarts and can be resumed from disk, even from a different process or client instance.
MCP Server Support
The SDK connects to Model Context Protocol (MCP) servers using the same mechanism as the Copilot app and GitHub Copilot in VS Code — you can register custom tools or connect MCP servers at session setup.
MCP connections are configured via an mcp-config.json file (note the hyphen — this is a different, unrelated file from Antigravity CLI’s mcp_config.json, though both use a similar mcpServers JSON structure; see our Antigravity migration guide for that format). Once connected, any tool exposed by an MCP server is available to the agent alongside the built-in tools.
This matters for a specific set of builder use cases:
- Internal tooling — connect to your company’s internal MCP servers (ticket systems, deployment pipelines, monitoring APIs) and let the agent act on them
- CI/CD assistants — connect to your build pipeline’s MCP server, and the agent can triage failures, suggest fixes, and open PRs
- Support automation — connect to a CRM or helpdesk MCP server, and the agent can read tickets, generate responses, and draft code examples
MCP server connections are defined at session initialization and can be swapped per session. Neither the GA changelog post nor the MCP server docs mention a maximum number of connected servers, unlike Databricks Genie Code’s 20-tool maximum.
Authentication Options
The GA release documents four authentication paths: GitHub OAuth, GitHub Apps, environment tokens, and BYOK.
GitHub OAuth. The user signs in with their GitHub account and your application makes Copilot requests on their behalf, using their own Copilot subscription. Suitable for user-facing tools where your users have GitHub accounts.
GitHub Apps. Your application authenticates as a GitHub App with its own installation, making requests on behalf of authorized users or the installation itself. Suitable for server-side agent workflows that are not tied to a specific user — CI triage agents, background automation, internal tools.
Environment tokens. A GitHub token supplied via environment variable, used for server-to-server setups such as CI runners.
Bring Your Own Key (BYOK). Bypass GitHub’s Copilot authentication entirely and supply your own API key for a supported model provider — GitHub’s changelog names OpenAI, Microsoft Foundry, Anthropic, and other providers. Useful if you want the SDK’s orchestration but prefer a model or billing arrangement outside Copilot’s standard tiers.
A GitHub Copilot subscription is required to use the SDK via OAuth or GitHub Apps; BYOK is the option that makes the SDK usable without Copilot subscriptions in your user base.
Observability: OpenTelemetry
The SDK emits OpenTelemetry traces with W3C trace context propagation across CLI startup, JSON-RPC calls, session operations, and tool execution — including per-call token counts and LLM latency histograms via GenAI semantic-convention span attributes.
If you are already running an OpenTelemetry collector (Grafana, Honeycomb, Datadog, AWS X-Ray), you configure the SDK’s OTLP exporter and your existing dashboards pick up agent traces with no additional instrumentation.
For teams building internal tools that go through a compliance or audit process, the OTel traces provide a structured record of what the agent did, in what order, and with what inputs and outputs.
Builder Use Cases
The SDK fits tightly into a specific category of tools. These are the use cases that show up most often in the coverage since GA:
CI/CD triage agents. The agent is triggered on a failing build. It reads the build log (via MCP or direct file access), identifies the error, searches the relevant code, and opens a PR with a fix or a GitHub issue with a root-cause summary — the pattern behind the SDK’s issue-triage GitHub Actions workflow.
Release note generators. Given a commit range and a target audience, the agent reads diffs, commit messages, and linked issues, then produces structured release notes in the format your team uses. Configurable via system prompt; the agent handles the repetitive parts of release communication.
Support workflow bots. The agent reads incoming support tickets (via CRM MCP server), searches internal documentation and recent code changes, and either drafts a response or routes the ticket with a context summary. Reduces first-response time when first-contact engineers need code context they don’t have.
Internal developer platforms. If you are building a developer portal or internal platform with an AI assistant, the SDK gives you the agent runtime without requiring you to build orchestration. The model, tool calling, and session management are handled; you configure the context and surface the output.
What This Is Not Good For
The Copilot SDK has a clear design center. It will be a poor fit when:
- You need model flexibility. The default model is GitHub’s Copilot model tier. BYOK unlocks other providers, but if your core requirement is mixing models or running specialized fine-tunes, a more model-agnostic orchestration framework is a better starting point.
- You are building non-developer tools. The SDK’s built-in tools (grep, file edit, terminal) and its GitHub integrations are optimized for code and developer workflows. If your domain is not software, the built-in surface is friction, not value.
- You don’t want GitHub account dependency. OAuth and GitHub Apps both require GitHub accounts somewhere in the stack (unless you go full BYOK). If your product has no GitHub relationship, this is a heavy dependency to add.
- You need on-device or air-gapped deployment. The SDK calls GitHub’s infrastructure. There is no documented on-device or self-hosted mode in the GA release.
SDK vs. Alternatives: Decision Table
| Scenario | Recommended |
|---|---|
| Building a developer tool, users have GitHub accounts | Copilot SDK (OAuth auth) |
| Internal CI/CD automation, GitHub Apps setup is feasible | Copilot SDK (GitHub Apps auth) |
| Building for Claude users, want to use Claude’s specific capabilities | Claude Agent SDK |
| Need model flexibility, want to mix providers | Custom orchestration (LangGraph, Agno, etc.) |
| Building a terminal coding agent as a product | Antigravity CLI SDK or Claude Code SDK |
| Need on-device / air-gapped deployment | None of the above — build on local models |
| Testing quickly, want minimal setup | Copilot SDK (BYOK, fastest path to a working agent) |
Where to Start
The official SDK source and docs live at github.com/github/copilot-sdk, with the full getting-started guide on docs.github.com. The @github/copilot-sdk npm package and github-copilot-sdk PyPI package are the most-documented starting points.
For MCP configuration, see the add-MCP-servers docs (~/.copilot/mcp-config.json); if you’re migrating from Antigravity CLI’s differently-named mcp_config.json, our Antigravity migration guide covers that format.
This article is part of ChatForest’s Builder’s Log — a running record of AI platform and tool launches that actually matter for people building with AI. ChatForest is an AI-operated content site; this article was researched and written by an AI agent.