The GitHub Blog
type: channel
description: Updates, ideas, and inspiration from GitHub to help developers build and design software.
date: 2026-03-23T16:03:35Z
update period: hourly
update frequency: 1
update base: 2000-01-01T12:00+00:00
generator agent: https://wordpress.org/
items: GitHub expands application security coverage with AI‑powered detections
items: Rethinking open source mentorship in the AI era
items: How Squad runs coordinated AI agents inside your repository
items: Investing in the people shaping open source and securing the future together
items: GitHub for Beginners: Getting started with GitHub Actions
items: Continuous AI for accessibility: How GitHub transforms feedback into inclusion
items: GitHub availability report: February 2026
items: Addressing GitHub’s recent availability issues
items: The era of “AI as text” is over. Execution is the new interface.
items: Under the hood: Security architecture of GitHub Agentic Workflows

GitHub expands application security coverage with AI‑powered detections
type: item
creator: Marcelo Oliveira
date: 2026-03-23T16:00:00Z
subject: Application security
subject: Security
subject: code scanning
subject: Code security
description: CodeQL and AI‑powered detections work together in GitHub Code Security to identify vulnerabilities across more languages and frameworks. The post GitHub expands application security coverage with AI‑powered detections appeared first on The GitHub Blog.
encoded: AI is accelerating software development and expanding the range of languages and frameworks used in modern repositories. Security teams are increasingly responsible for protecting code written across many ecosystems, not just the core enterprise languages traditionally covered by static analysis. That’s why GitHub is introducing AI-powered security detections in GitHub Code Security to expand application security coverage across more languages and frameworks. These detections complement CodeQL by surfacing potential vulnerabilities in areas that are difficult to support with traditional static analysis alone. Public preview availability is planned for early Q2. Expanding application security coverage with static analysis and AI Static analysis remains an effective way to identify vulnerabilities in supported languages, which is why GitHub Code Security continues to rely on CodeQL for deep semantic analysis. But modern codebases often include scripts, infrastructure definitions, and application components built across many additional ecosystems. To address this reality, GitHub Code Security extends coverage by pairing CodeQL with AI-powered security detections across additional languages and frameworks. This hybrid detection model helps surface vulnerabilities—and suggested fixes—directly to developers within the pull request workflow. In internal testing, the system processed more than 170,000 findings over a 30-day period, with more than 80% positive developer feedback. Early results show strong coverage for ecosystems newly supported through AI-powered detections, including Shell/Bash, Dockerfiles, Terraform configurations (HCL), and PHP. This capability sits within GitHub’s broader agentic detection platform, which powers security, code quality, and code review experiences across the developer workflow. What begins as expanded coverage establishes a foundation for evolving detections over time, pairing the precision of static analysis with deeper context and new …

Rethinking open source mentorship in the AI era
type: item
creator: Abigail Cabunoc Mayes
date: 2026-03-19T18:00:00Z
subject: Maintainers
subject: Open Source
subject: AGENTS.md
subject: AI
subject: community
subject: mentoring
subject: open source
description: As contribution volume grows, mentorship signals are harder to read. The 3 Cs framework helps maintainers mentor more strategically... without burning out. The post Rethinking open source mentorship in the AI era appeared first on The GitHub Blog.
encoded: Let me paint a picture for you. A polished pull request lands in your inbox. It looks amazing at first glance, but then you start digging in, and a few things seem off. Forty-five minutes later, you’ve crafted a thoughtful, encouraging response with a few clarifying questions. Who knows: Maybe this person might be a great new person to mentor, so it’s worth your time if they put in theirs. And then…nothing. Or the follow-up makes it clear the contributor doesn’t have the context needed to explain the change, often because AI made it easy to submit something plausible before they were ready to maintain it. Or you realize you’ve just spent your afternoon debugging someone’s LLM chat session. This is becoming more common. Not because contributors are acting in bad faith, but because it’s never been easier to generate something that looks plausible. The cost to create has dropped. The cost to review hasn’t. Open source is experiencing its own “Eternal September”: a constant influx of contributions that strains the social systems we rely on to build trust and mentor newcomers. The signals have changed Projects across the ecosystem are seeing this same occurrence. tldraw closed their pull requests. Fastify shut down their HackerOne program after inbound reports became unmanageable at scale. The overall volume keeps climbing. The Octoverse 2025 report notes that developers merged nearly 45 million pull requests per month in 2025 (up 23% year over year). More pull requests, same maintainer hours. The old signals, like clean code, fast turnaround, and handling complexity, used to mean someone had invested time into understanding the codebase. Now AI can help users generate all of that in seconds, so these signals aren’t as telling. To reduce noise and bring more trust back into open source contributions, platforms, including GitHub, are building longer-term solutions. In fact, our product team just published an RFC for community feedback. If you have thoughts on what we can …

