Building agentic workflows from scratch is hard.  You have to manage context across turns, orchestrate tools and commands, route between models, integrate MCP servers, and think through permissions, safety boundaries, and failure modes. Even before you reach your actual product logic, you’ve already built a small platform.  GitHub Copilot SDK (now in technical preview) removes that burden. It allows you to take the same Copilot agentic core that powers GitHub Copilot CLI and embed it in any application.   This gives you programmatic access to the same production-tested execution loop that powers GitHub Copilot CLI. That means instead of wiring your own planner, tool loop, and runtime, you can embed that agentic loop directly into your application and build on top of it for any use case.  You also get Copilot CLI’s support for multiple AI models, custom tool definitions, MCP server integration, GitHub authentication, and real-time streaming. How to get started We’re starting with support for Node.js, Python, Go, and .NET. You can use your existing GitHub Copilot subscription or bring your own key.   The github/copilot-sdk repository includes:   Setup instructions  Starter examples  SDK references for each supported language  A good first step is to define a single task like updating files, running a command, or generating a structured output and letting Copilot plan and execute steps while your application supplies domain-specific tools and constraints.  Here’s a short code snippet to preview how you can call the SDK in TypeScript:  import { CopilotClient } from “@github/copilot-sdk”; const client = new CopilotClient(); await client.start(); const session = await client.createSession({ model: “gpt-5”, }); await session.send({ prompt: “Hello, world!” }); Visit github/copilot-sdk to start building.   What’s new in GitHub Copilot CLI   Copilot CLI lets you plan projects or features, modify files, run commands, use custom agents, delegate tasks to the cloud, and more, all without leaving your terminal.  Since we first introduced it, we’ve been expanding Copilot’s agentic workflows so it:  Works the way you do with persistent memory, infinite sessions, and intelligent compaction.  Helps you think with explore, plan, and review workflows where you can choose which model you want at each step.  Executes on your behalf with custom agents, agent skills, full MCP support, and async task delegation.  How does the SDK build on top of Copilot CLI?  The SDK takes the agentic power of Copilot CLI (the planning, tool use, and multi-turn execution loop) and makes it available in your favorite programming language. This makes it possible to integrate Copilot into any environment. You can build GUIs that use AI workflows, create personal tools that level up your productivity, or run custom internal agents in your enterprise workflows.   Our teams have already used it to build things like:  YouTube chapter generators  Custom GUIs for their agents  Speech-to-command workflows to run apps on their desktops  Games where you can compete with AI  Summarizing tools  And more!  Think of the Copilot SDK as an execution platform that lets you reuse the same agentic loop behind the Copilot CLI, while GitHub handles authentication, model management, MCP servers, custom agents, and chat sessions plus streaming. That means you are in control of what gets built on top of those building blocks. Start building today! Visit the SDK repository to get started. The post Build an agent into any app with the GitHub Copilot SDK appeared first on The GitHub Blog. ​ AI & ML, Company news, GitHub Copilot, News & insights, GitHub Copilot CLI, GitHub Copilot SDK, SDK The GitHub Blog

