Updates, ideas, and inspiration from GitHub to help developers build and design software.
Pick your agent: Use Claude and Codex on Agent HQ
Claude by Anthropic and OpenAI Codex are now available in public preview on GitHub and VS Code with a Copilot Pro+ or Copilot Enterprise subscription. Here's what you need to know and how to get started today. The post Pick your agent: Use Claude and Codex on Agent HQ appeared first on The GitHub Blog.
Context switching equals friction in software development. Today, we’re removing some of that friction with the latest updates to Agent HQ which lets you run coding agents from multiple providers directly inside GitHub and your editor, keeping context, history, and review attached to your work. Copilot Pro+ and Copilot Enterprise users can now run multiple coding agents directly inside GitHub, GitHub Mobile, and Visual Studio Code (with Copilot CLI support coming soon). That means you can use agents like GitHub Copilot, Claude by Anthropic, and OpenAI Codex (both in public preview) today. With Codex, Claude, and Copilot in Agent HQ, you can move from idea to implementation using different agents for different steps without switching tools or losing context. We’re bringing Claude into GitHub to meet developers where they are. With Agent HQ, Claude can commit code and comment on pull requests, enabling teams to iterate and ship faster and with more confidence. Our goal is to give developers the reasoning power they need, right where they need it. Katelyn Lesse, Head of Platform, Anthropic How to get started When you have a task, you can choose Copilot, Claude, Codex, or a custom agent. You can make them work asynchronously and then review the results on your own time. Each coding agent session consumes one premium request. You can currently start Claude and Codex sessions from github.com, GitHub Mobile, and in VS Code. Claude and Codex must be explicitly enabled in your settings before use. See details on how. Create and view agent sessions on GitHub You can start and manage agent sessions directly from GitHub: Open the Agents tab in any repository where agents are enabled. Enter your request and select an agent using the Copilot icon. Submit the request to start the session. Agents run asynchronously by default. You can follow their progress in real time or review completed sessions later, with detailed logs showing what the agent did and why. Each session produces artifacts like comments, drafts, and proposed changes that can be reviewed like any other contribution. Assign agents to issues and pull requests You can also use agents directly in your existing collaboration workflows: Assign an issue to Copilot, Claude, Codex, or all three to compare results. Agents can submit draft pull requests for review. Assign agents to existing pull requests to request changes or further analysis. Mention @Copilot, @Claude, or @Codex in pull request comments to prompt follow-up work. Agent activity is logged and reviewable, so their output fits naturally into the same workflows you already use to evaluate developer contributions. Agents can still make mistakes. That’s exactly why their output is designed to be reviewed, compared, and challenged, not blindly accepted. Start agent sessions in Visual Studio Code You can also work with agents directly from VS Code (version 1.109 or later): Open the Agent sessions view from the title bar or by pressing Ctrl+Shift+P /CMD+Shift+P and searching for “agent sessions” Choose a session type and your agent: Local (Copilot), Claude, or Codex for fast, interactive assistance Cloud for autonomous tasks that run on GitHub, then select an agent Background for asynchronous local work (Copilot only) This lets you explore ideas in the editor and then delegate longer-running work to GitHub without losing context or history. From faster code to better decisions Agent HQ also lets you compare how different agents approach the same problem, too. You can assign multiple agents to a task, and see how Copilot, Claude, and Codex reason about tradeoffs and arrive at different solutions. In practice, this helps you surface issues earlier by using agents for different kinds of review: Architectural guardrails: Ask one or more agents to evaluate modularity and coupling, helping identify changes that could introduce unintended side effects. Logical pressure testing: Use another agent to hunt for edge cases, async pitfalls, or scale assumptions that could cause problems in production. Pragmatic implementation: Have a separate agent propose the smallest, backward-compatible change to keep the blast radius of a refactor low. This method of working moves your reviews and thinking to strategy over syntax. Our collaboration with GitHub has always pushed the frontier of how developers build software. The first Codex model helped power Copilot and inspired a new generation of AI-assisted coding. We share GitHub’s vision of meeting developers wherever they work, and we’re excited to bring Codex to GitHub and VS Code. Codex helps engineers work faster and with greater confidence—and with this integration, millions more developers can now use it directly in their primary workspace, extending the power of Codex everywhere code gets written. Alexander Embiricos, OpenAI Why running agents on GitHub matters GitHub is already where code lives, collaboration happens, and decisions are reviewed, governed, and shipped. Making coding agents native to that workflow, rather than external tools, makes them even more useful at scale. Instead of copying and pasting context between tools, documents, and threads, all discussion and proposed changes stay attached to the repository itself. With Copilot, Claude, and Codex working directly in GitHub and VS Code, you can: Explore tradeoffs early: Run agents in parallel to surface competing approaches and edge cases before code hardens. Keep context attached to the work: Agents operate inside your repository, issues, and pull requests instead of starting from stateless prompts. Avoid new review processes: Agent-generated changes show up as draft pull requests and comments, reviewed the same way you’d review a teammate’s work. There are no new dashboards to learn, and no separate AI workflows to manage. Everything runs inside the environments you already use. Built for teams, not just individuals These workflows don’t just benefit individual developers. Agent HQ gives you org-wide visibility and systematic control over how AI interacts with your codebase: Agent controls: Manage access and security policies in one place, allowing enterprise admins to define which agents and models are permitted across the organization. Code quality checks: GitHub Code Quality (in public preview) extends Copilot’s security checks to evaluate the maintainability and reliability impact of changed code, helping ensure “LGTM” reflects long-term code health. Automated first-pass review: We have integrated a code review step directly into the Copilot’s workflow, allowing Copilot to address initial problems before a developer ever sees the code. Impact metrics: Use the Copilot metrics dashboard (in public preview) to track usage and impact across your entire organization, providing clear traceability for agent-generated work. Security and auditability: Maintain full control with audit logging and enterprise-grade access management, ensuring agents work with your security posture instead of against it. This allows teams to adopt agent-based workflows without sacrificing code quality, accountability, or trust. More agents coming soon Access to Claude and Codex will soon expand to more Copilot subscription types. In the meantime, we’re actively working with partners, including Google, Cognition, and xAI to bring more specialized agents into GitHub, VS Code, and Copilot CLI workflows. Read the docs to get started > The post Pick your agent: Use Claude and Codex on Agent HQ appeared first on The GitHub Blog.
What the fastest-growing tools reveal about how software is being built
What languages are growing fastest, and why? What about the projects that people are interested in the most? Where are new developers cutting their teeth? Let’s take a look at Octoverse data to find out. The post What the fastest-growing tools reveal about how software is being built appeared first on The GitHub Blog.
In 2025, software development crossed a quiet threshold. In our latest Octoverse report, we found that the fastest-growing languages, tools, and open source projects on GitHub are no longer about shipping more code. Instead, they’re about reducing friction in a world where AI is helping developers build more, faster. By looking at some of the areas of fastest growth over the past year, we can see how developers are adapting through: The programming languages that are growing most in AI-assisted development workflows. The tools that win when speed and reproducibility matter. The areas where new contributors are showing up (and what helps them stick). Rather than catalog trends, we want to focus on what those signals mean for how software is being built today and what choices you might consider heading into 2026. The elephant in the room: Typescript is the new #1 In August 2025, TypeScript became the most-used language on GitHub, overtaking Python and JavaScript for the first time. Over the past year, TypeScript added more than one million contributors, which was the largest absolute growth of any language on GitHub. <img data-recalc-dims="1" fetchpriority="high" decoding="async" height="576" width="1024" src="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-top-programming-languages.png?resize=1024%2C576" alt="A chart showing the top 10 programming languages on GitHub from 2023 to 2025. TypeScript rises to #1 in 2025, overtaking Python and JavaScript, which move to #2 and #3 respectively. Other top languages include Java, C#, PHP, Shell, C++, HCL, and Go. The chart tracks ranking changes over time on a dark background with colored lines representing each language." class="wp-image-91509" srcset="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-top-programming-languages.png?w=1728 1728w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-top-programming-languages.png?w=300 300w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-top-programming-languages.png?w=768 768w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-top-programming-languages.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-top-programming-languages.png?w=1536 1536w" sizes="(max-width: 1000px) 100vw, 1000px" /> Python also continued to grow rapidly, adding roughly 850,000 contributors (+48.78% YoY), while JavaScript grew more slowly (+24.79%, ~427,000 contributors). Together, TypeScript and Python both significantly outpaced JavaScript in both total and percentage growth. This shift signals more than a preference change. Typed languages are increasingly becoming the default for new development, particularly as AI-assisted coding becomes routine. Why is that? In practice, a significant portion of the failures teams encounter with AI-generated code surface as type mismatches, broken contracts, or incorrect assumptions between components. Stronger type systems act as early guardrails: they can help catch errors sooner, reduce review churn, and make AI-generated changes easier to reason about before code reaches production. If you’re going to be using AI in your software design, which more and more developers are doing on a daily basis, strongly typed languages are your friend. Here’s what this means in practice: If you’re starting a new project today, TypeScript is increasingly becoming the default (especially for teams using AI in daily development). If you’re introducing AI-assisted workflows into an existing JavaScript codebase, adding types may reduce friction more than switching models or tools. Python is key for AI Contributor counts show who is using a language. Repository data shows what that language is being used to build. When we look specifically at AI-focused repositories, Python stands apart. As of August 2025, nearly half of all new AI projects on GitHub were built primarily in Python. <img data-recalc-dims="1" decoding="async" height="576" width="1024" src="https://github.blog/wp-content/uploads/2026/01/GitHub-Octoverse-2025_Most-commonly-used-languages-inside-AI%E2%80%91tagged-repos_1920x1080_2x.png?resize=1024%2C576" alt="A chart listing the most commonly used programming languages in AI-tagged projects on GitHub in 2025. Python ranks first with 582,000 repositories (+50.7% year over year), followed by JavaScript with 88,000 (+24.8%), TypeScript with 86,000 (+77.9%), Shell with 9,000 (+324%), and C++ with 7,800 (+11%). The chart includes brief descriptions of each language’s role in AI development, displayed on a blue gradient background with green geometric ribbon graphics." class="wp-image-93553"> This matters because AI projects now account for a disproportionate share of open source momentum. Six of the ten fastest-growing open source projects by contributors in 2025 were directly focused on AI infrastructure or tooling. <img data-recalc-dims="1" decoding="async" height="576" width="1024" src="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?resize=1024%2C576" alt="A table listing the fastest-growing open source projects on GitHub in 2025 by contributors. The top ten are zen-browser/desktop, cline/cline, vllm-project/vllm, astral-sh/uv, microsoft/vscode, infiniflow/ragflow, sgl-project/sglang, continuedev/continue, comfyanonymous/ComfyUI, and home-assistant/core. Growth rates range from 2,301% to 6,836%, with most projects marked as AI-focused. Displayed on a blue gradient background with the GitHub Octoverse ribbon graphic." class="wp-image-91494" srcset="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=1440 1440w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=300 300w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=768 768w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-fastest-growing-open-source-projects-by-contributors.png?w=1024 1024w" sizes="(max-width: 1000px) 100vw, 1000px" /> Python’s role here isn’t new, but it is evolving. The data suggests a shift from experimentation toward production-ready AI systems, with Python increasingly anchoring packaging, orchestration, and deployment rather than living only in notebooks. Moreover, Python is likely to continue to grow in 2026, as AI continues to gain support and additional projects. Here’s what this means in practice: Python remains the backbone of applied AI work from training and inference to orchestration. Production-focused Python skills such as packaging, typing, CI, and containerization are becoming more important than exploratory scripting alone. A deeper look at the top open source projects Looking across the fastest-growing projects, a clear pattern emerges: developers are optimizing for speed, control, and predictable outcomes. Many of the fastest-growing tools emphasize performance and minimalism. Projects like astral-sh/uv, a package and project manager, focus on dramatically faster Python package management. This reflects a growing intolerance for slow feedback loops and non-deterministic environments. Having just one of these projects could be an anomaly, but having multiple indicates a clear trend. This trend aligns closely with AI-assisted workflows where iteration speed and reproducibility directly impact developer productivity. Here’s what this means in practice: Fast installs and deterministic builds increasingly matter as much as feature depth. Tools that reduce “works on my machine” moments are winning developer mindshare. Where first-time open source contributors are showing up As the developer population grows, understanding where first-time contributors show up (and why) becomes increasingly important. <img data-recalc-dims="1" loading="lazy" decoding="async" height="576" width="1024" src="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-open-source-projects-attracting-most-first-time-contributors.jpg?resize=1024%2C576" alt="A chart showing the open source projects that attracted the most first-time contributors on GitHub in 2025. The top ten are microsoft/vscode, firstcontributions/first-contributions, home-assistant/core, slackblitz/bolt.new, flutter/flutter, zen-browser/desktop, is-a-dev/register, vllm-project/vllm, comfyanonymous/ComfyUI, and ollama/ollama. Displayed on a blue gradient background with green 3D ribbon graphics." class="wp-image-91623" srcset="https://github.blog/wp-content/uploads/2025/10/octoverse-2025-open-source-projects-attracting-most-first-time-contributors.jpg?w=1944 1944w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-open-source-projects-attracting-most-first-time-contributors.jpg?w=300 300w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-open-source-projects-attracting-most-first-time-contributors.jpg?w=768 768w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-open-source-projects-attracting-most-first-time-contributors.jpg?w=1024 1024w, https://github.blog/wp-content/uploads/2025/10/octoverse-2025-open-source-projects-attracting-most-first-time-contributors.jpg?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Projects like VS Code and First Contributions continued to top the list over the last year, reflecting both the scale of widely used tools and the persistent need for low-friction entry points into open source (notably, we define contributions as any content-generating activity on GitHub). Despite this growth, basic project governance remains uneven across the ecosystem. README files are common, but contributor guides and codes of conduct are still relatively rare even as first-time contributions increase. This gap represents one of the highest-leverage improvements maintainers and open source communities can make. The fact that most of the projects on this list have detailed documentation on what the project is and how to contribute shows the importance of this guidance. Here’s what this means in practice: Clear documentation lowers the cost of contribution more than new features. Contributor guides and codes of conduct can help convert curiosity into sustained participation. Improving project hygiene is often the fastest way to grow a contributor base. Putting it all together Taken together, these trends point to a shift in what developers value and how they choose tools. AI is no longer a separate category of development. It’s shaping the languages teams use, which tools gain traction, and which projects attract contributors. Typed languages like TypeScript are becoming the default for reliability at scale, while Python remains central to AI-driven systems as they move from prototypes into production. Across the ecosystem, developers are rewarding tools that minimize friction with faster feedback loops, reproducible environments, and clearer contribution paths. Developers and teams that optimize for speed, clarity, and reliability are shaping how software is being built. As a reminder, you can check out the full 2025 Octoverse report for more information and make your own conclusions. There’s a lot of good data in there, and we’re just scratching the surface of what you can learn from it. The post What the fastest-growing tools reveal about how software is being built appeared first on The GitHub Blog.
How to maximize GitHub Copilot’s agentic capabilities
A senior engineer's guide to architecting and extending Copilot's real-world applications. The post How to maximize GitHub Copilot’s agentic capabilities appeared first on The GitHub Blog.
Modern engineering work rarely lives in a single file. Real systems evolve across years of incrementally layered decisions—some good, some accidental. A single feature request (“Add tagging to notes,” “Refactor the validation layer,” “Support a new consumer on our API”) often touches controllers, domain models, repositories, migrations, tests, documentation, and deployment strategy. Copilot’s agentic capabilities don’t replace your judgment in these situations—they amplify it. When used well, Copilot becomes a partner in system design, refactoring, modernization, and multi-file coordination. This guide focuses on architecture-aware, multi-step workflows used every day by staff engineers, but written to be accessible for earlier-career engineers who want to understand how senior engineers think—and how Copilot can accelerate their own growth. It draws on four GitHub Skills exercises (linked below), and builds toward a complete, real-world scenario: extending a small modular Notes Service with a tagging subsystem, refactoring a validation layer, designing a safe migration, and modernizing tests. Before you start You’ll get the most out of this guide if you have: GitHub Copilot with agent mode enabled Some familiarity with service-layer architectures (Node, Python, Go—language doesn’t matter Copy a GitHub Skills exercise template to your handle or organization (use the green “Copy Exercise” button) A willingness to let Copilot propose solutions—and the judgment to inspect and challenge them If you’re earlier in your career, don’t worry. Each section explains why these patterns matter and how to practice them safely. Learn interactively at your own pace with GitHub Skills The following free modules map directly to the workflows in this guide: Expand your team with Copilot: multi-step agentic execution Build applications with Copilot (agent mode): task-driven code generation Modernize your legacy codebases with Copilot: refactoring and migrations Customize Your GitHub Copilot experience: Customize GitHub Copilot’s behavior with custom instructions, prompts, and custom agents for your specific development workflows Each one is designed to be forkable, inspectable, and safe for experimentation. You can also explore all our GitHub Skills courses below. Explore GitHub Skills > Using Copilot for system design and decomposition (not just scaffolding) Senior engineers rarely begin by writing code. They begin by identifying boundaries: domain logic, data access, interfaces, and how modules should interact. Copilot agent mode can help by revealing structural issues and proposing architectures. Prompt: Analyze this service and propose a modular decomposition with domain, infrastructure, and interface layers. Identify anti-patterns, coupling issues, and potential failure points. You’ll typically get back: Proposed module boundaries Cross-layer coupling concerns Async/transaction pitfalls Duplication or tight weaving of responsibilities Testability and observability implications This transforms Copilot from an autocomplete tool into a design reviewer. You can push further by asking it to compare architectures: Compare hexagonal architecture vs. layered architecture for this codebase. Recommend one based on the constraints here. Include tradeoffs. Want to try it yourself? Use these proposals as starting points. Building a modular service using agentic workflows Once boundaries are defined, Copilot can coordinate changes across modules. Prompt: Implement the domain, controller, and repository layers as distinct modules. Use dependency inversion to reduce coupling. Document assumptions and contracts for each module. Copilot will typically generate: Domain model interfaces Repository abstractions Controller logic calling domain services A short Markdown summary describing each module For earlier-career engineers, this provides exposure to real engineering patterns. For senior engineers, it provides leverage and reduces boilerplate overhead. Feature work with architectural awareness (example: tagging subsystem) Adding a tagging subsystem is a deceptively simple request with meaningful architectural implications. Even this single feature forces decisions across the system: Data modeling: embedded tags vs. normalized tables vs. many-to-many relationships Search behavior: how tags affect indexing, filtering, and relevance API contracts: whether tags are first-class resources or an implementation detail Validation boundaries: where constraints and invariants are enforced Migration and rollout: additive vs. breaking changes and rollback strategy Before touching code, ask Copilot to map the impact. Prompt: Propose the architectural changes required to add a tagging subsystem. Identify migration needs, cross-cutting concerns, caching or indexing implications, and potential regressions. Copilot may identify: Tag–note relationships (one-to-many or many-to-many) Migration strategy Impact to search logic Required test updates Changes in validation logic Implications on external API consumers This is the staff-level lens that Copilot can help junior developers adopt. Then implement it: Implement the tagging domain model, schema changes, repository updates, and controller logic. Update tests and documentation. Show each change as a diff. Example output (simplified) Migration example: ALTER TABLE notes ADD COLUMN tags TEXT DEFAULT '[]'; Domain model example: export interface Tag { id: string; label: string; } export interface Note { id: string; title: string; body: string; tags: Tag[]; } Controller update (partial): await noteService.addTag(noteId, { label: req.body.label }); This is where agent mode shines: coordinating multiple files with consistent intent. Schema migrations and safe rollout strategies At senior levels, the hardest part isn’t writing SQL. It’s designing a change that is: Backward compatible Reversible Safe under load Transparent to dependent systems Ask Copilot to reason about this: Prompt: Generate an additive, backward-compatible schema migration to support the tagging subsystem. Describe the rollback plan, compatibility window, and expected impact to existing clients. This forces Copilot to consider: Mon-breaking additive fields Optional fields vs. required fields Whether a dual-read or dual-write strategy is needed Safe rollback procedures API versioning implications If you’re earlier in your career, this offers lessons on how safe migrations are designed. And if you’re more experienced, this gives you a repeatable workflow for multi-step schema evolution. Advanced refactoring with agentic workflows Let’s perform a real cross-module refactor: extracting validation out of controllers into a domain service. Prompt: Create a step-by-step refactor plan to extract validation logic into a domain service. Identify affected modules and required test updates. Copilot may output something like: Introduce domain validationService Move validation logic from controller to service Update controllers to use new service Update repository logic where validation assumptions leak Update domain tests Update integration tests Execute in incremental steps Prompt: Execute steps 1–3 only. Stop before controller rewrites. Provide detailed diffs and call out risky areas. This is a low-blast-radius refactor, modeled directly in the IDE. Modernizing test strategy Instead of asking Copilot “write tests,” ask it to assess the entire suite. Prompt: Analyze the current test suite and identify systemic gaps. Recommend a modernization plan including contract, integration, and domain-layer tests. Then implement contract tests: describe("NotesRepository contract", () => { test("create + fetch returns a fully hydrated note object", async () => { const note = await notesRepo.create({ title: "Test", body: "…" }); const fetched = await notesRepo.get(note.id); expect(fetched).toMatchObject({ title: "Test" }); expect(fetched.id).toBeDefined(); }); }); This elevates testing into an architectural concern. A complete end-to-end workflow Bringing it all together, here’s a real sequence you might run with Copilot: Ask Copilot to analyze the existing architecture: identify hazards, modularization opportunities Define module boundaries: domain, repository, controller layers Add tagging subsystem: architectural assessment to implementation to tests to doc updates Create a backward-compatible migration: additive schema to rollback plan Perform a targeted refactor: validation layer extraction Modernize tests: contract + integration + domain tests This workflow is architecturally realistic—and a model for how Copilot becomes a system-level collaborator. What agent mode is not for It’s important to clarify that agent mode is not ideal for: Altering domain invariants without human review Redesigning cross-service ownership boundaries Replacing logic driven by institutional knowledge Large sweeping rewrites across hundreds of files Debugging deep runtime issues Copilot should support your decision-making, not replace it. Key takeaways Agent mode excels at multi-step, multi-file engineering workflows. Copilot is a design and coordination partner, not a replacement for judgment. Use Copilot for decomposition, refactoring, migrations, test strategy, and documentation. Start with architecture, not implementation. You can safely practice all these patterns in GitHub Skills. Learn more about agent mode > Where to go next Here’s where GitHub Skills comes in—not as “beginner content,” but as a set of guided, self-contained labs that reinforce the patterns above. Even senior engineers will benefit: These exercises are structured so you can reliably recreate complex workflows and test Copilot’s behavior in controlled environments. Explore GitHub Skills > The post How to maximize GitHub Copilot’s agentic capabilities appeared first on The GitHub Blog.
From pixels to characters: The engineering behind GitHub Copilot CLI’s animated ASCII banner
Learn how GitHub built an accessible, multi-terminal-safe ASCII animation for the Copilot CLI using custom tooling, ANSI color roles, and advanced terminal engineering. The post From pixels to characters: The engineering behind GitHub Copilot CLI’s animated ASCII banner appeared first on The GitHub Blog.
Most people think ASCII art is simple, and a nostalgic remnant of the early internet. But when the GitHub Copilot CLI team asked for a small entrance banner for the new command-line experience, they discovered the opposite: An ASCII animation in a real-world terminal is one of the most constrained UI engineering problems you can take on. Part of what makes this even more interesting is the moment we’re in. Over the past year, CLIs have seen a surge of investment as AI-assisted and agentic workflows move directly into the terminal. But unlike the web—where design systems, accessibility standards, and rendering models are well-established—the CLI world is still fragmented. Terminals behave differently, have few shared standards, and offer almost no consistent accessibility guidelines. That reality shaped every engineering decision in this project. Different terminals interpret ANSI color codes differently. Screen readers treat fast-changing characters as noise. Layout engines vary. Buffers flicker. Some users override global colors for accessibility. Others throttle redraw speed. There is no canvas, no compositor, no consistent rendering model, and no standard animation framework. By the numbers 3 seconds of animation ~20 frames ~6,000 lines of TypeScript Dozens of terminal + theme combinations tested So when an animated Copilot mascot flying into the terminal appeared, it looked playful. But behind it was serious engineering work, unexpected complexity, a custom design toolchain, and a tight pairing between a designer and a long-time CLI engineer. That complexity only became fully visible once the system was built. In the end, animating a three-second ASCII banner required over 6,000 lines of TypeScript—most of it dedicated not to visuals, but to handling terminal inconsistencies, accessibility constraints, and maintainable rendering logic. This is the technical story of how it came together. 📦 What’s new in GitHub Copilot CLI GitHub Copilot CLI brings agentic workflows directly into your terminal—letting you plan projects, modify files, run commands, use custom agents, and delegate tasks to the cloud, all without leaving the CLI. Since its introduction, Copilot CLI has expanded to support richer, more flexible agentic workflows: Works the way you do with persistent memory, infinite sessions, and intelligent compaction Helps you think using explore, plan, and review workflows where you can choose the model at each step Executes on your behalf with custom agents, agent skills, full MCP support, and async task delegation Want to bring these same agentic capabilities into your own tools or products? The GitHub Copilot SDK exposes the same execution loop that powers Copilot CLI, so you can embed agents into any application using your Copilot subscription or your own model keys. Learn more about the Copilot SDK > Why animated ASCII is a hard engineering problem Before diving into the build process, it’s worth calling out why this problem space is more advanced than it looks. Terminals don’t have a canvas Unlike browsers (DOM), native apps (views), or graphics frameworks (GPU surfaces), terminals treat output as a stream of characters. There’s no native concept of: Frames Sprites Z-index Rasterized pixels Animation tick rates Because of this, every “frame” has to be manually repainted using cursor movements and redraw commands. There’s no compositor smoothing anything over behind the scenes. Everything is stdout writes + ANSI control sequences. ANSI escape codes are inconsistent, and terminal color is its own engineering challenge ANSI escape codes like \x1b[35m (bright magenta) or \x1b[H (cursor home) behave differently across terminals—not just in how they render, but in whether they’re supported at all. Some environments (like Windows Command Prompt or older versions of PowerShell) have limited or no ANSI support without extra configuration. But even in terminals that do support ANSI, the hardest part isn’t the cursor movement. It’s the colors. When you’re building a CLI, you realistically have three approaches: Use no color at all. This guarantees broad compatibility, but makes it harder to highlight meaning or guide users’ attention—especially in dense CLI output. Use richer color modes (3-bit, 4-bit, 8-bit, or truecolor) that aren’t uniformly supported or customizable. This introduces a maintenance headache: Different terminals, themes, and accessibility profiles render the same color codes differently, and users often disagree about what “good” colors look like. Use a minimal, customizable palette (usually 4-bit colors) that most terminals allow users to override in their preferences. This is the safest path, but it limits how accurately you can represent a brand palette—and it forces you to design for environments with widely varying contrast and theme choices. For the Copilot CLI animation, this meant treating color as a semantic system, not a literal one: Instead of committing specific RGB values, the team mapped high-level “roles” (eyes, goggles, shadow, border) to ANSI colors that degrade gracefully across different terminals and accessibility settings. Accessibility is a first-class concern Terminals are used by developers with a wide range of visual abilities—not just blind users with screen readers, but also low-vision users, color-blind users, and anyone working in high-contrast or customized themes. That means: Rapid re-renders can create auditory clutter for screen readers Color-based meaning must degrade safely, since bold, dim, or subtle hues may not be perceivable Low-vision users may not see contrast differences that designers expect Animations must be opt-in, not automatic Clearing sequences must avoid confusing assistive technologies This is also why the Copilot CLI animation ended up behind an opt-in flag early on—accessibility constraints shaped the architecture from the start. These constraints guided every decision in the Copilot CLI animation. The banner had to work when colors were overridden, when contrast was limited, and even when the animation itself wasn’t visible. Ink (React for the terminal) helps, but it’s not an animation engine Ink lets you build terminal interfaces using React components, but: It re-renders on every state change It doesn’t manage frame deltas It doesn’t synchronize with terminal paint cycles It doesn’t solve flicker or cursor ghosting Which meant animation logic had to be handcrafted. Frame-based ASCII animation has no existing workflow for designers There are tools for ASCII art, but virtually none for: Frame-by-frame editing Multi-color ANSI previews Exporting color roles Generating Ink-ready components Testing contrast and accessibility Even existing ANSI preview tools don’t simulate how different terminals remap colors or handle cursor updates, which makes accurate design iteration almost impossible without custom tooling. So the team had to build one. Part 1: A request that didn’t fit any workflow Cameron Foxly (@cameronfoxly), a brand designer at GitHub with a background in animation, was asked to create a banner for the Copilot CLI. “Normally, I’d build something in After Effects and hand off assets,” Cameron said. “But engineers didn’t have the time to manually translate animation frames into a CLI. And honestly, I wanted something more fun.” He’d seen the static ASCII intro in Claude Code and knew Copilot deserved more personality. The 3D Copilot mascot flying in to reveal the CLI logo felt right. But after attempting to create just one frame manually, the idea quickly ran into reality. “It was a nightmare,” Cameron said. “If this is going to exist, I need to build my own tool.” Part 2: Building an ASCII animation editor from scratch Cameron opened an empty repository in VS Code, and began asking GitHub Copilot for help scaffolding an animation MVP that could: Read text files as frames Render them sequentially Control timing Clear the screen without flicker Add a primitive “UI” Within an hour, he had a working prototype that was monochrome, but functional. Simplified early animation loop Below is a simplified example variation of the frame loop logic Cameron prototyped: import fs from "fs"; import readline from "readline"; /** * Load ASCII frames from a directory. */ const frames = fs .readdirSync("./frames") .filter(f => f.endsWith(".txt")) .map(f => fs.readFileSync(`./frames/${f}`, "utf8")); let current = 0; function render() { // Move cursor to top-left of terminal readline.cursorTo(process.stdout, 0, 0); // Clear the screen below the cursor readline.clearScreenDown(process.stdout); // Write the current frame process.stdout.write(frames[current]); // Advance to next frame current = (current + 1) % frames.length; } // 75ms = ~13fps. Higher can cause flicker in some terminals. setInterval(render, 75); This introduced the first major obstacle: color. The prototype worked in monochrome, but the moment color was added, inconsistencies across terminals—and accessibility constraints—became the dominant engineering problem. Part 3: ANSI color theory and the real-world limitations The Copilot brand palette is vibrant and high-contrast, which is great for web but exceptionally challenging for terminals. ANSI terminals support: 16-color mode (standard) 256-color mode (extended) Sometimes truecolor (“24-bit”) but inconsistently Even in 256-color mode, terminals remap colors based on: User themes Accessibility settings High-contrast modes Light/dark backgrounds OS-level overrides Which means you can’t rely on exact hues. You have to design with variability in mind. Cameron needed a way to paint characters with ANSI color roles while previewing how they look in different terminals. He took a screenshot of the Wikipedia ANSI table, handed it to Copilot, and asked it to scaffold a palette UI for his tool. Adding a color “brush” tool A simplified version: function applyColor(char, color) { // Minimal example: real implementation needed support for roles, // contrast testing, and multiple ANSI modes. const codes = { magenta: "\x1b[35m", cyan: "\x1b[36m", white: "\x1b[37m" }; return `${codes[color]}${char}\x1b[0m`; // Reset after each char } This enabled Cameron to paint ANSI-colored ASCII like you would in Photoshop, one character at a time. But now he had to export it into the real Copilot CLI codebase. Part 4: Exporting to Ink (React for the terminal) Ink is a React renderer for building CLIs using JSX components. Instead of writing to the DOM, components render to stdout. Cameron asked Copilot to help generate an Ink component that would: Accept frames Render them line-by-line Animate them with state updates Integrate cleanly into the CLI codebase Simplified Ink frame renderer import React from "react"; import { Box, Text } from "ink"; /** * Render a single ASCII frame. */ export const CopilotBanner = ({ frame }) => ( <Box flexDirection="column"> {frame.split("\n").map((line, i) => ( <Text key={i}>{line}</Text> ))} </Box> ); And a minimal animation wrapper: export const AnimatedBanner = () => { const [i, setI] = React.useState(0); React.useEffect(() => { const id = setInterval(() => setI(x => (x + 1) % frames.length), 75); return () => clearInterval(id); }, []); return <CopilotBanner frame={frames[i]} />; }; This gave Cameron the confidence to open a pull request (his first engineering pull request in nine years at GitHub). “Copilot filled in syntax I didn’t know,” Cameron said. “But I still made all the architectural decisions.” Now it was time for the engineering team to turn a prototype into something production-worthy. Part 5: Terminal animation isn’t solved technology Andy Feller (@andyfeller), a long-time GitHub engineer behind the GitHub CLI, partnered with Cameron to bring the animation into the Copilot CLI codebase. Unlike browsers—which share rendering engines, accessibility APIs, and standards like WCAG—terminal environments are a patchwork of behaviors inherited from decades-old hardware like the VT100. There’s no DOM, no semantic structure, and only partial agreement on capabilities across terminals. This makes even “simple” UI design problems in the terminal uniquely challenging, especially as AI-driven workflows push CLIs into daily use for more developers. “There’s no framework for terminal animations,” Andy explained. “We had to figure out how to do this without flickering, without breaking accessibility, and across wildly different terminals.” Andy broke the engineering challenges into four broad categories: Challenge 1: From banner to ready without flickering Most terminals repaint the entire viewport when new content arrives. At the same time, CLIs come with a strict usability expectation: when developers run a command, they want to get to work immediately. Any animation that flickers, blocks input, or lingers too long actively degrades the experience. This created a core tension the team had to resolve: how to introduce a brief, animated banner without slowing startup, stealing focus, or destabilizing the terminal render loop. In practice, this was complicated by the fact that terminals behave differently under load. Some: Throttle fast writes Reveal cleared frames momentarily Buffer output differently Repaint the cursor region inconsistently To avoid flicker while keeping the CLI responsive across popular terminals like iTerm2, Windows Terminal, and VS Code, the team had to carefully coordinate several interdependent concerns: Keeping the animation under three seconds so it never delayed user interaction Separating static and non-static components to minimize unnecessary redraws Initializing MCP servers, custom agents, and user setup without blocking render Working within Ink’s asynchronous re-rendering model The result was an animation treated as a non-blocking, best-effort enhancement—visible when it could be rendered safely, but never at the expense of startup performance or usability. Challenge 2: Brand color mapping in ANSI “ANSI color consistency simply doesn’t exist,” Andy said. Most modern terminals support 8-bit color, allowing CLIs to choose from 256 colors. However, how those colors are actually rendered varies widely based on terminal themes, OS settings, and user accessibility overrides. In practice, CLIs can’t rely on exact hues—or even consistent contrast—across environments. The Copilot banner introduced an additional complexity: although it’s rendered using text characters, the block-letter Copilot logo functions as a graphical object, not readable body text. Under accessibility guidelines, non-text graphical elements have different contrast requirements than text, and they must remain perceivable without relying on fine detail or precise color matching. To account for this, the team deliberately chose a minimal 4-bit ANSI palette—one of the few color modes most terminals allow users to customize—to ensure the animation remained legible under high-contrast themes, low-vision settings, and color overrides. This meant the team had to: Treat the Copilot wordmark as non-text graphical content with appropriate contrast requirements Select ANSI color codes that approximate the Copilot palette without relying on exact hues Satisfy WCAG contrast guidance for both text and non-text elements Ensure the animation remained legible in light and dark terminals Degrade gracefully when users override terminal colors for accessibility Test color combinations across multiple terminal emulators and theme configurations Rather than encoding brand colors directly, the animation maps semantic roles—such as borders, eyes, highlights, and text—to ANSI color slots that terminals can reinterpret safely. This allows the banner to remain recognizable without assuming control over the user’s color environment. <img data-recalc-dims="1" loading="lazy" decoding="async" width="872" height="246" src="https://github.blog/wp-content/uploads/2026/01/banner1.png?resize=872%2C246" alt="Dark mode version of the GitHub Copilot CLI banner." class="wp-image-93470" srcset="https://github.blog/wp-content/uploads/2026/01/banner1.png?w=872 872w, https://github.blog/wp-content/uploads/2026/01/banner1.png?w=300 300w, https://github.blog/wp-content/uploads/2026/01/banner1.png?w=768 768w" sizes="auto, (max-width: 872px) 100vw, 872px" /> <img data-recalc-dims="1" loading="lazy" decoding="async" width="869" height="242" src="https://github.blog/wp-content/uploads/2026/01/banner2.png?resize=869%2C242" alt="Light mode version of the GitHub Copilot CLI banner." class="wp-image-93471" srcset="https://github.blog/wp-content/uploads/2026/01/banner2.png?w=869 869w, https://github.blog/wp-content/uploads/2026/01/banner2.png?w=300 300w, https://github.blog/wp-content/uploads/2026/01/banner2.png?w=768 768w" sizes="auto, (max-width: 869px) 100vw, 869px" /> Challenge 3: Making the animation maintainable Cameron’s prototype was a great starting point for Andy to incorporate into the Copilot CLI but it wasn’t without its challenges: Banner consisted of ~20 animation frames covering an 11×78 area There are ~10 animation elements to stylize in any given frame Needed a way to separate the text of the frame from the colors involved Each frame mapped hard coded colors to row and column coordinates Each frame required precise timing to display Cameron’s vision First, the animation was broken down into distinct animation elements that could be used to create separate light and dark themes: type AnimationElements = | "block_text" | "block_shadow" | "border" | "eyes" | "head" | "goggles" | "shine" | "stars" | "text"; type AnimationTheme = Record<AnimationElements, ANSIColors>; const ANIMATION_ANSI_DARK: AnimationTheme = { block_text: "cyan", block_shadow: "white", border: "white", eyes: "greenBright", head: "magentaBright", goggles: "cyanBright", shine: "whiteBright", stars: "yellowBright", text: "whiteBright", }; const ANIMATION_ANSI_LIGHT: AnimationTheme = { block_text: "blue", block_shadow: "blackBright", border: "blackBright", eyes: "green", head: "magenta", goggles: "cyan", shine: "whiteBright", stars: "yellow", text: "black", }; Next, the overall animation and subsequent frames would capture content, color, duration needed to animate the banner: interface AnimationFrame { title: string; duration: number; content: string; colors?: Record<string, AnimationElements>; // Map of "row,col" positions to animation elements } interface Animation { metadata: { id: string; name: string; description: string; }; frames: AnimationFrame[]; } Then, each animation frame was captured to separate frame content from stylistic and animation details, resulting in over 6,000 lines of TypeScript to safely animate three seconds of the Copilot logo across terminals with wildly different rendering and accessibility behaviors: const frames: AnimationFrame[] = [ { title: "Frame 1", duration: 80, content: ` ┌┐ ││ ││ └┘`, colors: { "1,0": "border", "1,1": "border", "2,0": "border", "2,1": "border", "10,0": "border", "10,1": "border", "11,0": "border", "11,1": "border", }, }, { title: "Frame 2", duration: 80, content: ` ┌── ──┐ │ │ █▄▄▄ ███▀█ ███ ▐▌ ███ ▐▌ ▀▀█▌ ▐ ▌ ▐ │█▄▄▌ │ └▀▀▀ ──┘`, colors: { "1,0": "border", "1,1": "border", "1,2": "border", "1,8": "border", "1,9": "border", "1,10": "border", "2,0": "border", "2,10": "border", "3,1": "head", "3,2": "head", "3,3": "head", "3,4": "head", "4,1": "head", "4,2": "head", "4,3": "goggles", "4,4": "goggles", "4,5": "goggles", "5,1": "head", "5,2": "goggles", "5,3": "goggles", "5,5": "goggles", "5,6": "goggles", "6,1": "head", "6,2": "goggles", "6,3": "goggles", "6,5": "goggles", "6,6": "goggles", "7,3": "goggles", "7,4": "goggles", "7,5": "goggles", "7,6": "goggles", "8,3": "eyes", "8,5": "head", "9,4": "head", "10,0": "border", "10,1": "head", "10,2": "head", "10,3": "head", "10,4": "head", "10,10": "border", "11,0": "border", "11,1": "head", "11,2": "head", "11,3": "head", "11,8": "border", "11,9": "border", "11,10": "border", }, }, Finally, each animation frame is rendered building segments of text based on consecutive color usage with the necessary ANSI escape codes: {frameContent.map((line, rowIndex) => { const truncatedLine = line.length > 80 ? line.substring(0, 80) : line; const coloredChars = Array.from(truncatedLine).map((char, colIndex) => { const color = getCharacterColor(rowIndex, colIndex, currentFrame, theme, hasDarkTerminalBackground); return { char, color }; }); // Group consecutive characters with the same color const segments: Array<{ text: string; color: string }> = []; let currentSegment = { text: "", color: coloredChars[0]?.color || theme.COPILOT }; coloredChars.forEach(({ char, color }) => { if (color === currentSegment.color) { currentSegment.text += char; } else { if (currentSegment.text) segments.push(currentSegment); currentSegment = { text: char, color }; } }); if (currentSegment.text) segments.push(currentSegment); return ( <Text key={rowIndex} wrap="truncate"> {segments.map((segment, segIndex) => ( <Text key={segIndex} color={segment.color}> {segment.text} </Text> ))} </Text> ); })} Challenge 4: Accessibility-first design The engineering team approached the banner with the same philosophy as the GitHub CLI’s accessibility work: Respect global color overrides both in terminal and system preferences After the first use, avoid animations unless explicitly enabled via the Copilot CLI configuration file Minimize ANSI instructions that can confuse assistive tech “CLI accessibility is under researched,” Andy noted. “We’ve learned a lot from users who are blind as well as users with low vision, and those lessons shaped this project.” Because of this, the animation is opt-in and gated behind its own flag—so it’s not something developers see by default. And when developers run the CLI in –screen-reader mode, the banner is automatically skipped so no decorative characters or motion are sent to assistive technologies. Part 6: An architecture built to scale By the end of the refactor, the team had: Frames stored as plain text Animation elements Themes as simple mappings A runtime colorization step Ink-driven timing and rendering A maintainable foundation for future animations This pattern—storing frames as plain text, layering semantic roles, and applying themes at runtime—isn’t specific to Copilot. It’s a reusable approach for anyone building terminal UIs or animations. Part 7: What this project reveals about building for the terminal A “simple ASCII banner” turned into: A frame-based animation tool that didn’t exist A custom ANSI color palette strategy A new Ink component A maintainable rendering architecture Accessibility-first CLI design choices A designer’s first engineering contribution Real-world testing across diverse terminals Open source contributions from the community “The most rewarding part was stepping into open source for the first time,” Cameron said. “With Copilot, I was able to build out my MVP ASCII animation tool into a full open source app at ascii-motion.app,. Someone fixed a typo in my README, and it made my day.” As Andy pointed out, building accessible experiences for CLIs is still largely unexplored territory and far behind the tooling and standards available for the web. Today, developers are already contributing to Cameron’s ASCII Motion tool, and the Copilot CLI team can ship new animations without rebuilding the system. This is what building for the terminal demands: deep understanding of constraints, discipline around accessibility, and the willingness to invent tooling where none exists. Use GitHub Copilot in your terminal The GitHub Copilot CLI brings AI-assisted workflows directly into your terminal — including commands for explaining code, generating files, refactoring, testing, and navigating unfamiliar projects. Try GitHub Copilot CLI > The post From pixels to characters: The engineering behind GitHub Copilot CLI’s animated ASCII banner appeared first on The GitHub Blog.
Year recap and future goals for the GitHub Innovation Graph
Discover the latest trends and insights on public software development activity on GitHub with data from the Innovation Graph through Q3 2025. The post Year recap and future goals for the GitHub Innovation Graph appeared first on The GitHub Blog.
Today’s data release marks our second full year of regular releases since the launch of the GitHub Innovation Graph. The Innovation Graph serves as a stable, regularly updated source for aggregated statistics on public software development activity around the world, informing public policy, strengthening research, guiding funding decisions, and equipping organizations with the evidence needed to build secure and resilient AI systems. Updated bar chart races With our new data release, we’ve updated the bar chart race videos to the git pushes, repositories, developers, and organizations global metrics pages. Let’s take a look back at some of the progress the Innovation Graph has helped drive. Academic papers One of the most rewarding aspects of the past year has been seeing the growing range of research questions addressed with Innovation Graph data. Recent papers have explored everything from global collaboration networks to the institutional foundations of digital capabilities. These studies showcase how network analysis techniques can be applied to Innovation Graph data, in addition to earlier work we referenced last year linking open source to economic value, innovation measurement, labor markets, and AI-driven productivity through other methodologies. Historical Institutions and Modern Digital Capabilities: New Evidence from GitHub in Africa Research by an economist at the Federal Reserve Board uses GitHub data to examine how the density of Protestant mission stations correlates with present-day participation in digital production across African countries. Olana, Deriba, “Historical Institutions and Modern Digital Capabilities: New Evidence from GitHub in Africa” (November 25, 2025). Available at SSRN: https://ssrn.com/abstract=5805622 or http://dx.doi.org/10.2139/ssrn.5805622. The Structure of Cross-National Collaboration in Open-Source Software Development Researchers from MIT, Carnegie Mellon, and the University of Chicago analyze international collaboration patterns in the Innovation Graph’s economy collaborators dataset, shedding light on how common colonial histories influence modern software development collaboration activities. Xu, Henry, et al. “The Structure of Cross-National Collaboration in Open-Source Software Development,” (November 10, 2025). Available at doi.org/10.1145/3746252.3761237. Replication package available at https://github.com/hehao98/github-innovation-graph. Small-World Phenomenon of Global Open-Source Software Collaboration on GitHub A social network analysis by researchers at Midwestern State University and Tarleton State University highlights the tightly connected, small-world structure of global OSS collaboration. Zhang, Guoying, et al. “Small-World Phenomenon of Global Open-Source Software Collaboration on Github: A Social Network Analysis.” Journal of Global Information Management Vol. 33, No. 1 (2025). Available at doi.org/10.4018/JGIM.387412. The Software Complexity of Nations These researchers extend countries’ software economic complexity into the digital economy by leveraging the geographic distribution of programming languages in open source software, showing that software economic complexity predicts GDP, income inequality, and emissions, which have important policy implications. Juhász, Sándor, et al. “The Software Complexity of Nations.” Research Policy Vol. 55, No. 3. Available at doi.org/10.1016/j.respol.2026.105422. Conferences The Innovation Graph and related GitHub datasets were featured prominently in academic and policy discussions at a wide range of venues, including: ATLC25: The 10th Atlanta Conference on Science and Innovation Policy OpenForum Academy Symposium 2025 2nd CEU Vienna Data Analytics Jamboree Wharton Human-AI Research: 3rd Annual Business & Generative AI Conference News publications We were also encouraged to see Innovation Graph data referenced in major international reporting. In 2025, two pieces in The Economist drew on GitHub data examining China’s approach to open technology (June 17, 2025) and India’s potential role as a distinctive kind of AI superpower (September 18, 2025). Coverage like this reinforces the role that data on open source activity can play in understanding geopolitical and economic shifts. Reports Once again, Innovation Graph data contributed to several flagship reports, including: The 2025 Stanford AI Index Report The 2025 WIPO Global Innovation Index The Rise of FOSS in India report from the National Law School of India University We continue to value these opportunities to support macro-level measurement efforts, and we’re equally excited by complementary work that dives deeper into regional, institutional, and community-level dynamics. Moving forward As we move through 2026, we’re grateful for the community that has formed around the Innovation Graph, and we’re looking forward to building the next chapter together. Our focus will be on deepening collaboration, welcoming new perspectives, and creating clearer pathways for people to apply the Innovation Graph data in their own contexts, from strategy and research to product development and policy. The post Year recap and future goals for the GitHub Innovation Graph appeared first on The GitHub Blog.
7 learnings from Anders Hejlsberg: The architect behind C# and TypeScript
Anders Hejlsberg shares lessons from C# and TypeScript on fast feedback loops, scaling software, open source visibility, and building tools that last. The post 7 learnings from Anders Hejlsberg: The architect behind C# and TypeScript appeared first on The GitHub Blog.
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 exactly like the old one, including quirks and edge cases. Rust, despite its popularity, would have required significant redesign due to ownership constraints and pervasive cyclic data structures. Go’s garbage collection and structural similarity made it possible to preserve behavior while unlocking performance and concurrency. The result was substantial performance gains, split between native execution and parallelism. More importantly, the community did not have to relearn the compiler’s behavior. Sometimes the most responsible choice isn’t the most ambitious one, but instead preserves behavior, minimizes disruption, and removes a hard limit that no amount of incremental optimization can overcome. In an AI-driven workflow, grounding matters more than generation Hejlberg is skeptical of the idea of AI-first programming languages. Models are best at languages they have already seen extensively, which naturally favors mainstream ecosystems like JavaScript, Python, and TypeScript. But AI does change things when it comes to tooling. The traditional IDE model assumed a developer writing code and using tools for assistance along the way. Increasingly, that relationship is reversing. AI systems generate code. Developers supervise and correct. Deterministic tools like type checkers and refactoring engines provide guardrails that prevent subtle errors. In that world, the value of tooling is not creativity. It is accuracy and constraint. Tools need to expose precise semantic information so that AI systems can ask meaningful questions and receive reliable answers. The risk is not that AI systems will generate bad code. Instead, it’s that they will generate plausible, confident code that lacks enough grounding in the realities of a codebase. For developers, this shifts where attention should go. The most valuable tools in an AI-assisted workflow aren’t the ones that generate the most code, but the ones that constrain it correctly. Strong type systems, reliable refactoring tools, and accurate semantic models become essential guardrails. They provide the structure that allows AI output to be reviewed, validated, and corrected efficiently instead of trusted blindly. Why open collaboration is critical Despite the challenges of funding and maintenance, Hejlberg remains optimistic about open collaboration. One reason is institutional memory. Years of discussion, decisions, and tradeoffs remain searchable and visible. That history does not disappear into private email threads or internal systems. It remains available to anyone who wants to understand how and why a system evolved. Despite the challenges of funding and maintenance, Hejlsberg remains optimistic about open collaboration. And a big reason is institutional memory. “We have 12 years of history captured in our project,” he explains. “If someone remembers that a discussion happened, we can usually find it. The context doesn’t disappear into email or private systems.” That visibility changes how systems evolve. Design debates, rejected ideas, and tradeoffs remain accessible long after individual decisions are made. For developers joining a project later, that shared context often matters as much as the code itself. A pattern that repeats across decades Across four decades of language design, the same themes recur: Fast feedback loops matter more than elegance Systems need to accommodate imperfect code written by many people Behavioral compatibility often matters more than architectural purity Visible tradeoffs build trust These aren’t secondary concerns. They’re fundamental decisions that determine whether a tool can adapt as its audience grows. Moreover, they ground innovation by ensuring new ideas can take root without breaking what already works. For anyone building tools they want to see endure, those fundamentals matter as much as any breakthrough feature. And that may be the most important lesson of all. Did you know TypeScript was the top language used in 2025? Read more in the Octoverse report > The post 7 learnings from Anders Hejlsberg: The architect behind C# and TypeScript appeared first on The GitHub Blog.
Help shape the future of open source in Europe
Read GitHub’s position on the European Open Digital Ecosystem Strategy and learn how to participate. The post Help shape the future of open source in Europe appeared first on The GitHub Blog.
At GitHub, we believe that open source is a primary driver of innovation, security, and economic competitiveness. The European Union is currently at a pivotal moment in defining how it supports this ecosystem, and it wants to hear from you, the builders. The European Commission is planning to adopt an open source strategy called “Towards European Open Digital Ecosystems“. This initiative is not about passing new laws; instead the EU is looking to develop a strategic framework and funding measures to help the EU open source sector scale up and become more competitive. This effort aims to strengthen the EU’s technological sovereignty by supporting open source software and hardware across critical sectors like AI, cloud computing, and cybersecurity. We’ve been advocating for this kind of support for a long time. For instance, we previously highlighted the need for a European Sovereign Tech Fund to invest in the maintenance of critical basic open source technologies such as libraries or programming languages. This new strategy is a chance to turn those kinds of ideas into official EU policy. You can read GitHub’s response to the European Commission here. Brand new data from GitHub Innovation Graph shows that the EU is a global open source powerhouse: There are now almost 25 million EU developers on GitHub, who made over 155 million contributions to public projects in the last year alone. The EU wants to help European companies turn open source projects into successful businesses, which is an admirable goal with plenty of opportunities to achieve it. For example, the EU can create better conditions for open source businesses by making it easier for them to participate in public procurement and access the growth capital they need to turn great code into sustainable products. By supporting the business models and infrastructure that surround it, the EU can turn its massive developer talent into long-term economic leadership. It is important to understand, though, that not all open source projects can be turned into commercial products—and that commercialization is not every developer’s goal. A successful EU open source policy should also support the long-term sustainability of non-commercially produced open source components that benefit us all. That is why the European Commission needs to hear the full spectrum of experiences from the community—from individual maintainers, startups, companies, and researchers. Over 900 people have already shared their views, and we encourage you to join them. The European Commission is specifically looking for responses covering these five topics: Strengths and weaknesses: What is standing in the way of open source adoption and sustainable open source contributions in the EU? Added value: How does open source benefit the public and private sectors? Concrete actions: What should the EU do to support open source? Priority areas: Which technologies (e.g., AI, IoT, or Cloud) should be the focus? Sector impact: In which industries (e.g., automotive or manufacturing) could open source increase competitiveness and cybersecurity? How to Participate The “Call for Evidence” is your opportunity to help shape the future tech policy of the EU. It only takes a few minutes to provide your perspective. Submit your feedback by February 3 (midnight CET). Your voice is essential to ensuring that the next generation of European digital policy is built with the needs of real developers in mind. At GitHub Developer Policy, we are always open to feedback from developers. Please do not hesitate to contact us as well. The post Help shape the future of open source in Europe appeared first on The GitHub Blog.
Power agentic workflows in your terminal with GitHub Copilot CLI
Explore the GitHub Copilot CLI and try interacting with Copilot directly from your terminal. The post Power agentic workflows in your terminal with GitHub Copilot CLI appeared first on The GitHub Blog.
Since GitHub Copilot CLI launched in public preview in September 2025, we’ve been shipping frequent regular updates and advancements. Below, we’ll show you what makes Copilot CLI so special, why it’s great to have an agentic AI assistant right in your terminal, and how we’re building the Copilot CLI to connect more broadly to the rest of the GitHub Copilot ecosystem. Note: This blog is based on a GitHub Universe 2025 presentation. Watch below to see the functionality in action. 👇 Bringing the CLI to where you work If you use GitHub Copilot in VS Code or in a similar IDE, consider how often you spend your entire working day in the IDE, trying to avoid doing anything in any other working environment. We kept this thought top of mind when we conceptualized the GitHub Copilot CLI. Developers spend time using ssh to connect to servers, debug things in containers, triage issues on github.com, manage CI/CD pipelines, and write deployment scripts. There’s a lot of work that doesn’t neatly map into an individual IDE or even a multipurpose code editor like VS Code. To make sure that we brought the GitHub CLI to developers where they already are, it made sense to go through the terminal. After all, the terminal transcends all the different applications on your computer and, in the right hands, is where you can accomplish any task with fine-grained control. Bringing GitHub Copilot into the CLI and giving it access to the broader GitHub ecosystem lets you spend more time getting your work done, and less time hunting down man pages and scouring through documentation to learn how to do something. Showcasing the GitHub CLI functionality Often, the first step with a project is getting up to speed on it. Let’s consider an example where you’re filling in for a friend on a project, but you don’t know anything about it—you don’t know the codebase, the language, or even the framework. You’ve received a request to update a feedback form because the UI elements are not laid out correctly. Specifically, the Submit Feedback button overlaps the form itself, obscuring some fields. Whoever submitted the bug included a screenshot showing the UI error. To get started, you can launch the GitHub CLI and ask it to clone the repository. Clone the feedback repo and set us up to run it After sending this prompt, Copilot will get you everything you need: It will reference the documentation associated with the repository and figure out any dependencies you need in order to successfully run it. It’s a fast way to get started, even if you’re not familiar with the dependencies required. Copilot will prompt you before running any commands to make sure that it has permission to do so. It will tell you what it’s doing and make sure that you authorize any commands before it runs them. Now let’s say that your repository is set up and you go to run the server, but you receive an error that the port is already in use. This can be a workflow killer. You know that there are commands you can run in the terminal to identify the process using the port and safely shut it down, but you might not remember the exact syntax to do so. To make this much easier, you can just hand the task over to Copilot. What is using port 3000? Without you needing to look up the commands, Copilot can determine the PID using the port. You can then either kill the process yourself or hand that task over to Copilot so you can focus on other tasks. Find and kill the process on port 3000 Continuing with our example, you now have the repository up and running and can verify the error with the Submit Feedback button. However, you don’t want to look through all of the code files to try and find what the bug might be. Why not have Copilot take a look first and see if it can identify any obvious issues? Copilot can analyze images, so you can use the image supplied in the bug report. Upload the screenshot showing the error to the repository, and ask Copilot if it has any ideas on how to fix the bug. Fix the big shown in @FIX-THIS.PNG Copilot will attempt to find and fix the issue, supplying a list of suggested changes. You can then review the changes and decide whether or not to have Copilot automatically apply the fixes. And we’re able to do all of this in the terminal thanks to the GitHub CLI. However, before uploading these changes to the repository, the team has very strict accessibility requirements. You might not be familiar with what these are, but in this example, the team has a custom agent that defines them. It has all the right MCP tools to check on the guardrails, so you can leverage the agent to do an accessibility review of any proposed changes. /agent This command provides a list of available custom agents, so you can select the appropriate one you want to use. Once you select the appropriate agent, simply ask it to look over the proposed changes. Review our changes This prompt sets the coding agent to work, looking at your changes. If it finds any issues, it will let you know and suggest updates to make sure your changes are aligned with its instructions. This can be immensely powerful with the appropriate agents to leverage to provide checks on your code. Finally, let’s say you want to know if there are any open issues that map to the work that you’ve done, but you don’t want to manually search through all of the open issues. Luckily, Copilot CLI ships with the GitHub MCP server, so you can look up anything on the GitHub repository without needing to manually go to github.com. Are there any open issues that map to the work we're doing? The GitHub MCP server will then go through and search through all of the issues and identify any that might match the work that you’ve addressed. If it pulls up issues that aren’t completely resolved by the work that you’ve done, you can still delegate this work to a coding agent so that you can continue working on whatever you’re focused on. /delegate Finish fixing the issue outlined in #1 and use the playright MCP server to ensure that it's fixed The /delegate command dispatches a coding agent to work on the task for you in the background while you turn your attention to other areas. It will open a pull request for future work that the coding agent performs. This is identical to the standard Copilot coding agent workflow—just started through GitHub Copilot CLI. Headless operation for scripting and automation GitHub Copilot CLI has even more functionality than what we’ve previously showcased. You can now perform tasks headlessly in the Copilot CLI. Remember the example where we talked about identifying and killing the process running on port 3000? You could do this through the CLI with the following command. copilot --allow-all-tools -p "Kill the process using port 3000" Copilot will then use the appropriate commands to identify and kill that process. While this is a simple example, you can think of more complex scenarios where you could hook this up into a script or actions workflow and reuse it over and over again. Note that this included the flag –allow-all-tools, which is probably not something you want to include in an actual environment unless you’re running in a container. Luckily, we provide several flags that you can pass to only allow access to certain directories and tools. You can even restrict Copilot from using specific commands, so you can guarantee that a human is always involved, such as with pushing up to a repository. To see a list of possible flags, run the following command. copilot --help You can authenticate interactively with a login command or by using a personal access token. This way, you can use this with automations. We’re also actively working on more authentication methods that are more enterprise friendly. Trying the Copilot CLI yourself We’re constantly shipping updates and are always looking for feedback from our users. We have several open issues and are tracking the items that customers want to see. If you want to see what we’re working on and provide feedback, check out our public GitHub Copilot CLI repository. And if you want to get started, it’s incredibly easy. It’s available for Windows (both WSL and natively in PowerShell), Mac OS, and Linux. We provide several platform-specific ways to install the CLI in the Copilot CLI README. Give it a try and come join the conversation on our public repository to help us build the best terminal-based AI system we possibly can. We look forward to hearing your feedback! Get started with GitHub Copilot CLI > The post Power agentic workflows in your terminal with GitHub Copilot CLI appeared first on The GitHub Blog.
Build an agent into any app with the GitHub Copilot SDK
Now in technical preview, the GitHub Copilot SDK can plan, invoke tools, edit files, and run commands as a programmable layer you can use in any application. The post Build an agent into any app with the GitHub Copilot SDK appeared first on The GitHub Blog.
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.
A cheat sheet to slash commands in GitHub Copilot CLI
Run tests, fix code, and get support—right in your workflow. Stay focused and let Copilot handle the busywork. The post A cheat sheet to slash commands in GitHub Copilot CLI appeared first on 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 example, here I am adding the Documents directory to the allowed list for file access: /add-dir /Users/jacklynlee31/Documents Copilot then gives me the following output: Added directory to allowed list: /Users/jacklynlee31/Documents /list-dirs: Show allowed directories. This command helps keep file access transparent. This can help with team compliance policies. When to use: Verifying Copilot’s scope Troubleshooting access issues Reviewing permissions before running commands /list-dirs After running the command, Copilot will show you the list of directories. For example: Allowed directories for file access: 1. /Users/jacklynlee31 2. /Users/jacklynlee31/Documents Total: 2 directories /cwd: Show or change the working directory. This keeps Copilot focused on the part of your codebase you’re actively working in. When to use: Navigating complex project trees Switching between repositories Narrowing context for better suggestions /cwd For example, after using the command, Copilot gave me the following output: Current working directory: /Users/jacklynlee31/Downloads When using /cwd [directory], you are able to switch to a different directory: /cwd /Users/jacklynlee31/Downloads Copilot will give you a similar output to show the new working directory path: Changed working directory to: /Users/jacklynlee31/Downloads Configuration commands /model: Select an AI model. Copilot supports multiple models, but you don’t need to overthink it. Start with the default model, then experiment when you notice differences in speed, reasoning depth, or cost. When to use: Comparing outputs Testing new or preview models Troubleshooting unexpected responses /model After running the command, Copilot will display an interactive model selection menu similar to the following: Choose the AI model to use for Copilot CLI. The selected model will be persisted and used for future sessions. ❯ 1. Claude Sonnet 4.5 (1x) (default) (current) 2. Claude Opus 4.5 (Preview) (1x) 3. Claude Haiku 4.5 (0.33x) 4. Claude Sonnet 4 (1x) 5. GPT-5.1 (1x) 6. GPT-5.1-Codex-Mini (0.33x) 7. GPT-5.1-Codex (1x) 8. GPT-5 (1x) 9. GPT-5-Mini (0x) 10. GPT-4.1 (0x) 11. Gemini 3 Pro (Preview) (1x) 12. Cancel (Esc) You can select a model from the list with the number or arrow keys and press Enter. You can also use /model [model] to directly change the AI model. /theme [show|set|list] [auto|dark|light]: Configure the terminal theme. Show: shows the current theme preference. Set: used to set the terminal theme to auto, dark, or light. List: shows a list of available themes. When to use: Improving readability Matching team or environment standards /theme set dark After setting the theme, Copilot will confirm your preference and prompt you to restart the CLI to apply the new theme: ● Theme preference set to: dark The new theme will be applied on the next restart of the CLI. /terminal-setup: Enable multiline inputs. This is especially helpful for complex instructions or multi step code changes. This command ensures your terminal is ready for advanced tasks and collaborative workflows. When to use: Writing longer prompts Performing large refactors or reviews Improving prompt formatting during large code edits /terminal-setup /reset-allowed-tools: Reset tool permissions. This command helps you quickly roll back the allowed tools set to a clean slate, removing obsolete or risky items. When to use: After team or role changes Cleaning up after demos or experiments /reset-allowed-tools After using the command, Copilot will show a confirmation: The list of allowed tools has been reset. External services commands /agent: Select a custom agent. Custom agents let you target specialized tasks or integrations. When to use: Switching agent configurations by repository/org/project Testing specialized or third-party agents /delegate <prompt>: Create an AI-generated pull request. This lets you automate changes and create pull requests without leaving the terminal. When to use: Applying changes across multiple repositories Kicking off reviewable work quickly For example, here I generated a pull request in my repository to add dark mode support: /delegate Add dark mode support /share [file|gist] [path]: Export your session. Documentation is critical—and this command lets you capture entire session histories to share or archive. When to use: Async handoffs Documenting decisions or experiments Attaching context to issues or pull requests /share file /Users/jacklynlee31/Desktop After sharing the file, Copilot will confirm that the session was shared successfully to your chosen location: ● Session shared successfully to: /Users/jacklynlee31/Desktop/copilot-session-221b5571-3998-47e1-b57a-552cf9078947.md /login, /logout: Log in or out of Copilot. When to use: Rotating credentials Switching accounts on a shared device /mcp [show|add|edit|delete|disable|enable]: Manage MCP configurations. Managing MCP server configuration directly from the terminal means you don’t have to switch between tools or interfaces. Show: show the list of available MCP servers. Add: add a new MCP server. Edit: edit an existing MCP server. Delete: delete a MCP server. Disable: disable a MCP server. Enable: enable a MCP server. /user [show|list|switch]: Manage what GitHub account you’re using. Multi-user and enterprise development often means switching between accounts. /user can help you with your role-based workflows and testing. When to use: Multi-user machines Managing service accounts vs. personal accounts Rotating between organizations /user show /user list /user switch /help: Show all available commands. When to use: Discovering new features Quick reference while using the CLI Bringing it all together With slash commands in Copilot CLI, you can make common workflow tasks fast and repeatable. You’re gaining explicit control over context, scope, and automation without leaving the terminal. The best way to experience this is to dive in and try slash commands yourself. Start with /clear, /cwd, and /help. Then layer in others as your workflows grow. As slash command capabilities grow, your feedback helps us shape what comes next. Use /feedback to share what’s working, and what isn’t. Quick reference Slash command What it does When to use /clear Clears session history/context Shift tasks, reset Copilot’s context, resolve confusion /exit, /quit Exits the Copilot session Finish a session, reset the CLI /session, /usage Shows current session and usage stats Audit activity, monitor Copilot CLI usage /add-dir <directory> Adds allowed directory for file access Limit scope, improve security/auditing /list-dirs Lists directories Copilot can access Confirm or manage file access permissions /cwd [directory] Changes/outputs the working directory Navigate projects, limit Copilot context /model [model] Changes Copilot AI model for the CLI Experiment, troubleshoot, optimize model behavior /theme [show|set|list] Manage terminal output theme Customize for environment or team standards /reset-allowed-tools Resets allowed external tools Remove tool permissions, reset for audits /agent Selects a custom Copilot agent When using specialized agents by repo/org /delegate <prompt> Delegates changes as a PR in a remote repository Automate changes, multi-repo workflows /share [file|gist] Shares session as markdown or GitHub Gist Document sessions, async handoff, team sharing /login, /logout Sign in/out of Copilot in the CLI Change user, rotate credentials /mcp [show|add|edit|...] MCP server configuration management Update CI/CD proxy config, enterprise setups /user [show|list|switch] GitHub user management Multi-user or team CLI management /help Lists all CLI commands and shortcuts Onboarding, discoverability /feedback Submit feedback about Copilot CLI Share suggestions or bug reports with GitHub Try Copilot slash commands in the GitHub CLI and speed up your workflow. Install Copilot CLI or read the docs to get started. Additional resources Copilot feature page Colpilot CLI Copilot Chat Cookbook The post A cheat sheet to slash commands in GitHub Copilot CLI appeared first on The GitHub Blog.