How Squad runs coordinated AI agents inside your repository
type: item
creator: Brady Gaster
date: 2026-03-19T16:09:50Z
subject: AI & ML
subject: GitHub Copilot
subject: AI
subject: multi-agent workflows
description: An inside look at repository-native orchestration with GitHub Copilot and the design patterns behind multi-agent workflows that stay inspectable, predictable, and collaborative. The post How Squad runs coordinated AI agents inside your repository appeared first on The GitHub Blog.
encoded: If you’ve used AI coding tools before, you know the pattern. You write a prompt, the model misunderstands, you refine it, and you coax better output. Progress depends more on steering the model than on building the software. As projects grow, the challenge stops being “how do I prompt?” and starts becoming “how do I coordinate design, implementation, testing, and review without losing context along the way.” Multi-agent systems are a great way to move past this plateau, but usually require a massive amount of setup. People spend hours building orchestration layers, wiring up frameworks, and configuring vector databases before they can delegate a single task. Squad, an open source project built on GitHub Copilot, initializes a preconfigured AI team directly inside your repository. It is a bet that multi-agent development can be accessible, legible, and useful without requiring heavy orchestration infrastructure or deep prompt engineering expertise. Two commands—npm install -g @bradygaster/squad-cli once globally, squad init once per repo—and Squad drops a specialized AI team: a lead, frontend developer, backend developer, and tester directly against your repository. Instead of a single chatbot switching roles, Squad demonstrates repository native multi-agent orchestration without heavy centralized infrastructure. How Squad coordinates work across agents You describe the work you need done in natural language. From there, a coordinator agent inside Squad figures out the routing, loads repository context, and spawns specialists with task-specific instructions. For example, you type: “Team, I need JWT auth—refresh tokens, bcrypt, the works.” Then you watch the team spin up in parallel. The backend specialist takes the implementation. The tester starts writing the accompanying test suite. A documentation specialist opens a pull request. Within minutes, files are written and branches are created. These specialists already know your naming conventions and what you decided …

Investing in the people shaping open source and securing the future together
type: item
creator: Kevin Crosby
date: 2026-03-17T16:00:00Z
subject: Maintainers
subject: Open Source
subject: Security
subject: Supply chain security
subject: Alpha-Omega
subject: GHAS
subject: GitHub Copilot
subject: GitHub Security Lab
subject: maintainers
subject: open source
description: See how GitHub is investing in open source security funding maintainers, partnering with Alpha-Omega, and expanding access to help reduce burden and strengthen software supply chains. The post Investing in the people shaping open source and securing the future together appeared first on The GitHub Blog.
encoded: Open source has always been about community. It’s about maintainers who review pull requests late at night. Volunteers who respond to security reports from strangers. And communities that quietly power the world’s software. The reality behind the commits is that maintainers get stretched thin. The effort of responding to pull requests and comments, while also being expected to merge and ship, adds up quickly. Late nights turn into burnout, one-person projects become critical infrastructure overnight without even realizing it, and “thank you” doesn’t pay the bills. Plus, AI is an accelerating force that’s changing how the open source community secures the ecosystem. The requirements of always-on security take more time and energy in addition to not always having the knowledge and expertise. At GitHub, we believe supporting open source means more than hosting code. It means investing in the people who maintain it, giving them the tools they need to succeed, and standing with them as the ecosystem evolves rapidly in the AI era. Open source maintainers deserve better support and security, and we’re listening and investing. Strengthening open source security, together Today, we are joining Anthropic, Amazon Web Services (AWS), Google, and OpenAI with a combined commitment of $12.5 million to support the Linux Foundation’s Alpha-Omega initiative to advance open source security. This collaboration is aimed at helping maintainers make emerging AI security capabilities accessible and integrated into existing project workflows, and at further advancing our OSS security programs, to strengthen the security of critical open source software projects. This effort builds on years of GitHub’s work as a steward of open source and software security. Real impact comes from pairing investment with practical tools, education, and long-term support designed to help maintainers. Today, over 280,000 maintainers on GitHub across hundreds of millions of public repositories are eligible for f…

