The art of simplicity

In the previous post, we walked through local sandboxing in the Copilot CLI: enable it with /sandbox enable , tune filesystem and network rules through the TUI, and your agent's shell execution is isolated by Microsoft MXC. Simple, useful, done. But if you're building with the Copilot SDK, embedding the agent runtime into your own .NET application, you can't type /sandbox enable into a session you're programmatically orchestrating. So the question becomes: how do you get the same isolation guarantees when you own the host? The good news: sandbox support is coming to the SDK as a preview feature. The entry point is Session.Rpc.Options.UpdateAsync , and it lets you push a sandbox configuration into a running session from code. Preview caveat : this API is behind the experimental surface of the SDK. It's real, it works, but the shape may change before it stabilises. Treat it as preview-quality and don't build production contracts on top of it just yet. Wha...

There's a moment in every agentic workflow where you pause and think: wait, what exactly is Copilot allowed to touch right now? For a long time the answer was: pretty much everything under your working directory and whatever shell commands it decides to run to get the job done. That was fine when Copilot was mostly suggesting code. It's a different story when it's running tools, executing scripts, and modifying files on your behalf. As of June 2026, GitHub has an answer: local sandboxing , now in public preview. It doesn't replace good judgment about what you ask Copilot to do, but it does put a real isolation boundary between the agent's tool execution and the rest of your machine. Let’s explore this feature… Why do we need this? The Copilot CLI has evolved significantly since GA. What started as a smart terminal assistant now has Autopilot mode, /plan , fleet parallelism, rubber duck, and a full agentic harness underneath. When you run Copilot in Autopil...

By default, the CopilotClient starts in CopilotCli mode. That means the full Copilot CLI persona is active — which includes a lot: All built-in tools available (subject to the ToolSet filtering you do per session) Host integration enabled: the CLI picks up your local ~/.copilot/ config, agents directory, plugins, and AGENTS.md files if they exist The default system prompt with the full Copilot identity Co-author trailers added to git commits Storage backed by the local filesystem at the default path For a developer using the SDK on their own machine to automate their own workflows, this is perfect. The agent behaves exactly like Copilot CLI would interactively. Context flows in from their environment, their local agent configs are respected, their Copilot persona is preserved. The multi-tenant problem The moment you start running the SDK as a service — where one process handles sessions for multiple users or tenants — default mode becomes a liability. ...

This post is part of a follow-up series to my GitHub Copilot SDK blog series . After wrapping up the main series I was left with a list of features that deserved more than a passing mention. First up: SystemMessageConfig , and specifically the mode that most tutorials gloss right over. The temptation of Replace When you first discover that the Copilot SDK lets you control the system prompt, the obvious instinct is to reach for SystemMessageMode.Replace . Full control, clean slate, no surprises — what's not to like? var session = await client.CreateSessionAsync(new SessionConfig { Model = "gpt-5", SystemMessage = new SystemMessageConfig { Mode = SystemMessageMode.Replace, Content = "You are a helpful assistant." } }); However there is a big problem with adding this line. When you replace the system prompt wholesale you are not just customizing Copilot, you are evicting it. The carefully tuned defaults around tool use, safet...

With the change to token based billing, I pay a lot more attention on what my AI agents are doing. Although some info is available, I was missing the tools to evaluate my token consumption and have an in-depth understanding of what's going on. Until I discovered AgentsView. AgentsView is a local-first desktop and web app that reads those files and gives you a proper UI to work with them: browse sessions, search across all message content, see tool calls and thinking blocks, and get a quick health grade for each session. Let's install it and see what it actually looks like. Installation There are a few ways in, pick whatever fits your workflow. As a Windows user I decided to grab the latest .exe or .AppImage from the GitHub Releases page . The desktop app is fully bundled and auto-updates. Executing the downloaded executable will walk you through an installation wizard. Remark: There is also a CLI which uses the same data directory. Running it If you went the...

You built an MCP server in C#. It works great on your machine. Now you want to share it with colleagues, publish it to the community, or ship it as part of a product. The problem? Every time someone wants to use a local MCP server, they have to clone a repo, install runtimes, hand-edit a JSON config file, get the path wrong, edit it again... you know the drill. MCP Bundles ( .mcpb ) solve exactly that. They're the .vsix of the MCP ecosystem: a single file that a supporting app (like Claude for Desktop) opens with one click to present a guided install dialog. No terminal, no JSON editing, no "works on my machine." This post walks through taking a C# MCP server binary and packaging it into a distributable .mcpb file from scratch. What's inside a .mcpb file? Before touching anything, it helps to understand what you're building. A .mcpb file is just a ZIP archive with a specific structure: my-server.mcpb (ZIP file) ├── manifest.json ← required: ...

