GitHub Copilot SDK GA: Build Production AI Agents

Direct answer: The GitHub Copilot SDK is now generally available and lets developers embed the agent runtime behind Copilot CLI into their own applications. It provides planning, tool invocation, file edits, streaming, multi-turn sessions, MCP integration, hooks, tracing, and model access across Node.js/TypeScript, Python, Go, .NET, Rust, and Java. It is most useful when you want a programmable coding or workflow agent without building the entire orchestration loop yourself. It is not a free, model-agnostic inference API: normal use requires a Copilot subscription, while BYOK is available for supported providers.

Key takeaways

• GitHub announced general availability on June 2, 2026, after a technical preview and public preview.
• The SDK exposes the same agentic engine used by Copilot CLI through language-specific clients.
• The supported SDKs are Node.js/TypeScript, Python, Go, .NET, Rust, and Java.
• Custom tools, MCP servers, hooks, streaming events, cloud sessions, and OpenTelemetry tracing make it more than a chat wrapper.
• Node.js, Python, and .NET bundle the Copilot CLI runtime; Go, Java, and Rust normally need a separately available CLI or runtime setup.
• Treat permissions as an application security boundary. The SDK can edit files and execute tools, so production deployments should use least privilege, isolated workspaces, explicit approvals, and audit logs.

GitHub Copilot SDK GA matters because it turns a familiar coding agent into an embeddable runtime. Instead of recreating context management, tool loops, session state, model routing, and MCP plumbing, a team can put a domain-specific interface around an existing agent engine.

That convenience comes with coupling. Your application depends on Copilot CLI behavior, Copilot authentication or supported BYOK providers, usage limits, model availability, and a permission model that must be designed deliberately. This guide focuses on what the release enables and where it should—and should not—be used.

What the GitHub Copilot SDK actually is

The SDK is a programmatic layer over the Copilot agent runtime. Your application starts or connects to the Copilot CLI server, creates a session, sends prompts, receives events, and supplies constraints or tools. The runtime can plan work, invoke tools, edit files, and continue across turns.

The important distinction is between an SDK and a model API. The SDK does not give you a raw completion endpoint with a simple token price. It gives you an agent execution loop: sessions, tools, permissions, streaming, and runtime behavior. That is valuable for coding assistants, repository automation, internal developer tools, and structured workflow agents. It is unnecessary overhead for a single prompt-response feature.

GitHub’s GA announcement lists the core capabilities as planning, tool invocation, file edits, streaming, and multi-turn sessions. It also adds custom tools and MCP, prompt customization, OpenTelemetry trace propagation, several authentication paths, cloud and remote sessions, and hooks around tool use and permissions.

What changed at general availability

The SDK began as a technical preview announced in January 2026. The preview supported Node.js, Python, Go, and .NET and exposed the agentic core behind Copilot CLI. GitHub’s GA release adds a stable API and production-ready support, with Rust and Java joining the supported language list.

The practical GA changes are:

GA does not mean every deployment is automatically production-safe. It means the SDK surface is mature enough for supported application development. You still need to validate model behavior, runtime versions, permission handlers, failure recovery, and billing in your own environment.

Installation and architecture by language

The official release lists these installation commands:

1npm install @github/copilot-sdk
2
3pip install github-copilot-sdk
4
5go get github.com/github/copilot-sdk/go
6
7dotnet add package GitHub.Copilot.SDK
8
9cargo add github-copilot-sdk

Java is distributed through Maven and Gradle. Follow the Java SDK instructions in the official repository rather than guessing coordinates in a build script.

For Python, the maintained SDK README requires Python 3.11 or newer:

1python -m venv .venv
2source .venv/bin/activate
3python -m pip install --upgrade pip
4python -m pip install github-copilot-sdk
5python -m copilot download-runtime

The runtime download step pre-provisions the CLI binary in the local cache. The SDK can download it lazily as a fallback, but explicit provisioning is easier to make reproducible in CI and container images. The Python documentation also describes an optional in-process transport; treat that as experimental and test it separately from the default stdio or TCP transport.