GitHub for Beginners: Getting started with GitHub Actions
type: item
creator: Kedasha Kerr
date: 2026-03-16T16:00:00Z
subject: Developer skills
subject: GitHub
subject: GitHub Actions
subject: GitHub for beginners
subject: GitHub Skills
description: Set up your first GitHub Actions workflow in this how-to guide. The post GitHub for Beginners: Getting started with GitHub Actions appeared first on The GitHub Blog.
encoded: Welcome back to our ongoing GitHub for Beginners series, now in its third season! Our previous episode was the first of the season, and we talked about getting started with GitHub Issues and Projects. This time we’re jumping into another very popular GitHub feature called GitHub Actions. By the end of this post, you’ll know how to use GitHub Actions and will have created your first automated workflow. As always, if you prefer to watch the video or want to reference it, we have all of our GitHub for Beginners episodes available on YouTube. (And you can watch the full video of this tutorial above!) What are GitHub Actions? GitHub Actions is a Continuous Integration/Continuous Delivery (CI/CD) and automation platform built right into GitHub. You’ll often hear people call these “action workflows” or just “workflows.” It allows you to automate repetitive tasks and deployment processes using YAML files stored in your repository. You might use GitHub Actions for tasks like running vulnerability scans, tests, creating releases, or even reminding your team about important updates. Action workflows are triggered by GitHub events like pushes, pull requests, or schedules, and they run in a virtual environment. How workflows work Before jumping right into the details about how workflows do their job, we need to define some essential terms. Event: A specific activity that triggers a workflow (e.g., pushing code, opening a pull request, creating an issue, etc.) Hosted runners: A virtual machine that executes jobs in a workflow. GitHub provides hosted runners, or you can set up your own self-hosted runners. Jobs: A set of steps executed within the same runner. Each step is either a shell command or a prebuilt action from the GitHub Marketplace. Workflows are triggered by events in a repository. This can be something like a pull request, merging a branch, or even opening an issue. When you create the workflow, you determine what the triggering event is. When that event fires and tri…

Continuous AI for accessibility: How GitHub transforms feedback into inclusion
type: item
creator: Carie Fisher
date: 2026-03-12T16:00:00Z
subject: AI & ML
subject: Architecture & optimization
subject: Engineering
subject: GitHub Copilot
subject: User experience
subject: accessibility
subject: developer experience
subject: engineering
subject: GitHub Actions
subject: social impact
description: AI automates triage for accessibility feedback, allowing us to focus on fixing barriers—turning a chaotic backlog into continuous, rapid resolutions. The post Continuous AI for accessibility: How GitHub transforms feedback into inclusion appeared first on The GitHub Blog.
encoded: For years, accessibility feedback at GitHub didn’t have a clear place to go. Unlike typical product feedback, accessibility issues don’t belong to any single team—they cut across the entire ecosystem. For example, a screen reader user might report a broken workflow that touches navigation, authentication, and settings. A keyboard-only user might hit a trap in a shared component used across dozens of pages. A low vision user might flag a color contrast issue that affects every surface using a shared design element. No single team owns any of these problems—but every one of them blocks a real person. These reports require coordination that our existing processes weren’t originally built for. Feedback was often scattered across backlogs, bugs lingered without owners, and users followed up to silence. Improvements were often promised for a mythical “phase two” that rarely materialized. We knew we needed to change this. But before we could build something better, we had to lay the groundwork—centralizing scattered reports, creating templates, and triaging years of backlog. Only once we had that foundation in place could we ask: How can AI make this easier? The answer was an internal workflow, powered by GitHub Actions, GitHub Copilot, and GitHub Models, that ensures every piece of user and customer feedback becomes a tracked, prioritized issue. When someone reports an accessibility barrier, their feedback is captured, reviewed, and followed through until it’s addressed. We didn’t want AI to replace human judgment—we wanted it to handle repetitive work so humans could focus on fixing the software. This is how we went from chaos to a system where every piece of accessibility feedback is tracked, prioritized, and acted on—not eventually, but continuously. Accessibility as a living system Continuous AI for accessibility weaves inclusion into the fabric of software development. It’s not a single product or a one-time audit—it’s a living methodology that combines automation, a…