Do you ever feel like you’re spending more time moving between different tools than you are writing code? If you thrive in the terminal and want faster, more predictable ways to run tests, fix code, and manage context, Copilot CLI slash commands give you that control without breaking your flow. You can use slash commands to perform a variety of tasks like configuring which AI model to use or setting up an MCP server, or even sharing your session externally. Slash commands offer fast, repeatable actions without needing to craft a new prompt each time. TL;DR: See all the slash commands and what they do at the bottom of this post. 😉 What are slash commands? A slash command is a simple instruction, like /clear or /session, that tells Copilot exactly what you want to do. They are prefixed with a / and instantly trigger Copilot to carry out context-aware actions. To start using slash commands , open Copilot CLI and type / to see a list of available commands. How to use slash commands Type / in the Copilot CLI to see a list of available slash commands and their descriptions. You can also use /help to get more details about what each command does and how to use it. For instructions and examples, keep scrolling! Start here (two minutes) Open Copilot CLI Type /help to see available commands Run /clear to reset context Run /cwd to confirm Copilot is scoped to the right directory.  You can jump to the sections below based on what you’re trying to do.  Learn more in our docs > In addition to Copilot CLI, you can use slash commands across Copilot Chat and with agent mode, too. Why use slash commands? As developers, we want tools that work fast in the terminal. Slash commands in Copilot CLI do just that. Instead of writing a new prompt for each task, you use quick, explicit, and repeatable commands directly in your workflow. In practice, they help with: Speed and predictability: With slash commands, Copilot’s actions are more transparent and predictable. Unlike natural language prompts, which can be interpreted in different ways, slash commands always trigger the same response. This removes guesswork because you always know what you’re going to get, instantly.  Productivity: Before slash commands, you might have copied and pasted code, written long prompts, or switched back and forth between tools. Now you can clean up errors, run tests, and get code explanations right from the CLI, without leaving your terminal. Clarity and security: Commands like /add-dir and /list-dirs give clear boundaries for file access and create an auditable trail, which is essential for teams working in sensitive environments. This eliminates uncertainty about what’s happening behind the scenes, reduces the risk of accidental data exposure, and helps teams maintain control in sensitive environments.  Better accessibility: Slash commands fit seamlessly into keyboard-driven and accessible workflows. Commands like /help provide an instant overview of available actions, while /list-dirs or /list-files let users browse without navigating complex interfaces. These commands enable users who rely on keyboard shortcuts or assistive technologies to quickly discover and use Copilot features. Trust and compliance: Slash commands enhance trust by making every Copilot action explicit and traceable. For example, teams can use /add-dir to grant Copilot access to a specific directory. This ensures that sensitive files stay protected. With slash commands like /session or /usage, teams can manage tool access, monitor activity, and stay compliant. Custom workflows and extensibility: As support for slash commands expands, you can tailor Copilot to work with your own tasks and automations. Delegate pull requests, switch agents, or connect to CI/CD pipelines, all from the CLI, with commands like /delegate, /agent, and /mcp. Think of slash commands as explicit shortcuts for things you already do. There’s a lot you can do with Copilot CLI, and slash commands make the process easier. Useful Copilot CLI slash commands for your everyday workflow Below are the most commonly used slash commands, grouped by what you typically need to control in your workflows: context, scope, configuration, and collaboration. 💡 Tip: If you only remember three commands, start with /clear, /cwd, and /model. These give you immediate control over context, scope, and output quality.  Session management commands /clear: Delete the current session’s conversation history. Copilot accumulates context as you work. This inherited context can muddy suggestions when you have too much of it, or when you’re trying to switch tasks. /clear lets you quickly wipe the slate when you’re multitasking or working between projects. When to use: Switching to a new task or repository Copilot responses are referencing old files or earlier conversations You want to avoid context bleed between projects /exit, /quit: Exit the CLI. The commands /exit and /quit provide a direct way to end your session and disconnect from Copilot, ensuring resource cleanup and a clear boundary for session-based work. When to use: Wrapping up your session Logging out of a shared terminal /session, /usage: Display session usage metrics about the current CLI session. These commands give visibility into the actions Copilot has performed during your session, helping with audits, troubleshooting, and resource tracking. When to use: Auditing team/individual Copilot CLI usage Reviewing model or tool usage during a session Debugging runs or model use When you run either the /session or /usage commands, Copilot shows output similar to the following, displaying usage metrics about your session: Session ID: 221b5571-3998-47e1-b57a-552cf9078947 Started: 11/24/2025, 11:18:54 AM Last Modified: 11/24/2025, 11:18:54 AM Duration: 50s Working Directory: /Users/jacklynlee31 Usage: Total usage est: 0 Premium requests Total duration (API): 0s Total duration (wall): 50s Total code changes: 0 lines added, 0 lines removed Hit Enter or Esc to continue Directory and file access commands /add-dir: Allow Copilot to access a directory. By limiting Copilot’s access to the files you choose, you can ensure responses are relevant to your current scope and increase security. When to use: Scoping Copilot to a specific repository or subdirectory Navigating large codebases with sensitive files /add-dir <directory> For