The architecture is intentionally consistent across languages:

1. Your application creates a client.
2. The client starts or connects to a Copilot CLI runtime.
3. The application creates a session with a model and permission policy.
4. The session emits assistant, tool, and lifecycle events.
5. Your code supplies custom tools, handles approvals, and stores results.
6. The client and session are closed explicitly or by an async context manager.

A minimal Python agent

The Python SDK is asynchronous and provides an async context-manager workflow. This example is intentionally read-only: it asks the agent to inspect a repository without granting unrestricted command execution.

1import asyncio
2from copilot import CopilotClient
3from copilot.session import PermissionHandler
4from copilot.session_events import AssistantMessageData, SessionIdleData
5
6async def main() -> None:
7    async with CopilotClient(working_directory="./workspace") as client:
8        async with await client.create_session(
9            model="gpt-5",
10            on_permission_request=PermissionHandler.approve_all,
11        ) as session:
12            finished = asyncio.Event()
13
14            def on_event(event) -> None:
15                match event.data:
16                    case AssistantMessageData() as data:
17                        print(data.content)
18                    case SessionIdleData():
19                        finished.set()
20
21            session.on(on_event)
22            await session.send(
23                "Inspect the repository and summarize its test commands. "
24                "Do not edit files, install packages, or run network commands."
25            )
26            await finished.wait()
27
28asyncio.run(main())

The approve_all handler is useful for a controlled local sample, but it is not a safe production default. The SDK’s own documentation warns that approval behavior depends on managed settings. For a real service, implement an allowlist-based permission handler that rejects writes, shell commands, network access, or sensitive paths unless the operation has been explicitly approved.

The TypeScript shape is similarly small:

1import { CopilotClient } from "@github/copilot-sdk";
2
3const client = new CopilotClient();
4await client.start();
5
6try {
7  const session = await client.createSession({ model: "gpt-5" });
8  await session.send({
9    prompt: "Summarize the repository's test strategy without changing files.",
10  });
11  // Subscribe to streaming events and close the session in your application.
12} finally {
13  await client.stop();
14}

Check the SDK README for the exact event and cleanup APIs for the version you install. The repository is the source of truth for language-specific method names; preview-era examples may use different casing or event helpers.

MCP and custom tools

MCP support is one of the strongest reasons to use the SDK. An embedded agent can connect to existing MCP servers instead of forcing each application team to write a bespoke adapter. Custom tools are useful when the operation belongs to your application: query a ticket system, retrieve a deployment status, validate a migration plan, or create a dry-run patch.

A safe tool design should answer four questions before the agent can invoke it:

• What data can the tool read?
• What side effects can it cause?
• Which identity and tenant does it use?
• How does a human review or reverse the result?

Do not expose a broad run_shell tool merely because the runtime can execute commands. Prefer narrow functions such as read_build_log, list_pending_migrations, or create_draft_pull_request. Return structured results, cap output size, redact secrets, and set timeouts.

For larger organizations, GitHub added enterprise MCP allowlists in August 2026. Enterprise owners can centrally allow or deny MCP servers using allowedMcpServers and deniedMcpServers in managed settings. Matching can use a remote server URL, a local server command, or a name; URL and command matching are security controls, while names are only convenience labels. Policies fail closed when configuration is malformed or unverifiable. This is a useful baseline, but application-level authorization is still required.

The MCP security threat-modeling guide covers the broader risks of tool servers, including confused-deputy behavior, credential exposure, and overly broad capabilities.

Authentication, BYOK, and billing

The SDK supports several authentication patterns:

• A signed-in GitHub user through Copilot CLI credentials.
• GitHub OAuth or GitHub App flows for application-managed access.
• Environment tokens such as COPILOT_GITHUB_TOKEN, GH_TOKEN, or GITHUB_TOKEN.
• BYOK for supported providers, including OpenAI, Microsoft Foundry, and Anthropic, subject to GitHub’s current compatibility rules.