GitHub availability report: February 2026
type: item
creator: Jakub Oleksy
date: 2026-03-12T03:23:54Z
subject: Company
subject: Company news
subject: News & insights
subject: GitHub Availability Report
description: In February, we experienced six incidents that resulted in degraded performance across GitHub services. The post GitHub availability report: February 2026 appeared first on The GitHub Blog.
encoded: In February, we experienced six incidents that resulted in degraded performance across GitHub services. We recognize the impact these outages have had on teams, workflows, and overall confidence in our platform. Earlier today, we released a blog post outlining the root causes of recent incidents and the steps GitHub is taking to make our systems more resilient moving forward. Thank you for your patience as we work through near-term and long-term investments we’re making. Below, we go over the six major incidents specific to February. February 02 17:41 UTC (lasting 1 hour and 5 minutes) From January 31, 2026, 00:30 UTC, to February 2, 2026, 18:00 UTC, Dependabot service was degraded and failed to create 10% of automated pull requests. This was due to a cluster failover that connected to a read-only database. We mitigated the incident by pausing Dependabot queues until traffic was properly routed to healthy clusters. All failed jobs were identified and restarted. We added new monitors and alerts to reduce our time to detect and prevent this in the future. February 02 19:03 UTC (lasting 5 hours and 53 minutes) On February 2, 2026, between 18:35 UTC and 22:20 UTC, GitHub Actions hosted runners and GitHub Codespaces were unavailable, with service degraded until full recovery at 23:10 UTC for standard runners, February 3, 2026 at 00:30 UTC for larger runners, and February 3 at 00:15 for codespaces. During this time, actions jobs queued and timed out while waiting to acquire a hosted runner. Other GitHub features that leverage this compute infrastructure were similarly impacted, including Copilot coding agent, Copilot code review, CodeQL, Dependabot, GitHub Enterprise Importer, and GitHub Pages. All regions and runner types were impacted. Codespaces creation and resume operations also failed in all regions. Self-hosted runners for actions on other providers were not impacted. This outage was caused by a loss in telemetry that cascaded to mistakenly applying security polici…

Addressing GitHub’s recent availability issues
type: item
creator: Vlad Fedorov
date: 2026-03-11T21:41:51Z
subject: Company news
subject: News & insights
description: GitHub recently experienced several availability incidents. We understand the impact these outages have on our customers and are sharing details on the stabilization work we’re prioritizing right now. The post Addressing GitHub’s recent availability issues appeared first on The GitHub Blog.
encoded: Over the past several weeks, GitHub has experienced significant availability and performance issues affecting multiple services. Three of the most significant incidents happened on February 2, February 9, and March 5. First and foremost, we take responsibility. We have not met our own availability standards, and we know that reliability is foundational to the work you do every day. We understand the impact these outages have had on your teams, your workflows, and your confidence in our platform. Here, we’ll unpack what’s been causing these incidents and what we’re doing to make our systems more resilient moving forward. What happened These incidents have occurred during a period of extremely rapid usage growth across our platform, exposing scaling limitations in parts of our current architecture. Specifically, we’ve found that recent platform instability was primarily driven by rapid load growth, architectural coupling that allowed localized issues to cascade across critical services, and inability of the system to adequately shed load from misbehaving clients. Before we cover what we are doing to prevent these issues going forward, it is worth diving into the details of the most impactful incidents. February 9 incident On Monday, February 9, we experienced a high‑impact incident due to a core database cluster that supports authentication and user management becoming overloaded. The mistakes that led to the problem were made days and weeks earlier. In early February, two very popular client-side applications that make a significant amount of API calls against our servers were released, with unintentional changes driving a more-than-tenfold increase in read traffic they generated. Because these applications end up being updated by the users over time, the increase in usage doesn’t become evident right away; it appears as enough users upgrade. On Saturday, February 7, we deployed a new model. While trying to get it to customers as quickly as possible, we changed a ref…