In previous posts, I covered how to customize the GitHub Copilot CLI statusline. First with the default options , then with a dynamic script . Today we're taking it a step further: integrating Oh My Posh to bring full prompt theming support to your Copilot CLI session. Oh My Posh has native support for GitHub Copilot CLI, so you get all its theming power (Nerd Font icons, color gradients, diamond-style segments,…) rendering right inside the Copilot CLI statusline. What Is Oh My Posh? Oh My Posh is a cross-shell prompt engine that lets you define richly styled prompts using a JSON (or YAML/TOML) configuration file. You probably know it from PowerShell or bash, but it also ships a dedicated copilot subcommand specifically for integration with GitHub Copilot CLI's statusLine feature. Prerequisites Oh My Posh installed ( winget install JanDeDobbeleer.OhMyPosh   see docs ) A Nerd Font installed and set as your terminal font (for icons to render correctly) Gi...

Between all this AI craziness, we often forget to appreciate the small tools and features that make our lives easier. Such  a feature is Central Management Servers (CMS) , a built-in SQL Server feature that lets you manage a whole fleet of instances from one place. Let's walk through what it is, how to set it up, and when it'll actually make your life easier. So, what is a Central Management server? At its core, CMS is a SQL Server instance that acts as your hub for organizing and talking to other SQL Server instances. You register your other servers under it, group them however makes sense (by environment, team, region — you name it), and then query all of them at once. The metadata about your registered servers gets stored in the msdb database on the CMS host. Nothing fancy — it's just a central directory that SSMS knows how to use. Setting it up in SSMS Here's how to get going in SQL Server Management Studio: Step 1: Open the Registered Servers panel ...

For the last 2 days I have been struggling with a breaking change I had in my ASP.NET Core web api that caused the consuming application to fail. I had a header parameter that was optional but became required after changing the nullability of my project to enabled . Although I found the issue and was able to fix it quite fast, I was not happy with my current process and was wondering how I could prevent this from happening again. This brought me to a final solution where I introduced some extra tests that compared the OpenAPI metadata between different implementations. Let me show you how I did it… Generate OpenAPI documents at build time To compare 2 OpenAPI metadata documents we first need to get them. For the already released version of the API, I can download the document through the OpenAPI endpoint ( /openapi/v1.json by default). But what about the new version of the API that is still in development? I solve this by generating the OpenAPI document at build time. This m...

Today I lost a lot of time investigating a stupid(aren’t they all?) issue with some failing tests on the build server. The strange thing was that when I ran the same tests locally, they always succeeded...what was going wrong? Just for completeness, here is the test task configuration I was using: Nothing special I would think. It was only when diving deeper into the build output that I discovered what was going wrong. Here is the output that explains the problem: 2025-05-20T13:19:22.3855459Z vstest.console.exe 2025-05-20T13:19:22.3855564Z "D:\b\3\_work\210\s\IAM.Core.Tests\bin\Release\ net6.0\IAM.Core.Tests.dll " 2025-05-20T13:19:22.3855657Z "D:\b\3\_work\210\s\IAM.Core.Tests\bin\Release\ net8.0\IAM.Core.Tests.dll " 2025-05-20T13:19:22.3855761Z "D:\b\3\_work\210\s\Mestbank.Core.Tests\bin\Release\net6.0\Mestbank.Core.Tests.dll" 2025-05-20T13:19:22.3855857Z "D:\b\3\_work\210\s\Mestbank.Core.Tests\bin\Release\net8.0\Mestbank.Core.Tests....

As the list of available tools keeps growing, sooner or later something will not work and some debugging becomes necessary. In this post I look into ways to troubleshoot your MCP integration. Let's dive in! To understand what we need to debug you need to be aware of the architecture of an MCP integration. It follows a client-server architecture , where AI models can request data through a host with an MCP client (e.g. GitHub Copilot, Claude Desktop, …) from MCP servers, which then retrieve relevant information from local or remote sources. This means that when a problem occurs that there (at least) 2 places to look at. Debugging the MCP client Let’s start by looking into the client. The way you need to debug the client is completely dependent on the host. I’ll focus on GitHub Copilot and Claude Desktop. GitHub Copilot When VSCode encounters an error while trying to interact with an MCP server, you get a red error indicator in the Chat window: Click on the icon and...