The standard path requires a GitHub Copilot subscription. GitHub says the SDK is available to existing Copilot subscribers, including Copilot Free for personal use, while BYOK can be used without GitHub authentication. “Available” does not mean unlimited: SDK prompts count against the applicable Copilot usage allowance, and BYOK shifts provider charges to your provider account.

For cost planning, instrument at least:

• Prompts and completion tokens by workflow.
• Model selected and fallback model.
• Tool calls per session.
• Session duration and retries.
• Human approvals and rejected operations.
• Failed or abandoned sessions.

The SDK is not automatically cheaper than direct model APIs. It may reduce engineering cost by supplying an agent runtime, but the runtime can make more model calls and tool iterations than a single completion. Compare total task cost and successful-task rate, not only token price.

Security and privacy checklist

An agent that can read files, edit files, run commands, and call MCP servers is an application with privileged automation. Apply the same controls you would use for a deployment bot:

1. Use a dedicated workspace. Mount only the repository or data needed for the task. Keep credentials outside the agent’s working directory.
2. Default to read-only. Separate analysis sessions from change-making sessions. Require an approval transition before writes or external actions.
3. Limit tools. Register narrow custom tools and use MCP allowlists. Avoid unrestricted shell access.
4. Protect secrets. Redact tool output, prevent .env and credential directories from being read, and never place provider keys in prompts.
5. Set budgets and timeouts. Bound session length, tool calls, file size, subprocess runtime, and network requests.
6. Log decisions. Store the prompt, model, tool name, arguments after redaction, approval decision, result status, and trace ID.
7. Isolate execution. Use containers, a low-privilege OS account, filesystem restrictions, and an egress policy for untrusted tasks.
8. Review generated changes. Run tests, static analysis, dependency checks, and human review before merging.

GitHub’s managed settings can help establish a fleet-wide policy, but they do not replace tenant authorization, secrets management, or code review. For observability, the SDK’s W3C trace propagation and OpenTelemetry support can connect session activity to your existing traces. The OpenTelemetry GenAI observability guide is a useful companion for deciding which attributes to record and which sensitive values to exclude.

Performance and deployment trade-offs

The default SDK architecture adds a process boundary: your application communicates with the Copilot CLI runtime over JSON-RPC. That boundary is a feature for isolation and language neutrality, but it adds startup and serialization overhead. A long-running service should reuse clients and sessions where appropriate rather than launching a runtime for every short request.

Watch these latency sources:

• CLI runtime startup and runtime download on a cold host.
• Model time-to-first-token.
• Tool execution and network round trips.
• MCP server startup or remote-server latency.
• Permission-handler callbacks.
• Large repository indexing or file reads.

For a production service, preinstall or pre-provision the runtime in the image, warm a bounded pool of clients, stream progress to the caller, and cancel sessions when the request deadline expires. Do not share a session between unrelated tenants. If you need durable work, persist a task record and make every tool operation idempotent.

The SDK is a good fit for:

• Internal developer portals and repository assistants.
• CI diagnosis with read-only logs and test artifacts.
• Structured code-review or migration workflows.
• Desktop and web interfaces over a controlled coding agent.
• Applications that already use MCP and need a consistent agent loop.

It is a weaker fit for:

• Simple chat or extraction where a direct model API is enough.
• Hard real-time workloads with strict millisecond latency.
• Untrusted multi-tenant code execution without a strong sandbox.
• Products that require complete provider independence and a custom inference abstraction.

Common errors and debugging steps

The runtime cannot be found. Confirm the SDK version, Python version if applicable, and whether the runtime was downloaded. For Go, Java, and Rust, verify that the Copilot CLI is installed or that the selected application-level bundling path is configured.

