Updates, ideas, and inspiration from GitHub to help developers build and design software.
Agentic AI, MCP, and spec-driven development: Top blog posts of 2025
Explore the GitHub Blog’s top posts covering the biggest software development topics of the year. The post Agentic AI, MCP, and spec-driven development: Top blog posts of 2025 appeared first on The GitHub Blog.
As the editor of the GitHub Blog, I get a front-row seat to everything that’s published here. As we wrap up 2025, I’m marking the occasion by looking back at the most popular blog posts of the year as well as some of my favorite interviews. While AI models were the big topic of 2024, this year saw AI become your coding partner. AI agents and agentic tools were top among our most popular posts of the year. Below, you’ll find some of our biggest announcements of the year, plus some examples of how to use these features. Cozy up at your desk or on your couch, grab a blanket and a mug of coffee, and let’s dive in. Here’s what you read the most in 2025: Agent mode GitHub Copilot agent mode, announced in February, can iterate on its own code, recognize errors, and fix its mistakes in real time, right in your IDE. More simply, it’s a problem solver that understands your intent, builds a solution, and iterates until it gets it right. You also read all about it in our agent mode 101 guide. Here you can learn what agent mode is, how to use it, some common use cases, and how to get started. Coding agent In May, the GitHub Copilot coding agent was announced. Embedded directly into GitHub, the agent starts its work when you, for example, assign a GitHub issue to Copilot or prompt it in VS Code. Coding agent will explore the repository, write code, pass tests, and open a pull request for your review. Agent HQ Wrapping up a year of AI agents, during GitHub Universe in October, GitHub announced an ecosystem for all of your agents to work together. Agent HQ unites all of your agents on a single platform. Coding agents from Anthropic, OpenAI, Google, Cognition, xAI, and more became available directly within GitHub as part of your paid GitHub Copilot subscription. Most read tutorials of 2025 Looking for more ways to use GitHub Copilot? Check out these tutorials, the ones you read the most in 2025: How to write a great agents.md: Lessons from over 2,500 repositories Copilot ask, edit, and agent modes: What they do and when to use them 5 tips for writing better custom instructions for Copilot MCP Model Context Protocol (MCP) makes it simple for AI agents and tools to talk to each other. Each MCP server is like an ingredient in your AI stack, whether it’s Playwright for browser automation, Notion for knowledge access, or GitHub’s own MCP server with over a hundred tools. In April, we rolled out Agent Mode with MCP support to all VS Code users. In September, the GitHub MCP Registry launched as your new home base for discovering MCP servers, making it easier for you to build, evaluate, and even find the MCP servers you need. Spec-driven development Instead of coding first and writing docs later, in spec-driven development, you start with specifications, or specs. Specs become the shared source of truth. Spec Kit, our open source toolkit for spec-driven development, provides a structured process to bring spec-driven development to your coding agent workflows, making your specification the center of your engineering process. Conversations around the fire… Throughout the year, we brought you stories about people and projects shaping the industry. Here are some of my personal favorites and ones you can watch, read, or listen to as you curl up by the fire. 🎉 Did you know Git turned 20 this year? To celebrate, we sat down with Linus Torvalds, the creator of Git and Linux, to discuss how it forever changed software development. 🤖 It was the breach that broke the internet. Log4Shell proved that open source security isn’t guaranteed and isn’t just a code problem. Hear the untold story from Christian Grobmeier, one of the maintainers of the open source project Log4j. 🎧 Home Assistant became the most important project in so many houses. Hear about the paradox that makes Home Assistant compelling to developers from maintainer Franck Nijhof (better known as Frenck). See you in 2026! And that’s just scratching the surface! Explore the blog to see more exclusive interviews, career advice, open source highlights, and more of the tutorials you love from 2025. We’ll be here next year to share more. Stay tuned—we can’t wait for you to see what’s next! Stay connected in the New Year! Discover tips, technical guides, and best practices in our newsletter just for developers. Subscribe now > The post Agentic AI, MCP, and spec-driven development: Top blog posts of 2025 appeared first on The GitHub Blog.
Bugs that survive the heat of continuous fuzzing
Learn why some long-enrolled OSS-Fuzz projects still contain vulnerabilities and how you can find them. The post Bugs that survive the heat of continuous fuzzing appeared first on The GitHub Blog.
Even when a project has been intensively fuzzed for years, bugs can still survive. OSS-Fuzz is one of the most impactful security initiatives in open source. In collaboration with the OpenSSF Foundation, it has helped to find thousands of bugs in open-source software. Today, OSS-Fuzz fuzzes more than 1,300 open source projects at no cost to maintainers. However, continuous fuzzing is not a silver bullet. Even mature projects that have been enrolled for years can still contain serious vulnerabilities that go undetected. In the last year, as part of my role at GitHub Security Lab, I have audited popular projects and have discovered some interesting vulnerabilities. Below, I’ll show three open source projects that were enrolled in OSS-Fuzz for a long time and yet critical bugs survived for years. Together, they illustrate why fuzzing still requires active human oversight, and why improving coverage alone is often not enough. What is fuzz testing? Fuzz testing (or fuzzing) is an automated software testing technique that involves feeding a program random or mutated input values and monitoring it for exceptions or crashes. If you want to learn more on fuzzing, check out our fuzzing101 course. Check out the five step fuzzing workflow below > Gstreamer GStreamer is the default multimedia framework for the GNOME desktop environment. On Ubuntu, it’s used every time you open a multimedia file with Totem, access the metadata of a multimedia file, or even when generating thumbnails for multimedia files each time you open a folder. In December 2024, I discovered 29 new vulnerabilities, including several high-risk issues. To understand how 29 new vulnerabilities could be found in a software that has been continuously fuzzed for seven years, let’s have a look at the public OSS-Fuzz statistics available here. If we look at the GStreamer stats, we can see that it has only two active fuzzers and a code coverage of around 19%. By comparison, a heavily researched project like OpenSSL has 139 fuzzers (yes, 139 different fuzzers, that is not a typo). <img data-recalc-dims="1" loading="lazy" decoding="async" height="425" width="1024" src="https://github.blog/wp-content/uploads/2025/12/fuzz1.png?resize=1024%2C425" alt="Comparing OSS-Fuzz statistics for OpenSSL and GStreamer." class="wp-image-92977" srcset="https://github.blog/wp-content/uploads/2025/12/fuzz1.png?w=1526 1526w, https://github.blog/wp-content/uploads/2025/12/fuzz1.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/fuzz1.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/fuzz1.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> And the popular compression library bzip2 reports a code coverage of 93.03%, a number that is almost five times higher than GStreamer’s coverage. <img data-recalc-dims="1" loading="lazy" decoding="async" width="766" height="640" src="https://github.blog/wp-content/uploads/2025/12/fuzz2.png?resize=766%2C640" alt="OSS-Fuzz project statistics for the bzip2 compression library." class="wp-image-92978" srcset="https://github.blog/wp-content/uploads/2025/12/fuzz2.png?w=766 766w, https://github.blog/wp-content/uploads/2025/12/fuzz2.png?w=300 300w" sizes="auto, (max-width: 766px) 100vw, 766px" /> Even without being a fuzzing expert, we can guess that GStreamer’s numbers are not good at all. And this brings us to our first reason: OSS-Fuzz still requires human supervision to monitor project coverage and to write new fuzzers for uncovered code. We have good hope that AI agents could soon help us fill this gap, but until that happens, a human needs to keep doing it by hand. The other problem with OSS-Fuzz isn’t technical. It’s due to its users and the false sense of confidence they get once they enroll their projects. Many developers are not security experts, so for them, fuzzing is just another checkbox on their security to-do list. Once their project is “being fuzzed,” they might feel it is “protected by Google” and forget about it. Even if the project actually fails during the build stage and isn’t being fuzzed at all (which happens to more than one project in OSS-Fuzz). This shows that human security expertise is still required to maintain and support fuzzing for each enrolled project, and that doesn’t scale well with OSS-Fuzz’s success! Poppler Poppler is the default PDF parser library in Ubuntu. It’s the library used to render PDFs when you open them with Evince (the default document viewer in Ubuntu versions prior to 25.04) or Papers (the default document viewer for GNOME desktop and the default document viewer from newer Ubuntu releases). If we check Poppler stats in OSS-Fuzz, we can see it includes a total of 16 fuzzers and that its code coverage is around 60%. Those are quite solid numbers; maybe not at an excellent level, but certainly above average. That said, a few months ago, my colleague Kevin Backhouse published a 1-click RCE affecting Evince in Ubuntu. The victim only needs to open a malicious file for their machine to be compromised. The reason a vulnerability like this wasn’t found by OSS-Fuzz is a different one: external dependencies. Poppler relies on a good bunch of external dependencies: freetype, cairo, libpng… And based on the low coverage reported for these dependencies in the Fuzz Introspector database, we can safely say that they have not been instrumented by libFuzzer. As a result, the fuzzer receives no feedback from these libraries, meaning that many execution paths are never tested. <img data-recalc-dims="1" loading="lazy" decoding="async" width="547" height="644" src="https://github.blog/wp-content/uploads/2025/12/fuzz3.png?resize=547%2C644" alt="Coverage report table showing line coverage percentages for various Poppler dependencies." class="wp-image-92979" srcset="https://github.blog/wp-content/uploads/2025/12/fuzz3.png?w=547 547w, https://github.blog/wp-content/uploads/2025/12/fuzz3.png?w=255 255w" sizes="auto, (max-width: 547px) 100vw, 547px" /> But it gets even worse: Some of Evince’s default dependencies aren’t included in the OSS-Fuzz build at all. That’s the case with DjVuLibre, the library where I found the critical vulnerability that Kevin later exploited. DjVuLibre is a library that implements support for the DjVu document format, an open source alternative to PDF that was popular in the late 1990s and early 2000s for compressing scanned documents. It has become much less widely used since the standardization of the PDF format in 2008. The surprising thing is that while this dependency isn’t included among the libraries covered by OSS-Fuzz, it is shipped by default with Evince and Papers. So these programs were relying on a dependency that was “unfuzzed” and at the same time, installed on millions of systems by default. This is a clear example of how software is only as secure as the weakest dependency in its dependency graph. Exiv2 Exiv2 is a C++ library used to read, write, delete, and modify Exif, IPTC, XMP, and ICC metadata in images. It’s used by many mainstream projects such as GIMP and LibreOffice among others. Back in 2021, my teammate Kevin Backhouse helped improve the security of the Exiv2 project. Part of that work included enrolling Exiv2 in OSS-Fuzz for continuous fuzzing, which uncovered multiple vulnerabilities, like CVE-2024-39695, CVE-2024-24826, and CVE-2023-44398. Despite the fact that Exiv2 has been enrolled in OSS-Fuzz for more than three years, new vulnerabilities have still been reported by other vulnerability researchers, including CVE-2025-26623 and CVE-2025-54080. In that case, the reason is a very common scenario when fuzzing media formats: Researchers always tend to focus on the decoding part, since it is the most obviously exploitable attack surface, while the encoding side receives less attention. As a result, vulnerabilities in the encoding logic can remain unnoticed for years. From a regular user perspective, a vulnerability in an encoding function may not seem particularly dangerous. However, these libraries are often used in many background workflows (such as thumbnail generation, file conversions, cloud processing pipelines, or automated media handling) where an encoding vulnerability can be more critical. The five-step fuzzing workflow At this point it’s clear that fuzzing is not a magic solution that will protect you from everything. To assure minimum quality, we need to follow some criteria. In this section, you’ll find the fuzzing workflow I’ve been using with very positive results in the last year: the five-step fuzzing workflow (preparation – coverage – context – value – triaging). <img data-recalc-dims="1" loading="lazy" decoding="async" height="164" width="1024" src="https://github.blog/wp-content/uploads/2025/12/fuzz4.png?resize=1024%2C164" alt="Five-step fuzzing workflow diagram. (preparation - coverage - context - value - triaging)" class="wp-image-92980" srcset="https://github.blog/wp-content/uploads/2025/12/fuzz4.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/fuzz4.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/fuzz4.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/fuzz4.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/fuzz4.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Step 1: Code preparation This step involves applying all the necessary changes to the target code to optimize fuzzing results. These changes include, among others: Removing checksums Reducing randomness Dropping unnecessary delays Signal handling If you want to learn more about this step, check out this blog post. Step 2: Improving code coverage From the previous examples, it is clear that if we want to improve our fuzzing results, the first thing we need to do is to improve the code coverage as much as possible. In my case, the workflow is usually an iterative process that looks like this: Run the fuzzers > Check the coverage > Improve the coverage > Run the fuzzers > Check the coverage > Improve the coverage > … The “check the coverage” stage is a manual step where i look over the LCOV report for uncovered code areas and the “improve the coverage” stage is usually one of the following: Writing new fuzzing harnesses to hit new code that would otherwise be impossible to hit Creating new input cases to trigger corner cases For an automated, AI-powered way of improving code coverage, I invite you to check out the Plunger module in my FRFuzz framework. FRFuzz is an ongoing project I’m working on to address some of the caveats in the fuzzing workflow. I will provide more details about FRFuzz in a future blog post. Another question we can ask ourselves is: “When can we stop increasing code coverage?” In other words, when can we say the coverage is good enough to move on to the next steps? Based on my experience fuzzing many different projects, I can say that this number should be >90%. In fact, I always try to reach that level of coverage before trying other strategies, or even before enabling detection tools like ASAN or UBSAN. To reach this level of coverage, you will need to fuzz not only the most obvious attack vectors such as decoding/demuxing functions, socket-receivers, or file-reading routines, but also the less obvious ones like encoders/muxers, socket-senders, and file-writing functions. You will also need to use advanced fuzzing techniques like: Fault injection: A technique where we intentionally introduce unexpected conditions (corrupted data, missing resources, or failed system calls) to see how the program behaves. So instead of waiting for real failures, we simulate these failures during fuzzing. This helps us to uncover bugs in execution paths that are rarely executed, such as: Failed memory allocations (malloc returning NULL) Interrupted or partial reads/writes Missing files or unavailable devices Timeouts or aborted network connections A good example of fault injection is the Linux kernel Fault injection framework Snapshot fuzzing: Snapshot fuzzing takes a snapshot of the program at any interesting state, so the fuzzer can then restore this snapshot before each test case. This is especially useful for stateful programs (operating systems, network services, or virtual machines). Examples include the QEMU mode of AFL++ and the AFL++ Nyx mode. Step 3: Improving context-sensitive coverage By default, the most common fuzzers (aka AFL++, libfuzzer, and honggfuzz) track the code coverage at the edge level. We can define an “edge” as a transition between two basic blocks in the control-flow graph. So if execution goes from block A to block B, the fuzzer records the edge A → B as “covered.” For each input the fuzzer runs, it updates a bitmap structure marking which edges were executed as a 0 or 1 value (currently implemented as a byte in most fuzzers). In the following example, you can see a code snippet on the left and its corresponding control-flow graph on the right: <img data-recalc-dims="1" loading="lazy" decoding="async" height="608" width="1024" src="https://github.blog/wp-content/uploads/2025/12/fuzz5.png?resize=1024%2C608" alt="Edge coverage explanation." class="wp-image-92981" srcset="https://github.blog/wp-content/uploads/2025/12/fuzz5.png?w=1353 1353w, https://github.blog/wp-content/uploads/2025/12/fuzz5.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/fuzz5.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/fuzz5.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Edge coverage = { (0,1), (0,2), (1,2), (2,3), (2,4), (3,6), (4,5), (4,6), (5,4) } Each numbered circle corresponds to a basic block, and the graph shows how those blocks connect and which branches may be taken depending on the input. This approach to code coverage has demonstrated to be very powerful given its simplicity and efficiency. However, edge coverage has a big limitation: It doesn’t track the order in which blocks are executed. So imagine you’re fuzzing a program built around a plugin pipeline, where each plugin reads and modifies some global variables. Different execution orders can lead to very different program states, while the edge coverage can still look identical. Since the fuzzer thinks it has already explored all the paths, the coverage-guided feedback won’t keep guiding it, and the chances of finding new bugs will drop. To address this, we can make use of context-sensitive coverage. Context-sensitive coverage not only tracks which edges were executed, but it also tracks what code was executed right before the current edge. For example, AFL++ implements two different options for context-sensitive coverage: Context- sensitive branch coverage: In this approach, every function gets its own unique ID. When an edge is executed, the fuzzer takes the IDs from the current call stack, hashes them together with the edge’s identifier, and records the combined value. You can find more information on AFL++ implementation here N-Gram Branch Coverage: In this technique, the fuzzer combines the current location with the previous N locations to create a context-augmented coverage entry. For example: 1-Gram coverage: looks at only the previous location 2-Gram coverage: considers the previous two locations 4-Gram coverage: considers the previous four You can see how to configure it in AFL++ here In contrast to edge coverage, it’s not realistic to aim for a coverage >90% when using context-sensitive coverage. The final number will depend on the project’s architecture and on how deep into the call stack we decide to track. But based on my experience, anything above 60% can be considered a very good result for context-sensitive coverage. Step 4: Improving value coverage To explain this section, I’m going to start with an example. Take a look at the following web server code snippet: <img data-recalc-dims="1" loading="lazy" decoding="async" height="165" width="1024" src="https://github.blog/wp-content/uploads/2025/12/fuzz6.png?resize=1024%2C165" alt="Example of a simple webserver code snippet." class="wp-image-92982" srcset="https://github.blog/wp-content/uploads/2025/12/fuzz6.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/fuzz6.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/fuzz6.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/fuzz6.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/fuzz6.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Here we can see that the function unicode_frame_size has been executed 1910 times. After all those executions, the fuzzer didn’t find any bugs. It looks pretty secure, right? However, there is an obvious div-by-zero bug when r.padding == FRAME_SIZE * 2: <img data-recalc-dims="1" loading="lazy" decoding="async" height="184" width="1024" src="https://github.blog/wp-content/uploads/2025/12/fuzz7.png?resize=1024%2C184" alt="Simple div-by-zero vulnerability." class="wp-image-92983" srcset="https://github.blog/wp-content/uploads/2025/12/fuzz7.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/fuzz7.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/fuzz7.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/fuzz7.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/fuzz7.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Since the padding is a client-controlled field, an attacker could trigger a DoS in the webserver, sending a request with a padding size of exactly 2156 * 2 = 4312 bytes. Pretty annoying that after 1910 iterations the fuzzer didn’t find this vulnerability, don’t you think? Now we can conclude that even having 100% code coverage is not enough to guarantee that a code snippet is free of bugs. So how do we find these types of bugs? And my answer is: Value Coverage. We can define value coverage as the coverage of values a variable can take. Or in other words, the fuzzer will now be guided by variable value ranges, not just by control-flow paths. If, in our earlier example, the fuzzer had value-covered the variable r.padding, it could have reached the value 4312 and in turn, detected the divide-by-zero bug. So, how can we make the fuzzer to transform variable values in different execution paths? The first naive implementation that came to my mind was the following one: inline uint32_t value_coverage(uint32_t num) { uint32_t no_optimize = 0; if (num < UINT_MAX / 2) { no_optimize += 1; if(num < UINT_MAX / 4){ no_optimize += 2; ... }else{ no_optimize += 3 ... } }else{ no_optimize += 4; if(num < (UINT_MAX / 4) * 3){ no_optimize += 5; ... }else{ no_optimize += 6; ... } } return no_optimize; } In this code, I implemented a function that maps different values of the variable num to different execution paths. Notice the no_optimize variable to avoid the compiler from optimizing away some of the function’s execution paths. After that, we just need to call the function for the variable we want to value-cover like this: static volatile uint32_t vc_noopt; uint32_t webserver::unicode_frame_size(const HttpRequest& r) { //A Unicode character requires two bytes vc_noopt = value_coverage(r.padding); //VALUE_COVERAGE uint32_t size = r.content_length / (FRAME_SIZE * 2 - r.padding); return size; } Given the huge number of execution paths this can generate, you should only apply it to certain variables that we consider “strategic.” By strategic, I mean those variables that can be directly controlled by the input and that are involved in critical operations. As you can imagine, selecting the right variables is not easy and it mostly comes down to the developers and researchers experience. The other option we have to reduce the total number of execution paths is by using the concept of “buckets”: Instead of testing all 2^32 possible values of a 32 bits integer, we can group those values into buckets, where each bucket transforms into a single execution path. With this strategy, we don’t need to test every single value and can still achieve good results. These buckets also don’t need to be symmetrically distributed across the full range. We can emphasize certain subranges by creating smaller buckets or, create bigger buckets for ranges we are not so interested in. Now that I’ve explained the strategy, let’s take a look at what real-world options we have to get value coverage in our fuzzers: AFL++ CmpLog / Clang trace-cmp: These focus on tracing comparison values (values used in calls to ==, memcmp, etc.). They wouldn’t help us find our divide-by-zero bug, since they only track values used in comparison instructions. Clang trace-div + libFuzzer -use_value_profile=1: This one would work in our example, since it traces values involved in divisions. But it doesn’t give us variable-level granularity, so we can only limit its scope by source file or function, not by specific variable. That limits our ability to target only the “strategic” variables. To overcome these problems with value coverage, I wrote my own custom implementation using the LLVM FunctionPass functionality. You can find more details about my implementation by checking the FRFuzz code here. The last mile: almost undetectable bugs Even when you make use of all up-to-date fuzzing resources, some bugs can still survive the fuzzing stage. Below are two scenarios that are especially hard to tackle with fuzzing. Big input cases These are vulnerabilities that require very large inputs to be triggered (on the order of megabytes or even gigabytes). There are two main reasons they are difficult to find through fuzzing: Most fuzzers cap the maximum input size (for example 1 MB in the case of AFL), because larger inputs lead to longer execution times and lower overall efficiency. The total possible input space is exponential: O(256ⁿ), where n is the size in bytes of the input data. Even when coverage-guided fuzzers use heuristic approaches to tackle this problem, fuzzing is still considered a sub-exponential problem, with respect to input size. So the probability of finding a bug decreases rapidly as the input size grows. For example, CVE-2022-40303 is an integer overflow bug affecting libxml2 that requires an input larger than 2GB to be triggered. Bugs that require “extra time” to be triggered These are vulnerabilities that can’t be triggered within the typical per-execution time limit used by fuzzers. Keep in mind that fuzzers aim to be as fast as possible, often executing hundreds or thousands of test cases per second. In practice, this means per-execution time limits on the order of 1–10 milliseconds, which is far too short for some classes of bugs. As an example, my colleague Kevin Backhouse found a vulnerability in the Poppler code that fits well in this category: the vulnerability is a reference-count overflow that can lead to a use-after-free vulnerability. Reference counting is a way to track how many times a pointer is referenced, helping prevent vulnerabilities such as use-after-free or double-free. You can think of it as a semi-manual form of garbage collection. In this case, the problem was that these counters were implemented as 32-bit integers. If an attacker can increment the counter up to 2^32 times, it will wrap the value back to 0 and then trigger a use-after-free in the code. Kevin wrote a proof of concept that demonstrated how to trigger this vulnerability. The only problem is that it turned out to be quite slow, making exploitation unrealistic: The PoC took 12 hours to finish. That’s an extreme example of a bug that needs “extra time” to manifest, but many vulnerabilities require at least seconds of execution to trigger. Even that is already beyond the typical limits of existing fuzzers, which usually set per-execution timeouts well under one second. That’s why finding vulnerabilities that require seconds to trigger is almost a chimera for fuzzers. And this effectively discards a lot of real-world exploitation scenarios from what fuzzers can find. It’s important to note that although fuzzer timeouts frequently turn out to be false alarms, it’s still a good idea to inspect them. Occasionally they expose real performance-related DoS bugs, such as quadratic loops. How to proceed in these cases? I would like to be able to give you a how-to guide on how to proceed in these scenarios. But the reality is we don’t have effective fuzzing strategies for these case corners yet. At the moment, mainstream fuzzers are not able to catch these kinds of vulnerabilities. To find them, we usually have to turn to other approaches: static analysis, concolic (symbolic + concrete) testing, or even the old-fashioned (but still very profitable) method of manual code review. Conclusion Despite the fact that fuzzing is one of the most powerful options we have for finding bugs in complex software, it’s not a fire-and-forget solution. Continuous fuzzing can identify vulnerabilities, but it can also fail to detect some attack vectors. Without human-driven work, entire classes of bugs have survived years of continuous fuzzing in popular and crucial projects. This was evident in the three OSS-Fuzz examples above. I proposed a five-step fuzzing workflow that goes further than just code coverage, covering also context-sensitive coverage and value coverage. This workflow aims to be a practical roadmap to ensure your fuzzing efforts go beyond the basics, so you’ll be able to find more elusive vulnerabilities. If you’re starting with open source fuzzing, I hope this blog post helped you better understand current fuzzing gaps and how to improve your fuzzing workflows. And if you’re already familiar with fuzzing, I hope it gives you new ideas to push your research further and uncover bugs that traditional approaches tend to miss. Want to learn how to start fuzzing? Check out our Fuzzing 101 course at gh.io/fuzzing101 > The post Bugs that survive the heat of continuous fuzzing appeared first on The GitHub Blog.
WRAP up your backlog with GitHub Copilot coding agent
An easy-to-remember acronym, WRAP will help you write effective issues, refine your instructions, and get the most out of Copilot coding agent. The post WRAP up your backlog with GitHub Copilot coding agent appeared first on The GitHub Blog.
Engineers at GitHub have been using GitHub Copilot coding agent for over a year now, studying through experience where it can help save developers real time and energy. Through our work, we have developed a handy acronym: WRAP, which stands for: W – Write effective issues R – Refine your instructions A – Atomic tasks P – Pair with the coding agent WRAP will help you get the most out of coding agent. For example, you likely have a backlog full of issues that have been tough to prioritize. Perhaps you’ve had to push off some tech debt improvements in favor of shipping a new feature. Or perhaps your development time has been split between fixing customer bugs and larger passion projects. WRAP can help you quickly get up to speed, using coding agent to tackle tasks that you may not have had time for in the past. Write effective issues The first step of WRAP is to make sure you are writing effective issues to assign to GitHub Copilot coding agent. In essence, you are trying to set coding agent up for success by adding context for the agent, just like you would for a new team member. Here are a set of guidelines you should consider: Write an issue as though it’s for someone brand new to the codebase. If you consider what context a newcomer might need, you’re likely to include enough context for the coding agent to complete the task effectively. Craft a descriptive title that explains where the work is being done. One of the best things about the coding agent is that you can assign it as many tasks as you want. But assigning many tasks means you might be juggling a lot of pull request reviews! Make sure your issue title clearly describes the nature of your work and where it occurs so you can keep your agent panel easy to navigate. Add examples of what you want. If you already know what you’d like the coding agent to implement, such as a specific error-handling pattern, include an example in the issue! This additional context will make it much more likely that you’ll get the output you want. Here are some example issues to get started: Instead of: > Update the entire repository to use async/await Do something like: > Update the authentication middleware to use the newer async/await pattern, as shown in the example below. Add unit tests for verification of this work, ensuring edge cases are considered. > async function exampleFunction() { let result = await promise; console.log(result); //”done!” } Refine your instructions The next step of WRAP is to make sure that you refine the GitHub Copilot custom instructions to improve the results of your coding agent-created pull requests. There are a variety of different custom instructions that you can create, as well as a variety of different cases where it makes sense to use them. Repository custom instructions. This is a great place to store any information that might be applicable to your repository as a whole. For example, if you have a Go application and prefer specific ways of writing Go code, that should go in your repository custom instructions. Adding to these instructions over time will improve all the responses from any interactions with GitHub Copilot in that repository. Here’s a guide on how to get started adding these repository custom instructions. Note: This is a great first use case for GitHub Copilot coding agent! Try asking it to generate custom repository instructions for your repository. Organization custom instructions. Much like how you can create a set of GitHub Copilot custom instructions for an entire repository, you can also create a set of GitHub Copilot custom instructions for your entire organization. This is ideal for anything that applies to all repositories in your organization. For example, you may have requirements around tests that should be created for all applications. Here’s a guide on how to get started adding organization custom instructions. Coding agent custom agents. Similar to the repository and organization custom instructions, coding agent custom agents can be created with a natural language text file, and are applicable at either the enterprise, organization, or repository level. These are ideal for any repetitive development task that may occur often, but may not be applicable to every single set of changes. For example, you can create an “Integration Agent” for integrating new products with a specific repository. Here’s a guide on how to get started creating custom agents. Atomic tasks Coding agent is very good at handling small, atomic, and well-defined tasks. However, it can also be useful for large problems! If you want it to handle a larger problem, the trick is to break that large problem down into multiple, independent, smaller tasks. For example, you wouldn’t necessarily want to assign an issue to GitHub Copilot asking it to “Rewrite 3 million lines of code from Java to Golang.” That would probably be too large of a scope for a specific task, and reviewing those changes would likely be pretty painful. Instead, you could break that larger problem into smaller issues for Copilot to tackle: Migrate the authentication module to Golang, ensuring all existing unit tests pass. Convert the data validation utilities package to Golang while maintaining the same API interface. Rewrite the user management controllers to Golang, preserving existing REST endpoints and responses. By breaking that large problem into smaller atomic tasks, it will be much easier to test and validate the individual parts of the work and much easier to review the individual pull requests. Pair with coding agent When working with coding agent, it’s important to remember its strengths as a coding agent and your strengths as a human. This will lead to less frustrating experiences down the line if coding agent doesn’t perform like you might want or expect it to. For example, humans are very good at the following: Understanding the “Why:” Humans are great at knowing why a task was created. They can also determine whether the changes to a task will actually solve the underlying problem that caused the issue to be created in the first place. Navigating ambiguity: Humans are much better at navigating ambiguity than AI. For example, as a human, you might be able to omit some parts of an issue that you wouldn’t be able to omit for GitHub Copilot to complete it, such as what sorts of tests and telemetry you expect to be done. Cross-system thinking: Humans are much better at thinking about the implications of changes made in one system on another system. When coding agent completes a particular task in one repository, it’s unlikely to know about how that task will impact other repositories. Considering cross-system implications is a much better task for humans than for GitHub Copilot. On the other hand, coding agent is very good at the following: Tireless execution: You can assign ten different tasks to coding agent right now and expect it to work on each of them. Repetitive tasks: Humans often get bored or miss things when doing repetitive tasks, such as updating naming conventions across many files. GitHub Copilot is great for completing these things, though! Exploring possibilities: If you’re considering tackling a problem a couple of different ways, you can assign each one of those different ways to coding agent. This gives you a quick idea of how each of those strategies might play out, without using a lot of development resources.ij Take this with you Lingering backlog issues no longer stand a chance when you are equipped with GitHub Copilot and WRAP. Have a dependency that needs to be updated? Somewhere that you could use more test coverage? New error handling patterns that you’d like to adopt across your codebase? Or perhaps you’d like to get a jumpstart on adding repository instructions and use the GitHub Copilot coding agent to do so? Use WRAP to wrap up your backlog! Get started with GitHub Copilot > The post WRAP up your backlog with GitHub Copilot coding agent appeared first on The GitHub Blog.
Strengthening supply chain security: Preparing for the next malware campaign
Security advice for users and maintainers to help reduce the impact of the next supply chain malware attack. The post Strengthening supply chain security: Preparing for the next malware campaign appeared first on The GitHub Blog.
The open source ecosystem continues to face organized, adaptive supply chain threats that spread through compromised credentials and malicious package lifecycle scripts. The most recent example is the multi-wave Shai-Hulud campaign. While individual incidents differ in their mechanics and speed, the pattern is consistent: Adversaries learn quickly, target maintainer workflows, and exploit trust boundaries in publication pipelines. This post distills durable lessons and actions to help maintainers and organizations harden their systems and prepare for the next campaign, not just respond to the last one. We also share more about what’s next on the npm security roadmap over the next two quarters. Recent Shai-Hulud Campaigns Shai-Hulud is a coordinated, multi-wave campaign targeting the JavaScript supply chain and evolved from opportunistic compromises to engineered, targeted attacks. The first wave focused on abusing compromised maintainer accounts. It injected malicious post install scripts to slip malicious code into packages, exfiltrate secrets, and self-replicate, demonstrating how quickly a single foothold can ripple across dependencies. The second wave, referred to as Shai-Hulud 2.0, escalated the threat: Its ability to self-replicate and spread via compromised credentials was updated to enable cross-victim credential exposure. The second wave also introduced endpoint command and control via self-hosted runner registration, harvesting a wider range of secrets to fuel further propagation, and destructive functionality. This wave added a focus on CI environments, changing its behavior when it detects it is running in this context and including privilege escalation techniques targeted to certain build agents. It also used a multi-stage payload that was harder to detect than the previous wave payload. The shortened timeline between variants signals an organized adversary studying community defenses and rapidly iterating around them. Rather than isolated breaches, the Shai-Hulud campaigns target trust boundaries in maintainer workflows and CI publication pipelines, with a focus on credential harvesting and install-time execution. The defining characteristics we see across waves include: Credential-adjacent compromise: Attackers gain initial footholds via compromised credentials or OAuth tokens, then pivot to collect additional secrets (npm tokens, CI tokens, cloud credentials) to expand reach. This enables reuse across organizations and future waves without a single point of failure. Install-time execution with obfuscation: Malicious post-install or lifecycle scripts are injected into packages (or dependency chains) and only reveal behavior at runtime. Payloads are often conditionally activated (e.g., environment checks, org scopes) and exfiltrate data using techniques tailored to the environment it is running in. Targeting trusted namespaces and internal package names: The campaign affected popular and trusted packages, and the worm published infected packages with existing package names. The second wave also patched the version number of the package to make the infected packages look like legitimate updates and blend in with normal maintainer activity. Rapid iteration and engineering around defenses: Short intervals between variants and deliberate changes to bypass previous mitigations indicate an organized campaign mindset. The goal is durable access and scalable spread, not one-off opportunism. Review blind spots in publication pipelines: Differences between source and published artifacts, lifecycle scripts, and build-time transformations create gaps where injected behavior can land without notice if teams lack artifact validation or staged approvals. Recent waves in this pattern reinforce that defenders should harden publication models and credential flows proactively, rather than tailoring mitigations to any single variant. What’s Next for npm We’re accelerating our security roadmap to address the evolving threat landscape. Moving forward, our immediate focus is on adding support for: Bulk OIDC onboarding: Streamlined tooling to help organizations migrate hundreds of packages to trusted publishing at scale. Expanded OIDC provider support: Adding support for additional CI providers beyond GitHub Actions and GitLab. Staged publishing: A new publication model that gives maintainers a review period before packages go live, with MFA-verified approval from package owners. This empowers teams to catch unintended changes before they reach downstream users—a capability the community has been requesting for years. Together, these investments give maintainers stronger, more flexible tools to secure their packages at every stage of the publication process. Advice for GitHub and npm users and maintainers Malware like Shai-Hulud often spreads by adding malicious code to npm packages. The malicious code is executed as part of the installation of the package so that any npm user who installs the package is compromised. The malware scavenges the local system for tokens, which it can then use to continue propagating. Since npm packages often have many dependencies, by adding malware to one package, the attacker can indirectly infect many other packages. And by hoarding some of the scavenged tokens rather than using them immediately, the attacker can launch a new campaign weeks or months after the initial compromise. In the “References” section below, we have included links to longer articles with analysis of recent campaigns and advice on how to stay secure, so we won’t rehash all of that information here. Instead, here is a short summary of our top recommendations: Advice for everyone Enable phishing-resistant MFA on all your accounts, particularly for GitHub package managers like npm, PyPI, RubyGems, or NuGet, and also any accounts that could be leveraged for account takeover or phishing, like email and social media accounts. Always set an expiration date on tokens to ensure that they’re rotated on a regular schedule. Organizations can enforce a maximum lifetime policy. Audit and revoke access for unused GitHub/OAuth apps. Use a sandbox, such as GitHub Codespaces or a virtual machine or container, for development work. This limits the access of any malware that you accidentally run. Advice for maintainers Enable branch protection so that malicious updates cannot be pushed directly to your main branch, even if the attacker has access to a valid token. Use npm trusted publishing instead of tokens. Trusted publishing is also available for other package managers such as PyPI, RubyGems, and NuGet. Pin CI dependencies, enable code scanning, and don’t forget to resolve the code scanning alerts! Monitor package artifacts and validate published tarballs/bundles against source (e.g., SRI or artifact build attestations). Note that the above advice is preventative. If you believe you are a victim of an attack and need help securing your GitHub or npm account, please contact GitHub Support. References Report a malicious package in npm Our plan for a more secure npm supply chain Strengthening npm security View malware advisories in the Advisory Database Quickstart for securing your repository Dependency review on GitHub OpenSSF best practices for npm Microsoft’s guidance for detecting and defending Recent improvements to GitHub Actions The post Strengthening supply chain security: Preparing for the next malware campaign appeared first on The GitHub Blog.
5 podcast episodes to help you build with confidence in 2026
Looking ahead to the New Year? These GitHub Podcast episodes help you cut through the noise and build with more confidence across AI, open source, and developer tools. The post 5 podcast episodes to help you build with confidence in 2026 appeared first on The GitHub Blog.
The end of the year creates a rare kind of quiet. It is the kind that makes it easier to reflect on how you have been building, what you have been learning, and what you want to do differently next year. It is also the perfect moment to catch up on the mountain of browser tabs you’ve kept open and podcast episodes you’ve bookmarked. Speaking of podcasts, we have one! (Wow, smooth transition, Cassidy). If you’re looking to level-up your thinking around AI, open source software sustainability, and the future of software, we have some great conversations you can take on the road with you. This year on the GitHub Podcast, we talked with maintainers, educators, data experts, and builders across the open source ecosystem. These conversations were not just about trends or tools. They offered practical ways to think more clearly about where software is headed and how to grow alongside it. If 2026 is about building with more intention, these five episodes are a great place to start. Understand where AI tooling is actually heading If this year left you feeling overwhelmed by the pace of change in AI tooling, you are not alone. New models, new agents, and new workflows seemed to appear every week, often without much clarity on how they fit together or which ones would actually last. Our Unlocking the power of MCP episode slows things down. It introduces the Model Context Protocol (MCP) as a way to make sense of that chaos, explaining how an open standard can help AI systems interact with tools in consistent and transparent ways. Rather than adding to the noise, the conversation gives you a clearer mental model for how modern AI tools are being built and why open standards matter for trust, interoperability, and long-term flexibility. Most importantly, MCP makes building better for everyone. Learn about how the standard works (and you can check out GitHub’s open sourced MCP server, too). Ship smaller, smarter software—faster Not every meaningful piece of software needs a pitch deck or a product roadmap. Building tools and the future of DIY development explores a growing shift toward personal, purpose-built tools. These are tools created to solve one specific problem well, often by the people who feel that pain most acutely. Developers and non-developers alike are really empowered these days by open source and AI tools, because they’re enabled to build faster and with less mental overhead. It is a great reminder that modern tooling and AI have lowered the barrier to turning ideas into working software, without stripping away creativity or craftsmanship. After listening to this one, you might just pick up that unused domain name and make something! 😉 Understand what keeps open source sustainable If you were around the tech scene in 2021, you probably remember the absolute chaos that came with the Log4Shell vulnerability that was exposed in November that year. That vulnerability (and others since then) put a spotlight on the world’s dependence on underfunded open source infrastructure. But, money can’t solve all of the world’s problems, unfortunately. From Log4Shell to the Sovereign Tech Fund is a really interesting conversation about why success is not just about funding, but also community health, processes, and communication. By the end, you come away with a deeper appreciation for the invisible labor behind the tools you rely on, and a clearer sense of how individuals, companies, and governments can show up more responsibly. Align your skills with real-world trends 2025 really has been the year of growth and change across projects. The Octoverse report analyzes the state of open source across 1.12 billion open source contributions, 518 million merged pull requests, 180 million developers… you get the idea, a lot of numbers and a lot of data. TypeScript’s Takeover, AI’s Lift-Off: Inside the 2025 Octoverse Report grounds the conversation in data from GitHub’s Octoverse report, turning billions of contributions into meaningful signals. The discussion helps connect trends like TypeScript’s rise, AI-assisted workflows, and even COBOL’s unexpected resurgence to real decisions developers face: what to learn next, where to invest time, and how to stay adaptable. Rather than predicting the future, it offers something more useful: a clearer picture of the present and how to navigate what comes next. Understand what privacy-first software looks like in practice As more everyday devices become connected, it is getting harder to tell where convenience ends and control begins. This episode offers a refreshing counterpoint. Recorded live at GitHub Universe 2025, the conversation with Frank “Frenck” Nijhof explores how Home Assistant has grown into one of the most active open source projects in the world by prioritizing local control, privacy, and long-term sustainability. Listening to Privacy-First Smart Homes with Frenck from Home Assistant shifts how you think about automation and ownership. You hear how millions of households run smart homes without relying on the cloud, why the Open Home Foundation exists to fight vendor lock-in and e-waste, and how a welcoming community scaled to more than 21,000 contributors. The discussion also opens up what contribution can look like beyond writing code, showing how documentation, testing, and community support play a critical role. It is a reminder that building better technology often starts with clearer values and more inclusive ways to participate. Plus, you get to hear about the weird and wonderful ways people use Home Assistant to power their lives. Take this with you As we look toward 2026, these episodes share a common thread. They encourage building with clarity, curiosity, and care for your tools, your community, and yourself. Whether you are listening while traveling, winding down for the year, or planning what you want to focus on next, we hope these conversations help you start the year feeling more grounded and inspired. And if you speed through these episodes, don’t worry; we have so many more fantastic episodes from this season. You can listen to every episode of the GitHub Podcast wherever you get your podcasts, or watch them on YouTube. We are excited to see what you build in 2026. Subscribe to the GitHub Podcast > The post 5 podcast episodes to help you build with confidence in 2026 appeared first on The GitHub Blog.
This year’s most influential open source projects
From Appwrite to Zulip, Universe 2025’s Open Source Zone was stacked with standout projects showing just how far open source can go. Meet the maintainers—and if you want to join them in 2026, you can now apply for next year’s cohort. The post This year’s most influential open source projects appeared first on The GitHub Blog.
From Appwrite to Zulip, the Open Source Zone at Universe 2025 was stacked with projects that pushed boundaries and turned heads. These twelve open source teams brought the creativity, the engineering craft, and the “I need to try that” demos that make Universe special. Here’s a closer look at what they showcased this year. If you want to join them in 2026, applications for next year’s Open Source Zone are open now! Appwrite: Backend made simple Appwrite is an open source backend platform that helps developers build secure and scalable apps without boilerplate. With APIs for databases, authentication, storage, and more, it’s become a go-to foundation for web and mobile developers who want to ship faster. <img data-recalc-dims="1" loading="lazy" decoding="async" height="550" width="1024" src="https://github.blog/wp-content/uploads/2025/12/appwrite.png?resize=1024%2C550" alt="Screenshot of Appwrite." class="wp-image-93058" srcset="https://github.blog/wp-content/uploads/2025/12/appwrite.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/appwrite.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/appwrite.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/appwrite.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/appwrite.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Origin story: Appwrite Appwrite was created in 2019 by Eldad Fux as a side project, and it quickly grew from a weekend project to one of the fastest-growing developer platforms on GitHub, with over 50,000 stars and hundreds of contributors worldwide. <img data-recalc-dims="1" loading="lazy" decoding="async" height="682" width="1024" src="https://github.blog/wp-content/uploads/2025/12/appwrite2.png?resize=1024%2C682" alt="Photo of Appwrite's @divanov11 and @stnguyen90 in the Open Source Zone." class="wp-image-93059" srcset="https://github.blog/wp-content/uploads/2025/12/appwrite2.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/appwrite2.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/appwrite2.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/appwrite2.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/appwrite2.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Appwrite’s @divanov11 and @stnguyen90 give the Open Source Zone a 👍🏻. GoReleaser: Effortless release automation for Go GoReleaser automates packaging, publishing, and distributing Go projects so developers can ship faster with less stress. With strong support from its contributor base, it has become the go-to release engineering tool for Go maintainers who want to focus on building rather than busywork. 🚦 Go go go, GoReleaser: GoReleaser started life in 2015 as a simple release.sh script. Within a year, @caarlos0, rewrote it in Go with YAML configs, during his holiday break—instead of, you know, actually taking a holiday. That rewrite became the foundation of what’s now a tool with over 15,000 stars and paying customers worldwide. GitHub included! E.g. for GitHub CLI. And can we all just take a minute to applaud the GoReleaser logo?! <img data-recalc-dims="1" loading="lazy" decoding="async" width="1000" height="1000" src="https://github.blog/wp-content/uploads/2025/12/logo.png?resize=1000%2C1000" alt="A logo of a gopher on a rocket." class="wp-image-93060" srcset="https://github.blog/wp-content/uploads/2025/12/logo.png?w=1000 1000w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=150 150w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=600 600w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=400 400w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=200 200w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=90 90w, https://github.blog/wp-content/uploads/2025/12/logo.png?w=116 116w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> 💡 Fun fact: one of my colleagues, @ashleymcnamara, has created a secession (that’s the word for a bunch of Gophers—I checked!) of iconic Gopher designs that have become part of Go’s visual culture. If you’ve seen a Gopher sticker at a conference, odds are it came from her repo. Watch out, Ashley. Looks like you have some competition. Homebrew: The missing package manager for macOS Speaking of great logos. Homebrew is the de facto package manager for macOS, beloved by developers for making it simple to install, manage, and update software from the command line. From data scientists to DevOps engineers, millions rely on Homebrew every day to bootstrap their environments, automate workflows, and keep projects running smoothly. Thanks for having us! GitHub Universe was a great opportunity to re-energize by meeting users and fellow maintainers. Issy Long, Senior Software Engineer & Homebrew Lead Maintainer <img data-recalc-dims="1" loading="lazy" decoding="async" height="682" width="1024" src="https://github.blog/wp-content/uploads/2025/12/homebrew.png?resize=1024%2C682" alt="Photo of Homebrew at the GitHub Universe Open Source Zone." class="wp-image-93061" srcset="https://github.blog/wp-content/uploads/2025/12/homebrew.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/homebrew.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/homebrew.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/homebrew.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/homebrew.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Homebrew lead maintainers @p-linnane and @issyl0 were on hand to meet users and answer questions. Cheers! 🍻 Ladybird: A browser for the bold Ladybird is an ambitious and independent open source browser being built from scratch with performance, security, and privacy in mind. What began as a humble HTML viewer is now evolving into one of the most exciting projects in the browser space, supported by a rapidly growing global community. Ladybird publish a monthly update showcasing bug fixes, performance improvements, and feature additions like variable font support and enhanced WebGL support. 💡 Did you know: Ladybird started life in 2018 as a tiny HTML viewer tucked inside the SerenityOS operating system. Fast-forward a few years and it’s grown up into a full-fledged, from-scratch browser with a buzzing open source community—1200 contributors and counting! Moondream: Tiny AI, big vision Moondream is an open source visual language model that brings visual intelligence for everyone. With a tiny 1 GB footprint and blazing performance, it runs anywhere from laptops to edge devices without the need for GPUs or complex infrastructure. Developers can caption images, detect objects, follow gaze, read documents, and more using natural language prompts. With more than 6 million downloads and thousands of GitHub stars, Moondream is trusted across industries from healthcare to robotics, making state-of-the-art vision AI as simple as writing a line of code. Oh My Zsh: Supercharge your shell Oh My Zsh is a community-driven framework that makes the Zsh shell stylish, powerful, and endlessly customizable. With hundreds of plugins and themes and millions of users, it is one of the most beloved ways to supercharge the command line. People get really into customizing their prompts—myself included—but GitHub’s @casidoo raised the bar with her blog post. Safe to say her prompt looks way cooler than mine. For now… 😈 <img data-recalc-dims="1" loading="lazy" decoding="async" height="682" width="1024" src="https://github.blog/wp-content/uploads/2025/12/oh-my-zsh.png?resize=1024%2C682" alt="Photo of Oh My Zsh at the GitHub Universe Open Source Zone." class="wp-image-93064" srcset="https://github.blog/wp-content/uploads/2025/12/oh-my-zsh.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/oh-my-zsh.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/oh-my-zsh.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/oh-my-zsh.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/oh-my-zsh.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Oh my gosh, it’s the Oh My Zsh creator @robbyrussell and maintainer @carlosala discussing why your shell deserves nice things. 💡 Fun fact: Oh My Zsh started in 2009 as a weekend project by Robby Russell, and it’s now one of the most popular open-source frameworks for managing Zsh configs, with thousands of plugins and themes contributed by the community. <3 OpenCV: The computer vision powerhouse OpenCV is the most widely used open source computer vision library in the world, powering robotics, medical imaging, and cutting-edge AI research. With a vast community of contributors, it remains the essential toolkit for developers working with images and video. 🧐 Did you know: OpenCV started in 1999 at Intel as a research project and today it powers everything from self-driving cars to Instagram filters, with over 40,000 stars on GitHub and millions of users worldwide! Open Source Project Security Baseline (OSPSB): Raising the bar Security isn’t glamorous, but maintaining a healthy open source ecosystem depends on it—and that’s where the Open Source Project Security Baseline (OSPSB) comes in. OSPSB, an initiative from the OpenSSF community, gives maintainers a practical, no-nonsense checklist of what “good security” actually looks like. Instead of vague best practices, it focuses on realistic, minimum requirements that any project can meet, no matter the size of the team. At Universe 2025, OSPSB resonated with maintainers looking for clarity in a world of shifting threats. The maturity levels and self-assessment tools make it simple to understand where your project is strong, where it needs improvement, and how users can contribute back to security work — a win for the entire ecosystem. 💡 Fun fact: OSPSB is used by hundreds of projects as a self-assessment tool, and it’s supported by the GitHub Secure Open Source Fund to help maintainers keep their software resilient. The resilience and sustainability of open source is a shared responsibility between maintainers and users. Beyond telling consumers why they should trust your project, Baseline will also tell them where they can contribute to security improvements. Xavier René-Corail, Senior Director, GitHub Security Research p5.js and Processing for Creative Coding p5.js is a beginner-friendly JavaScript library that makes coding accessible for artists, educators, and developers alike. From interactive art to generative visuals, it empowers millions to express ideas through code and brings creative coding into classrooms and communities worldwide. Processing is an open-source programming environment designed to teach code through visual art and interactive media. Used by artists, educators, and students worldwide, it bridges technology and creativity, making programming accessible, playful, and expressive. PixiJS: Powering graphics on the web PixiJS is a powerful HTML5 engine for creating stunning 2D graphics on the web. Built on top of WebGL and WebGPU, it delivers one of the fastest and most flexible rendering experiences available. With an intuitive API, support for custom shaders, advanced text rendering, multi-touch interactivity, and accessibility features, PixiJS empowers developers to craft beautiful, interactive experiences that run smoothly across desktop, mobile, and beyond. With over 46,000 stars on GitHub and adoption by hundreds of global brands, PixiJS has become the go-to toolkit for building games, applications, and large-scale visualizations in the browser. 💡 Fun fact: PixiJS has been around for more than 12 years and has powered everything from hit games like Happy Wheels and Subway Surfers to immersive art installations projected onto city buildings. Developer Simone Seagle used PixiJS to bring The Met’s Open Access artworks to life—animating Kandinsky’s Violett with spring physics and transforming Monet’s water lilies into a swirling, interactive experience. SparkJS: Splat the limits of 3D Spark (no, not that one!) is an advanced 3D Gaussian Splatting renderer for THREE.js, letting developers blend cutting-edge research with the most popular JavaScript 3D engine on the web. Portable, fast, and surprisingly lightweight, SparkJS brings real-time splat rendering to almost any device with correct sorting, animation support, and compatibility for major splat formats like .PLY, .SPZ, and .KSPLAT. What is Gaussian Splatting? Gaussian Splatting is a graphics technique that represents 3D objects as millions of tiny, semi-transparent ellipsoids (“splats”) instead of heavy polygon meshes. It delivers photorealistic detail, smooth surfaces, and fast real-time performance, making it a rising star in computer vision, neural rendering, and now, thanks to Spark, everyday web development. Zulip: Conversations that scale Zulip is the open source team chat platform built for thoughtful communication at scale. Unlike traditional chat apps where conversations quickly become noise, Zulip’s unique topic-based threading keeps discussions organized and discoverable, even days later. With integrations, bots, and clients for every platform, Zulip helps distributed teams collaborate without the chaos. 💡 Fun fact: Zulip began as a small startup in 2012, was acquired by Dropbox in 2014, and open sourced in 2015. Today it has over 1500 contributors worldwide, powering communities, classrooms, nonprofits, and companies that need conversations to stay useful. <img data-recalc-dims="1" loading="lazy" decoding="async" height="682" width="1024" src="https://github.blog/wp-content/uploads/2025/12/Zulip.png?resize=1024%2C682" alt="Photo of Zulip's both in the GitHub Universe Open Source Zone." class="wp-image-93065" srcset="https://github.blog/wp-content/uploads/2025/12/Zulip.png?w=1600 1600w, https://github.blog/wp-content/uploads/2025/12/Zulip.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/Zulip.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/Zulip.png?w=1024 1024w, https://github.blog/wp-content/uploads/2025/12/Zulip.png?w=1536 1536w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> From left-to-right, @gnprice, @alya, @timabbott stand at the Zulip booth. We want to thank the maintainers for participating at GitHub Universe in the Open Source Zone, and for your projects that are making our world turn. You all are what open source is about! <3 Even if you didn’t get to meet these folks at Universe, it’s never too late to check out their work. Or, you can keep powering open source by contributing to or sponsoring a project. Want to showcase your project at GitHub Universe next year? Apply now! You’ll get two free tickets and a space on the show floor. The post This year’s most influential open source projects appeared first on The GitHub Blog.
The future of AI-powered software optimization (and how it can help your team)
We envision the future of AI-enabled tooling to look like near-effortless engineering for sustainability. We call it Continuous Efficiency. The post The future of AI-powered software optimization (and how it can help your team) appeared first on The GitHub Blog.
When was the last time you heard someone ask in a standup, “How could we do this more sustainably?” Topics like green software and carbon efficiency are unfortunately rarely at the top of busy development teams’ priority lists. What’s more, there are very few “green software practitioners” out there. But we believe we’re at a unique moment in time where this can all change. The next generation of AI-enabled developer tooling has the opportunity to create near-effortless, always-on engineering for sustainability. The GitHub Next and GitHub Sustainability teams have been collaborating to prove this concept and value through a series of internal and external pilot projects. We call it Continuous Efficiency. Making the case for Continuous Efficiency We believe that once it’s ready for broader adoption, Continuous Efficiency will have the potential to make a significant positive impact for developers, businesses, and sustainability. For developers Digital sustainability and green software are intrinsically aligned to “efficiency,” which is at the core of software engineering. Many developers would benefit from performant software, better standardization of code, change quality assurance, and more. For businesses Building for sustainability has measurable business value, including: Reducing power and resource consumption Increasing efficiency Better code quality Improved user experience Lower costs Despite this, sustainability rarely makes it onto the roadmap, priority list, or even the backlog. But imagine a world in which the codebase could continuously improve itself… <img data-recalc-dims="1" loading="lazy" decoding="async" height="320" width="1024" src="https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?resize=1024%2C320" alt="A graphic showing Continuous Efficiency = Green Software + Continuous AI" class="wp-image-92828" srcset="https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=1324 1324w, https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=300 300w, https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=768 768w, https://github.blog/wp-content/uploads/2025/12/image1_c8a727.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> Continuous Efficiency means effortless, incremental, validated improvements to codebases for increased efficiency. It’s an emergent practice based on a set of tools and techniques that we are starting to develop and hope to see the developer community expand on. This emerges at the intersection of Continuous AI and Green Software. Continuous AI is AI-enriched automation to software collaboration. We are exploring LLM-powered automation in platform-based software development and CI/CD workflows. Green Software is designed and built to be more energy-efficient and have a lower environmental impact. This practice tends to result in software that is cheaper, more performant, and more resilient. Continuous Efficiency in (GitHub) Action(s) While Continuous Efficiency is a generally applicable concept, we have been building implementations on a specific GitHub platform and infrastructure called Agentic Workflows. It’s publicly available and open source, but currently in “research demonstrator” status (read: experimental prototype, pre-release, subject to change and errors!). Agentic Workflows is an experimental framework for exploring proactive, automated, event-driven agentic behaviors in GitHub repositories, running safely in GitHub Actions. Our work in this space has been focused on two areas: Implementing rules and standards With modern LLMs and agentic workflows, we can now express engineering standards and code-quality guidelines directly in natural language and apply them at a scale that was previously unattainable. This capability goes far beyond traditional linting and static analysis approaches in three important ways: Declarative, intent-based rule authoring: you describe the intent in natural language and the model interprets and implements it (no need for hard-coded patterns or logic). Semantic generalizability: a single high-level rule can be applied across diverse code patterns, programming languages and architectures, giving far broader coverage than conventional tools and approaches. Intelligent remediation: this approach comprehensively resolves issues and violations through agentic, platform-integrated actions, like writing a pull request or adding comments and suggested edits to a change. Examples of our work: Case study: Code base reviews Green software rules implementation We have implemented a wide range of standard and specific Green Software rules, tactics and patterns. These can be applied fully agentically to entire codebases and repos. Example: We teamed up with the resolve project to scan their codebase with a number of rules, and agentically delivered proposed improvements. The outputs weren’t all perfect—but one of the recently approved and merged pull requests makes a small performance improvement by “hoisting” RegExp literals from within hot functions. The project gets 500M+ downloads per month on npm. So this small impact will scale! Case study: Implementing standards Web sustainability guidelines (WSG) The W3C WSG is a great resource to help people make web products and services more sustainable. We implemented the Web Development section into a set of 20 agentic workflows, so now the guidelines can be used by AI too! Example: We have run the WSG workflows on a number of GitHub and Microsoft web properties and found opportunities and built resolutions to improve them—ranging from deferred loading to using native browser features and latest language standards. Heterogeneous performance improvement Performance engineering is notoriously difficult because real-world software is profoundly heterogeneous. Every repository brings a different mix of languages and architectures, and even within a single codebase, the sources of performance issues can span from algorithmic choices to cache behavior to network paths. Expert performance engineers excel at navigating this complexity, but the sheer variety and volume of work across the industry demands better tooling and scalable assistance. We’ve been thinking about the “grand challenge” of how to build a generic agent that can walk up to any piece of software and make demonstrable performance improvements. One that could navigate the vast ambiguity and heterogeneity of software in the wild—no small task! Semi-automatic performance engineering aims to meet that need with an automated, iterative workflow where an agent researches, plans, measures, and implements improvements under human guidance. The process begins with “fit-to-repo” discovery—figuring out how to build, benchmark, and measure a given project—before attempting any optimization. Modern LLM-based agents can explore repositories, identify relevant performance tools, run microbenchmarks, and propose targeted code changes. Early results vary quite dramatically, but some show promise that guided automation can meaningfully improve software performance at scale. Case study: Daily perf improver Daily Perf Improver is a three-phase workflow, intended to run in small daily sprints. It can do things like: (1) Research and plan improvements (2) Infer how to build and benchmark the repository (3) Iteratively propose measured optimizations Example:On a focused recent pilot on FSharp.Control.AsyncSeq it has already delivered real gains by producing multiple accepted pull requests, including a rediscovered performance bug fix and verified microbenchmark-driven optimizations. Daily Perf Improver Research Demonstrator How to build and run agentic workflows GitHub agentic workflows enable you to write automation in natural language (Markdown) instead of traditional YAML or scripts. You author a workflow in a .md file that begins with a YAML-like “front matter” (defining triggers, permissions, tools, safe-outputs, etc.), followed by plain-English instructions. At build time you run the gh aw compile command (part of the agentic workflows CLI) which compiles the Markdown into a standard GitHub Actions workflow (.yml) that can be executed by the normal GitHub Actions runtime. When the compiled workflow runs, it launches an AI agent (for example via GitHub Copilot CLI, or other supported engines like Claude Code or OpenAI Codex) inside a sandboxed environment. The agent reads the repository’s context, applies the human-written natural-language instructions (for example “look for missing documentation, update README files, then open a pull request”), and produces outputs such as comments, pull requests, or other repository modifications. Because it’s running in the GitHub Actions environment, permission boundaries, safe-output restrictions, logs, auditability, and other security controls remain. How we build our Continuous Efficiency Workflows (with agents, of course!) Our internal process for creating Continuous Efficiency workflows follows a simple, repeatable pattern: Define the intent: based on a public standard or a domain-specific engineering requirement. Author the workflow in Markdown: using structured natural language, guided interactively by the create-agentic-workflow agent. Compile to YAML: turning the Markdown into a standard GitHub Actions workflow. Run in GitHub Actions: executing the workflow on selected repositories Want to get involved in Continuous Efficiency? If you’re a developer who loves the experimentation phase, you can already get started with running agentic workflows in GitHub Actions now! There are a range of examples that you can immediately try out (including a “Daily performance improver”) or author your own using natural language. GitHub Sustainability will soon be publishing rulesets, workflows, and more—if you’re interested in being an early adopter or design partner, please get in touch with me. The post The future of AI-powered software optimization (and how it can help your team) appeared first on The GitHub Blog.
A look at how we rebuilt GitHub Actions’ core architecture and shipped long-requested upgrades to improve performance, workflow flexibility, reliability, and everyday developer experience. The post Let’s talk about GitHub Actions appeared first on The GitHub Blog.
GitHub Actions has grown massively since its release in 2018; in 2025 alone, developers used 11.5 billion GitHub Actions minutes in public and open source projects, up 35% year over year from 2024. At the same time, this has not been without its growing pains, and you’ve made clear to us what improvements matter most: faster builds, improved security, better caching, more workflow flexibility, and rock-solid reliability. Meeting that level of demand first required a deliberate investment in re-architecting the core backend services powering every GitHub Actions job and runner. This was a substantial effort that laid the foundation for the long-term performance, scalability, and feature delivery you’ve been asking for. That new architecture is rolled out, powering 71 million jobs per day and giving us deeper visibility into developer experience across the platform. With that work behind us, we shift our attention back to your top requests for much needed, long-standing quality-of-life improvements. Below, we’ll walk through what we’ve shipped this year, how you can get started with these upgrades today, and what’s coming in 2026. Let’s jump in. Rebuilding the core of GitHub Actions In early 2024, the GitHub Actions team faced a problem. The platform was running about 23 million jobs per day, but month-over-month growth made one thing clear: our existing architecture couldn’t reliably support our growth curve. In order to increase feature velocity, we first needed to improve reliability and modernize the legacy frameworks that supported GitHub Actions. The solution? Re-architect the core backend services powering GitHub Actions jobs and runners. Our goals were to improve uptime and resilience against infrastructure issues, improve performance and reduce internal throttles, and leverage GitHub’s broader platform investments and developer experience improvements. We aimed to scale 10x over existing usage. This effort was a big bet and consumed a significant part of our team’s focus. And the work is paying off by helping us handle our current scale, even as we work through the last pieces of stabilizing our new platform. Since August, all GitHub Actions jobs have run on our new architecture, which handles 71 million jobs per day (over 3x from where we started). Individual enterprises are able to start 7x more jobs per minute than our previous architecture could support. This was not without its share of pain; it slowed the pace of feature work and delayed progress on long-standing community requests. We knew this would be a tough call, but it was a critical decision to enable our future roadmap and sustainability as a product. Shifting our focus back to community-requested improvements We acknowledge we still have a ways to go, and this is just the beginning of this new chapter of the GitHub Actions story. As we shift our focus back to much-needed improvements, we want to call out some of the most recent ships on this front: YAML anchors reduce duplication in complex workflows First up, we shipped support for YAML anchors, one of the most requested features across both the runners and community repositories. YAML anchors reduce repetitive configuration in GitHub Actions workflows by letting you define settings once with an anchor (&) and reference them elsewhere with an alias (*). This allows you to maintain consistent environment variables, step configurations, or entire job setups across your workflows—all defined centrally rather than repeated across multiple jobs. 💡 Read our Docs to learn more about YAML anchors and aliases Non-public workflow templates for consistent CI across teams We released non-public workflow templates, a longstanding request from organizations that want consistent, private workflow scaffolding. Non-public workflow templates let organizations set up common templates for their teams directly in their .github repository, giving developers a reliable starting point when spinning up new workflows. Instead of manually copying CI patterns across repositories, teams can now work from a shared set of patterns. 💡 Read our Docs to learn more about workflow templates Deeper reusable workflows for modular, large-scale pipelines We shipped increases to reusable workflow depth (another key request from the community). Reusable workflows let you break your automation into modular, shareable pieces. With the updated limits now supporting 10 levels of nesting and 50 workflow calls per run, teams now have more flexibility to structure their CI/CD pipelines in a way that’s maintainable and scales with their architectural requirements. 💡 Read our Docs to learn more about reusable workflows Larger caches for bigger projects and dependency-heavy builds Repositories can now exceed the previous 10GB cache limit, removing a long-standing pain point for teams with large dependencies or multi-language monorepos. For teams with larger codebases or complex build pipelines, the old 10GB GitHub Actions cache limit often meant build dependencies were evicted before they could speed up your next workflow run, leading to repeated downloads and slower builds. This release was only possible due to our architecture rework and fulfills a request from the community, particularly among some of our largest users. 💡 Read our Docs to learn more about managing cache storage More workflow dispatch inputs for richer automation In early December, we shipped an increase to the number of workflow dispatch inputs from 10 to 25, which also came up in our community discussions. Now developers have more flexibility to build sophisticated self-service workflows, whether teams are parameterizing deployments, configuring test runs, or building reusable automation with richer input options. 💡 Read our docs to learn more about manually running a workflow with workflow_dispatch More performance and platform improvements shipped in 2025 We also made progress on the strong foundation laid earlier this year, including arm64-hosted runners for public repositories, macOS 15 and Windows 2025 images (now generally available), Actions Performance Metrics (also generally available), and Custom Image support in public preview. These releases are designed to improve day-to-day workflow quality and remove long-standing friction. What’s coming in early 2026 This is just the beginning as there is much we need to do to deliver an even better experience with GitHub Actions. Here’s what we’re planning for the first quarter of 2026, influenced by some of the top requests from our community: Support for timezones in scheduled jobs and updates to schedule reliability. Return the run ID from workflow dispatch. Adding a case function for expressions so they have a conditional operator or function. UX improvements, including faster page load times, better rendering for workflows with over 300 jobs, and a filter for the jobs list. Moreover, we’ll start work on parallel steps, one of the most requested features across GitHub Actions. Our goal is to ship it before mid-2026. Lastly, we are going to raise the bar and start to address some of the asks to lift quality in our open source repositories—we appreciate we need to drive up the quality of our experience here as well. Help us shape the 2026 roadmap for GitHub Actions GitHub Actions is one of the most important primitives on GitHub. It powers the builds, tests, deployments, automations, and release processes that define how software ships today. Our promise to you: 2026 will bring more consistent releases, more transparency, and continued focus on the fundamentals that matter most. We are also increasing funding towards this area to enable us to meet your expectations faster than before. And this is where we need your help to make sure we’re focusing on the quality-of-life improvements that matter the most. We need your feedback. To support our work: Keep voting for your most important items in the community discussions. Join us in our new community discussion post, where the GitHub Actions product and engineering leads will be actively discussing with you what comes next. Help us drive a plan for next year to make actions the best it can be. We know GitHub Actions powers how developers build software, and the best version is the one we’ll build together. And as always, you can keep up to date with the GitHub Actions releases through the GitHub Changelog. The post Let’s talk about GitHub Actions appeared first on The GitHub Blog.
GitHub Availability Report: November 2025
In November, we experienced three incidents that resulted in degraded performance across GitHub services. The post GitHub Availability Report: November 2025 appeared first on The GitHub Blog.
In November, we experienced three incidents that resulted in degraded performance across GitHub services. November 17 16:52 UTC (lasting 2 hours and 16 minutes) On November 17, 2025, from 16:52 to 19:08 UTC, Dependabot was hitting a rate limit in GitHub Container Registry (GHCR) and was unable to complete about 57% of jobs within SLO. To mitigate the issue, we lowered the rate at which Dependabot started jobs and increased the GHCR rate limit. This mitigated the circumstances and led to the resolution of the incident. Longer term, we’re adding new monitors and alerts to help prevent this in the future. November 18 20:30 UTC (lasting 1 hour and 4 minutes) On November 18, 2025, from 20:30 to 21:34 UTC, we experienced failures on all Git operations, including both SSH and HTTP Git client interactions, as well as raw file access. These failures also impacted products that rely on Git operations. The root cause was an expired TLS certificate used for internal service-to-service communication. We mitigated the incident by replacing the expired certificate and restarting impacted services. Once those services were restarted we saw a full recovery. We have updated our alerting to cover the expired certificate, and we are performing an audit of other certificates in this area to ensure they also have the proper alerting and automation before expiration. In parallel, we are accelerating efforts to eliminate our remaining manually managed certificates, ensuring all service-to-service communication is fully automated. November 28 05:59 UTC (lasting 2 hours and 24 minutes) On November 28, 2025, between approximately 05:59 and 08:24 UTC, Copilot experienced an outage affecting the Claude Sonnet 4.5 model. Users attempting to use this model received an HTTP 400 error indicating no model was available until an alternative model was selected. Other models were not impacted. The issue was caused by a misconfiguration deployed to an internal service, which made Claude Sonnet 4.5 erroneously listed as unavailable. The problem was identified and mitigated by reverting the configuration change. We are working to improve cross-service deploy safeguards to prevent similar incidents in the future. Follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the engineering section on the GitHub Blog. The post GitHub Availability Report: November 2025 appeared first on The GitHub Blog.
MCP joins the Linux Foundation: What this means for developers building the next era of AI tools and agents
MCP is moving to the Linux Foundation. Here's how that will affect developers. The post MCP joins the Linux Foundation: What this means for developers building the next era of AI tools and agents appeared first on The GitHub Blog.
Over the past year, AI development has exploded. More than 1.1 million public GitHub repositories now import an LLM SDK (+178% YoY), and developers created nearly 700,000 new AI repositories, according to this year’s Octoverse report. Agentic tools like vllm, ollama, continue, aider, ragflow, and cline are quickly becoming part of the modern developer stack. As this ecosystem expands, we’ve seen a growing need to connect models to external tools and systems—securely, consistently, and across platforms. That’s the gap the Model Context Protocol (MCP) has rapidly filled. Born as an open source idea inside Anthropic, MCP grew quickly because it was open from the very beginning and designed for the community to extend, adopt, and shape together. That openness is a core reason it became one of the fastest-growing standards in the industry. That also allowed companies like GitHub and Microsoft to join in and help build out the standard. Now, Anthropic is donating MCP to the Agentic AI Foundation, which will be managed by the Linux Foundation, and the protocol is entering a new phase of shared stewardship. This will provide developers with a foundation for long-term tooling, production agents, and enterprise systems. This is exciting for those of us who have been involved in the MCP community. And given our long-term support of the Linux Foundation, we are hugely supportive of this move. The past year has seen incredible growth and change for MCP. I thought it would be great to review how MCP got here, and what its transition to the Linux Foundation means for the next wave of AI development. Before MCP: Fragmented APIs and brittle integrations LLMs started as isolated systems. You sent them prompts and got responses back. We would use patterns like retrieval-augmented generation (RAG) to help us bring in data to give more context to the LLM, but that was limited. OpenAI’s introduction of function calling brought about a huge change as, for the first time, you could call any external function. This is what we initially built on top of as part of GitHub Copilot. By early 2023, developers were connecting LLMs to external systems through a patchwork of incompatible APIs: bespoke extensions, IDE plugins, and platform-specific agent frameworks, among other things. Every provider had its own integration story, and none of them worked in exactly the same way. Nick Cooper, an OpenAI engineer and MCP steering committee member, summarized it plainly: “All the platforms had their own attempts like function calling, plugin APIs, extensions, but they just didn’t get much traction.” This wasn’t a tooling problem. It was an architecture problem. Connecting a model to the realtime web, a database, ticketing system, search index, or CI pipeline required bespoke code that often broke with the next model update. Developers had to write deep integration glue one platform at a time. As David Soria Parra, a senior engineer at Anthropic and one of the original architects of MCP, put it, the industry was running headfirst into an n×m integration problem with too many clients, too many systems, and no shared protocol to connect them. In practical terms, the n×m integration problem describes a world where every model client (n) must integrate separately with every tool, service, or system developers rely on (m). This would mean five different AI clients talking to ten internal systems, resulting in fifty bespoke integrations—each with different semantics, authentication flows, and failure modes. MCP collapses this by defining a single, vendor-neutral protocol that both clients and tools can speak. With something like GitHub Copilot, where we are connecting to all of the frontier labs models and developers using Copilot, we also need to connect to hundreds of systems as part of their developer platform. This was not just an integration challenge, but an innovation challenge. And the absence of a standard wasn’t just inefficient; it slowed real-world adoption. In regulated industries like finance, healthcare, security, developers needed secure, auditable, cross-platform ways to let models communicate with systems. What they got instead were proprietary plugin ecosystems with unclear trust boundaries. MCP: A protocol built for how developers work Across the industry including at Anthropic, GitHub, Microsoft, and others, engineers kept running into the same wall: reliably connecting models to context and tools. Inside Anthropic, teams noticed that their internal prototypes kept converging on similar patterns for requesting data, invoking tools, and handling long-running tasks. Soria Parra described MCP’s origin simply: it was a way to standardize patterns Anthropic engineers were reinventing. MCP distilled those patterns into a protocol designed around communication, or how models and systems talk to each other, request context, and execute tools. Anthropic’s Jerome Swanwick recalled an early internal hackathon where “every entry was built on MCP … went viral internally.” That early developer traction became the seed. Once Anthropic released MCP publicly alongside high-quality reference servers, we saw the value immediately, and it was clear that the broader community understood the value immediately. MCP offered a shared way for models to communicate with external systems, regardless of client, runtime, or vendor. Why MCP clicked: Built for real developer workflows When MCP launched, adoption was immediate and unlike any standard I have seen before. Developers building AI-powered tools and agents had already experienced the pain MCP solved. As Microsoft’s Den Delimarsky, a principal engineer and core MCP steering committee member focused on security and OAuth, said: “It just clicked. I got the problem they were trying to solve; I got why this needs to exist.” Within weeks, contributors from Anthropic, Microsoft, GitHub, OpenAI, and independent developers began expanding and hardening the protocol. Over the next nine months, the community added: OAuth flows for secure, remote servers Sampling semantics (These help ensure consistent model behavior when tools are invoked or context is requested, giving developers more predictable execution across different MCP clients.) Refined tool schemas Consistent server discovery patterns Expanded reference implementations Improving long-running task support Long-running task APIs are a critical feature. They allow builds, indexing operations, deployments, and other multi-minute jobs to be tracked predictably, without polling hacks or custom callback channels. This was essential for the long-running AI agent workflows that we now see today. Delimarsky’s OAuth work also became an inflection point. Prior to it, most MCP servers ran locally, which limited usage in enterprise environments and caused installation friction. OAuth enabled remote MCP servers, unlocking secure, compliant integrations at scale. This shift is what made MCP viable for multi-machine orchestration, shared enterprise services, and non-local infrastructure. Just as importantly, OAuth gives MCP a familiar and proven security model with no proprietary token formats or ad-hoc trust flows. That makes it significantly easier to adopt inside existing enterprise authentication stacks. Similarly, the MCP Registry—developed in the open by the MCP community with contributions and tooling support from Anthropic, GitHub, and others—gave developers a discoverability layer and gave enterprises governance control. Toby Padilla, who leads MCP Server and Registry efforts at GitHub, described this as a way to ensure “developers can find high-quality servers, and enterprises can control what their users adopt.” But no single company drove MCP’s trajectory. What stands out across all my conversations with the community is the sense of shared stewardship. Cooper articulated it clearly: “I don’t meet with Anthropic, I meet with David. And I don’t meet with Google, I meet with Che.” The work was never about corporate boundaries. It was about the protocol. This collaborative culture, reminiscent of the early days of the web, is the absolute best of open source. It’s also why, in my opinion, MCP spread so quickly. Developer momentum: MCP enters the Octoverse The 2025 Octoverse report, our annual deep dive into open source and public activity on GitHub, highlights an unprecedented surge in AI development: 1.13M public repositories now import an LLM SDK (+178% YoY) 693k new AI repositories were created this year 6M+ monthly commits to AI repositories Tools like vllm, ollama, continue, aider, cline, and ragflow dominated fastest-growing repos Standards are emerging in real time with MCP alone, hitting 37k stars in under eight months These signals tell a clear story: developers aren’t just experimenting with LLMs, they’re operationalizing them. With hundreds of thousands of developers building AI agents, local runners, pipelines, and inference stacks, the ecosystem needs consistent ways to connect models to tools, services, and context. MCP isn’t riding the wave. The protocol aligns with where developers already are and where the ecosystem is heading. The Linux Foundation move: The protocol becomes infrastructure As MCP adoption accelerated, the need for neutral governance became unavoidable. Openness is what drove its initial adoption, but that also demands shared stewardship—especially once multiple LLM providers, tool builders, and enterprise teams began depending on the protocol. By transitioning governance to the Linux Foundation, Anthropic and the MCP steering committee are signaling that MCP has reached the maturity threshold of a true industry standard. Open, vendor-neutral governance offers everyone: 1. Long-term stability A protocol is only as strong as its longevity. Linux Foundation’s backing reduces risk for teams adopting MCP for deep integrations. 2. Equal participation Whether you’re a cloud provider, startup, or individual maintainer, Linux Foundation governance processes support equal contribution rights and transparent evolution. 3. Compatibility guarantees As more clients, servers, and agent frameworks rely on MCP, compatibility becomes as important as the protocol itself. 4. The safety of an open standard In an era where AI is increasingly part of regulated workloads, neutral governance makes MCP a safer bet for enterprises. MCP is now on the same path as technologies like Kubernetes, SPDX, GraphQL, and the CNCF stack—critical infrastructure maintained in the open. Taken together, this move aligns with the Agentic AI Foundation’s intention to bring together multiple model providers, platform teams, enterprise tool builders, and independent developers under a shared, neutral process. What MCP unlocks for developers today Developers often ask: “What do I actually get from adopting MCP?” Here’s the concrete value as I see it: 1. One server, many clients Expose a tool once. Use it across multiple AI clients, agents, shells, and IDEs. No more bespoke function-calling adapters per model provider. 2. Predictable, testable tool invocation MCP’s schemas make tool interaction debuggable and reliable, which is closer to API contracts than prompt engineering. 3. A protocol for agent-native workloads As Octoverse shows, agent workflows are moving into mainstream engineering: 1M+ agent-authored pull requests via GitHub Copilot coding agent alone in the five months since it was released Rapid growth of key AI projects like vllm and ragflow Local inference tools exploding in popularity Agents need structured ways to call tools and fetch context. MCP provides exactly that. 4. Secure, remote execution OAuth and remote-server support mean MCP works for: Enterprises Regulated workloads Multi-machine orchestration Shared internal tools 5. A growing ecosystem of servers With a growing set of community and vendor-maintained MCP servers (and more added weekly), developers can connect to: Issue trackers Code search and repositories Observability systems Internal APIs Cloud services Personal productivity tools Soria Parra emphasized that MCP isn’t just for LLMs calling tools. It can also invert the workflow by letting developers use a model to understand their own complex systems. 6. It matches how developers already build software MCP aligns with developer habits: Schema-driven interfaces (JSON Schema–based) Reproducible workflows Containerized infrastructure CI/CD environments Distributed systems Local-first testing Most developers don’t want magical behavior—they want predictable systems. MCP meets that expectation. MCP also intentionally mirrors patterns developers already know from API design, distributed systems, and standards evolution—favoring predictable, contract-based interactions over “magical” model behaviors. What happens next The Linux Foundation announcement is the beginning of MCP’s next phase, and the move signals: Broader contribution More formal governance Deeper integration into agent frameworks Cross-platform interoperability An expanding ecosystem of servers and clients Given the global developer growth highlighted in Octoverse—36M new developers on GitHub alone this year—the industry needs shared standards for AI tooling more urgently than ever. MCP is poised to be part of that future. It’s a stable, open protocol that lets developers build agents, tools, and workflows without vendor lock-in or proprietary extensions. The next era of software will be shaped not just by models, but by how models interact with systems. MCP is becoming the connective tissue for that interaction. And with its new home in the Linux Foundation, that future now belongs to the community. Explore the MCP specification and the GitHub MCP Registry to join the community working on the next phase of the protocol. The post MCP joins the Linux Foundation: What this means for developers building the next era of AI tools and agents appeared first on The GitHub Blog.