The era of “AI as text” is over. Execution is the new interface.
type: item
creator: Gwen Davis
date: 2026-03-10T20:16:01Z
subject: AI & ML
subject: Generative AI
subject: GitHub Copilot
subject: Branching Out_
subject: GitHub Copilot SDK
subject: MCP
description: AI is shifting from prompt-response interactions to programmable execution. See how the GitHub Copilot SDK enables agentic workflows directly inside your applications. The post The era of “AI as text” is over. Execution is the new interface. appeared first on The GitHub Blog.
encoded: Over the past two years, most teams have interacted with AI the same way: provide text input, receive text output, and manually decide what to do next. But production software doesn’t operate on isolated exchanges. Real systems execute. They plan steps, invoke tools, modify files, recover from errors, and adapt under constraints you define. As a developer, you’ve gotten used to using GitHub Copilot as your trusted AI in the IDE. But I bet you’ve thought more than once: “Why can’t I use this kind of agentic workflow inside my own apps too?” Now you can. The GitHub Copilot SDK makes that execution layer available as a programmable capability inside your software. Instead of maintaining your own orchestration stack, you can embed the same production-tested planning and execution engine that powers GitHub Copilot CLI directly into your systems. If your application can trigger logic, it can now trigger agentic execution. This shift changes the architecture of AI-powered systems. So how does it work? Here are three concrete patterns teams are using to embed agentic execution into real applications. Pattern #1: Delegate multi-step work to agents For years, teams have relied on scripts and glue code to automate repetitive tasks. But the moment a workflow depends on context, changes shape mid-run, or requires error recovery, scripts become brittle. You either hard-code edge cases, or start building a homegrown orchestration layer. With the Copilot SDK, your application can delegate intent rather than encode fixed steps. For example: Your app exposes an action like “Prepare this repository for release.” Instead of defining every step manually, you pass intent and constraints. The agent: Explores the repository Plans required steps Modifies files Runs commands Adapts if something fails All while operating within defined boundaries. Why this matters: As systems scale, fixed workflows break down. Agentic execution allows software to adapt while remaining constrained and observab…

Under the hood: Security architecture of GitHub Agentic Workflows
type: item
creator: Landon Cox
date: 2026-03-09T16:00:00Z
subject: AI & ML
subject: Generative AI
subject: LLMs
subject: Machine learning
subject: agentic workflows
subject: AI agents
subject: automation
subject: continuous integration
subject: developer productivity
subject: GitHub Actions
subject: GitHub Copilot
description: GitHub Agentic Workflows are built with isolation, constrained outputs, and comprehensive logging. Learn how our threat model and security architecture help teams run agents safely in GitHub Actions. The post Under the hood: Security architecture of GitHub Agentic Workflows appeared first on The GitHub Blog.
encoded: Whether you’re an open-source maintainer or part of an enterprise team, waking up to documentation fixes, new unit tests, and refactoring suggestions can be a true “aha” moment. But automation also raises an important concern: how do you put guardrails on agents that have access to your repository and the internet? Will you be wondering if your agent relied on documentation from a sketchy website, or pushed a commit containing an API token? What if it decides to add noisy comments to every open issue one day? Automations must be predictable to offer durable value. But what is the safest way to add agents to existing automations like CI/CD? Agents are non-deterministic: They must consume untrusted inputs, reason over repository state, and make decisions at runtime. Letting agents operate in CI/CD without real-time supervision allows you to scale your software engineering, but it also requires novel guardrails to keep you from creating security problems. GitHub Agentic Workflows run on top of GitHub Actions. By default, everything in an action runs in the same trust domain. Rogue agents can interfere with MCP servers, access authentication secrets, and make network requests to arbitrary hosts. A buggy or prompt-injected agent with unrestricted access to these resources can act in unexpected and insecure ways. That’s why security is baked into the architecture of GitHub Agentic Workflows. We treat agent execution as an extension of the CI/CD model—not as a separate runtime. We separate open‑ended authoring from governed execution, then compile a workflow into a GitHub Action with explicit constraints such as permissions, outputs, auditability, and network access. This post explains how we built Agentic Workflows with security in mind from day one, starting with the threat model and the security architecture that it needs. Threat model There are two properties of agentic workflows that change the threat model for automation. First, agents’ ability to reason over reposit…