Authentication works locally but fails in CI. Do not depend on a developer’s cached login. Use a dedicated GitHub App or environment-token flow, scope it narrowly, and check that the workflow can access the required Copilot entitlement. For BYOK, verify that the provider key is present in the process environment and that the selected model is supported.

The agent appears to hang. Subscribe to lifecycle and tool events, set a session idle timeout, and log the last event type and trace ID. A hung MCP server, blocked permission request, or subprocess waiting for input is often the real cause.

The agent edits more than expected. Remove broad write tools, narrow the working directory, replace approval-all handlers, and require a diff review. Add tests that attempt prohibited operations and assert that the permission handler denies them.

A preview code sample breaks. Use the installed SDK’s README and changelog. GitHub’s GA repositories contain language-specific READMEs, samples, tests, and API references; those are more reliable than old blog snippets.

How it compares with building your own agent loop

A sensible evaluation is to implement one representative workflow both ways. Measure time to a correct result, cost per successful run, approval burden, p95 latency, and incident recovery. The SDK wins when its built-in runtime saves more engineering effort than the coupling costs your product.

FAQ

Is the GitHub Copilot SDK free?

The SDK package and repository are available for developers, but normal usage requires a Copilot subscription and consumes the applicable usage allowance. BYOK can use supported provider keys instead, with charges handled by those providers.

Can I use the SDK with MCP servers?

Yes. GitHub documents MCP integration and custom tools as core capabilities. Enterprise-managed settings can also allow or deny MCP servers centrally.

Does the SDK support Python and Go?

Yes. Python, Go, Node.js/TypeScript, .NET, Rust, and Java are supported at GA. Python requires 3.11 or newer according to the official SDK README.

Does it run code automatically?

The runtime can invoke tools and execute commands depending on the configured permissions and managed settings. That is why production applications should use explicit allowlists, sandboxing, timeouts, and human review rather than approving every request.

Is this the same as calling a Copilot completion API?

No. The SDK exposes an agent runtime with sessions, planning, tools, file operations, and events. It is closer to embedding a coding agent than sending one completion request.

Conclusion

The GitHub Copilot SDK GA release gives developers a credible shortcut to production-style agent workflows. Its value is not simply that it can generate text or code; its value is the surrounding runtime: session management, tool execution, MCP, streaming, hooks, authentication, and tracing across six languages.

Start with a narrow, read-only workflow and measure it. Add custom tools only when their permissions and side effects are explicit. Use enterprise MCP policies, isolated workspaces, redacted telemetry, and review gates before allowing edits or external actions. If your product needs a provider-neutral inference layer or strict control over every orchestration decision, build closer to a direct model API. If you need a capable coding agent inside an application quickly, the Copilot SDK is now a serious option.

For context, compare this runtime approach with the AI coding agents, CLI tools, skills, and plugins guide, the Agent Plugins 1.0 and MCP guide, and the Nanobot open-source agent runtime. Those projects illustrate the broader trade-off between reusable agent infrastructure and full control over the stack.

Sources and verification

• GitHub Changelog: Copilot SDK is now generally available — official GA announcement, capabilities, languages, availability, and pricing notes.
• GitHub Copilot SDK repository — maintained source, installation commands, architecture, authentication, runtime behavior, and language links.
• GitHub Copilot SDK documentation — official setup, feature, authentication, hooks, MCP, scaling, and troubleshooting documentation.
• GitHub: Build an agent into any app with the Copilot SDK — independent earlier technical-preview context and the original SDK shape.
• Microsoft Developer Community: Building Agents with GitHub Copilot SDK — independent practical case study and Python/TypeScript integration context.
• GitHub Changelog: MCP allowlists in enterprise managed settings — official enterprise governance details.

Visual credit: Original Mermaid architecture diagram by Essam A. Mamdani; no external image used.

Related reading

• GitHub Copilot’s Agentic Workflow Update for August 2026
• Harness Engineering for AI Coding Agents: A Practical Guide
• OpenAI Agents SDK 0.20: MCP v2 Migration Guide