Anders Hejlsberg’s work has shaped how millions of developers code. Whether or not you recognize his name, you likely have touched his work: He’s the creator of Turbo Pascal and Delphi, the lead architect of C#, and the designer of TypeScript.  We sat down with Hejlsberg to discuss his illustrious career and what it’s felt like to watch his innovations stand up to real world pressure. In a long-form conversation, Hejlsberg reflects on what language design looks like once the initial excitement fades, when performance limits appear, when open source becomes unavoidable, and how AI can impact a tool’s original function. What emerges is a set of patterns for building systems that survive contact with scale. Here’s what we learned. Watch the full interview above. Fast feedback matters more than almost anything else Hejlberg’s early instincts were shaped by extreme constraints. In the era of 64KB machines, there was no room for abstraction that did not pull its weight. “You could keep it all in your head,” he recalls. When you typed your code, you wanted to run it immediately. Anders Hejlsberg Turbo Pascal’s impact did not come from the Pascal language itself. It came from shortening the feedback loop. Edit, compile, run, fail, repeat, without touching disk or waiting for tooling to catch up. That tight loop respected developers’ time and attention. The same idea shows up decades later in TypeScript, although in a different form. The language itself is only part of the story. Much of TypeScript’s value comes from its tooling: incremental checking, fast partial results, and language services that respond quickly even on large codebases. The lesson here is not abstract. Developers can apply this directly to how they evaluate and choose tools. Fast feedback changes behavior. When errors surface quickly, developers experiment more, refactor more confidently, and catch problems closer to the moment they are introduced. When feedback is slow or delayed, teams compensate with conventions, workarounds, and process overhead.  Whether you’re choosing a language, framework, or internal tooling, responsiveness matters. Tools that shorten the distance between writing code and understanding its consequences tend to earn trust. Tools that introduce latency, even if they’re powerful, often get sidelined.  Scaling software means letting go of personal preferences  As Hejlsberg moved from largely working alone to leading teams, particularly during the Delphi years, the hardest adjustment wasn’t technical. It was learning to let go of personal preferences. You have to accept that things get done differently than you would have preferred. Fixing it would not really change the behavior anyway. Anders Hejlsberg That mindset applies well beyond language design. Any system that needs to scale across teams requires a shift from personal taste to shared outcomes. The goal stops being code that looks the way you would write it, and starts being code that many people can understand, maintain, and evolve together. C# did not emerge from a clean-slate ideal. It emerged from conflicting demands. Visual Basic developers wanted approachability, C++ developers wanted power, and Windows demanded pragmatism. The result was not theoretical purity. It was a language that enough people could use effectively. Languages do not succeed because they are perfectly designed. They succeed because they accommodate the way teams actually work. Why TypeScript extended JavaScript instead of replacing it TypeScript exists because JavaScript succeeded at a scale few languages ever reach. As browsers became the real cross-platform runtime, teams started building applications far larger than dynamic typing comfortably supports. Early attempts to cope were often extreme. Some teams compiled other languages into JavaScript just to get access to static analysis and refactoring tools. That approach never sat well with Hejlsberg. Telling developers to abandon the ecosystem they were already in was not realistic. Creating a brand-new language in 2012 would have required not just a compiler, but years of investment in editors, debuggers, refactoring tools, and community adoption. Instead, TypeScript took a different path. It extended JavaScript in place, inheriting its flaws while making large-scale development more tractable. This decision was not ideological, but practical. TypeScript succeeded because it worked with the constraints developers already had, rather than asking them to abandon existing tools, libraries, and mental models.  The broader lesson is about compromise. Improvements that respect existing workflows tend to spread while improvements that require a wholesale replacement rarely do. In practice, meaningful progress often comes from making the systems you already depend on more capable instead of trying to start over. Visibility is a part of what makes open source work TypeScript did not take off immediately. Early releases were nominally open source, but development still happened largely behind closed doors. That changed in 2014 when the project moved to GitHub and adopted a fully public development process. Features were proposed through pull requests, tradeoffs were discussed in the open, and issues were prioritized based on community feedback. This shift made decision-making visible. Developers could see not just what shipped, but why certain choices were made and others were not. For the team, it also changed how work was prioritized. Instead of guessing what mattered most, they could look directly at the issues developers cared about. The most effective open source projects do more than share code. They make decision-making visible so contributors and users can understand how priorities are set, and why tradeoffs are made. Leaving JavaScript as an implementation language was a necessary break For many years, TypeScript was self-hosted. The compiler was written in TypeScript and ran as JavaScript. This enabled powerful browser-based tooling and made experimentation easy. Over time, however, the limitations became clear. JavaScript is single-threaded, has no shared-memory concurrency, and its object model is flexible (but expensive). As TypeScript projects grew, the compiler was leaving a large amount of available compute unused. The team reached a point where further optimization would not be enough. They needed a different execution model. The controversial decision was to port the compiler to Go. This was not a rewrite. The goal was semantic fidelity. The new compiler needed to behave