In the previous post talked about why the GitHub Copilot SDK matters: it gives you a production-grade agent harness out of the box, so you can skip building the infrastructure and focus on your actual product. Now let's make it concrete. This post walks through everything you need to get up and running with the SDK in .NET — from prerequisites to a working streaming agent with a custom tool.
What we will build
We’ll keep it simple. By the end of this post you'll have a console application that:
- Connects to Copilot's agent runtime
- Sends a prompt and receives a streaming response
- Has a multi-turn conversation with persistent context
- Calls a custom tool you define in C#
Prerequisites
You'll need three things before touching any code.
1. .NET 8 or later
The SDK requires .NET 8+. Verify your version:
dotnet --version2. GitHub Copilot CLI, installed and authenticated
The SDK communicates with the Copilot CLI running as a local process — it doesn't call the API directly. This design keeps your credentials out of application code, which is a meaningful security advantage.
Install the CLI via the official installation guide, then authenticate using the /login slash command.
Verify it's working:
copilot --version3. A GitHub Copilot subscription
Any Copilot plan works — including the free tier. If you'd rather use your own model API keys (OpenAI, Azure AI Foundry, or Anthropic), BYOK is supported and we'll touch on that at the end.
Note: Every prompt counts against your Copilot subscription's premium request quota. For early experiments this is fine, but if you're building automated workflows that fire many requests, keep an eye on usage.
Step 1: Create the project
Create a new console app and add the SDK NuGet package:
mkdir copilot-demo && cd copilot-demo
dotnet new console
dotnet add package GitHub.Copilot.SDKThe CLI is bundled automatically with the .NET SDK package — no separate installation step required.
For anything beyond a quick script, also add:
dotnet add package Microsoft.Extensions.AIThis gives you AIFunctionFactory, which makes registering custom tools clean and ergonomic.
Step 2: Your first message
Open Program.cs and replace its contents with this:
Run it:
dotnet runThat's all it takes. CopilotClient manages the connection to the Copilot CLI process. CreateSessionAsync starts a conversation with a specific model. SendAndWaitAsync sends your prompt and blocks until the full response is ready.
Step 3: Add streaming
Waiting for the full response works fine for short answers, but for longer outputs you'll want to stream — displaying content as it arrives makes your app feel much more responsive.
The SDK emits assistant.message_delta events as tokens arrive, and session.idle when the turn is complete. You subscribe to events rather than polling — a clean, event-driven model that fits naturally with .NET.
Step 4: Multi-turn conversation
One of the things the SDK handles for you automatically is conversational context. Each CopilotSession maintains state across turns — you don't have to manually track message history or stuff it back into each request.
The agent remembers the full conversation history within the session. Ask a follow-up question and it knows what you were talking about — no extra wiring required.
Step 5: Add a custom tool
The agent runtime can call code you define whenever it determines a tool is needed to answer a request. You register tools using AIFunctionFactory.Create() from Microsoft.Extensions.AI.
Here's an example that gives the agent the ability to look up the current weather:
When you send that prompt, the agent decides on its own that it needs to call get_current_weather — once for Brussels, once for Berlin — and incorporates the results into its response. You didn't write any routing logic. The execution loop handles it.
Step 6: Handling permissions
The SDK expects that you always specify a permission request handler. A built-in one is PermissionHandler.ApproveAll, which is convenient for development but not something you want in production. For anything beyond local experiments, you'll want to inspect tool requests before they execute.
The permission framework lets you intercept each tool call by type — shell, write, read, url, custom-tool — and return approved or denied:
Using BYOK instead of a Copilot subscription
With the recent announcement about the upcoming price changes, you maybe prefer to use your own API keys from OpenAI, Azure AI Foundry, or Anthropic. Therefore you can configure the SDK to use those instead:
BYOK means no GitHub Copilot subscription is required. It's a useful option if you're already paying for model access elsewhere and want to avoid double-billing.
Putting it together
Here's a quick mental model of the three core concepts you've been working with:
CopilotClient— manages the connection to the Copilot CLI process running locally. Create one per application (register it as a singleton in DI).CopilotSession— holds a persistent conversational context. Create one per conversation or user session.SessionConfig— where you configure the model, tools, streaming, permissions, and custom instructions.
For production applications, the recommended pattern is to register CopilotClient as a singleton in your DI container and create sessions on demand:
Then inject it wherever you need it, and call CreateSessionAsync per request or conversation.
What's next
You now have a working .NET app that connects to the Copilot agent runtime, handles multi-turn conversations, streams responses, and can call your own code as a tool. That's the foundation.
In the next post, we'll go deeper on tool use and customization — how to build tools that do real things (query a database, call an API, read files), how to control which first-party tools are available, and how to think about tool design for agentic workflows.