GitHub Release Notes

Enterprises can now manage their dependencies’ licenses at scale with sophisticated, ruleset-based checks that enforce a centralized policy. Open source license compliance is now generally available for GitHub Enterprise Cloud customers, including data-resident GHEC, for repositories with GitHub Code Security enabled.

How it works

Open source license compliance expands on the capabilities of the dependency review action by introducing an enterprise-wide license policy. The policy is activated by targeting repositories with a ruleset that uses a new Require license compliance results before merging condition, similar to the existing code scanning conditions. When developers open pull requests that add or modify dependencies, license checks automatically ensure each new or changed dependency has an acceptable license. The feature annotates the pull request with a message about each noncompliant dependencies. These annotations must be addressed by removing or replacing the dependency, amending the license policy, or creating package exceptions.

Open source license compliance introduces a new predefined enterprise role, Enterprise Open-Source License Manager. Assign this role to individuals or teams who should review and approve closure requests. Policy managers receive email notifications about pending requests and can review them from the enterprise console.

What’s new and improved

Since the public preview release in June, we’ve made several improvements:

• License information is now available for GitHub Enterprise Cloud data residency customers. This not only enables the license compliance feature, but also populates the dependency graph and Software Bill of Materials (SBOM) exports with license data.
• License policy changes now emit audit log events, for integration with external systems of record.
• There are new API endpoints for downloading, updating, and replacing the enterprise license policy.
• There is also a new API endpoint for checking whether packages comply with policy. This enables coding agents to avoid recommending or incorporating packages which violate an organization’s license usage policy.

How to try it

For detailed setup instructions, see About open source license compliance.

For information about API endpoints see REST API endpoints for dependency-graph

Join the discussion within GitHub Community.

The post Open source license compliance generally available appeared first on The GitHub Blog.

Original source

You can now use the generally available Xcode 27 runner image to build and test your Apple applications in GitHub Actions. Previously in public preview, this GitHub-hosted image runs on macOS 27 and includes the Xcode 27 toolchain and Apple SDKs.

Xcode-based images

Each image supports one major Xcode version rather than targeting a specific operating system version. This makes it easier to select the toolchain your project needs and know what each runner provides.

Get started

To use the image, set your workflow’s runs-on: value to one of these labels:

• xcode-27
• xcode-27-xlarge

If you already use these labels, you don’t need to change your workflows. The image is available on Apple Silicon (arm64) runners only, not Intel runners.

To view the installed software or report an issue, visit the runner-images repository.

The post Xcode 27 runner image generally available appeared first on The GitHub Blog.

Original source

@GitHub in Slack and Teams now supports working across multiple repositories in a single conversation. Whether you’re creating issues, opening pull requests, or investigating bugs, you can work across repositories without switching conversations.

For example, you can ask @GitHub to:

• Create issues from conversations: “@GitHub Create an issue in github/issues to track this bug, using the context from this thread.”
• Make code changes: “@GitHub Fix this bug in our frontend repository and open a PR with the changes.”
• Track your PRs: “@GitHub Show me all my open PRs across repositories and highlight which ones need my attention.”
• Investigate bugs: “@GitHub Investigate this issue using the code in our frontend and backend repositories.”

You can do all of this directly from Slack or Teams, without switching repositories or starting a new conversation.

Additional improvements

We’ve also made several improvements to GitHub in Slack and Microsoft Teams:

• More natural conversations: Mention @GitHub anywhere in your message, not just at the beginning.
• Smoother repository switching: Move between repositories more easily during a conversation.
• Better Slack conversation context: @GitHub can use shared Slack messages and threads as context, making it easier to reference discussions without copying and pasting details.
• Improved reliability: We’ve made several improvements to reduce errors, improve task startup, and help @GitHub recover more smoothly from interruptions in Slack and Teams.

Join the discussion within the GitHub Community.

The post Multi-repository support and other improvements for GitHub in Slack and Teams appeared first on The GitHub Blog.

Original source

Added

• Add --disable-client-telemetry flag to turn off client telemetry uploads from the CLI

Fixed

• Sandboxed shell commands now explain credential-proxy certificate trust failures and can offer an approved rerun outside the sandbox.
• Keep saved /diff review comments when reopening an unchanged diff in the same session, with an explicit discard action.
• Plugin enable, disable, update, and uninstall actions now route reliably after plugin inventory refreshes.
• Reasoning-only max-token responses no longer loop indefinitely and now end with a clear error when no progress is made
• Show a clear warning and keep the active model display in sync when a saved model is automatically replaced on resume.

Original source

Improved

• Show a clear notice when administrator-managed settings override your selected model
• Enable semantic code search by default for online sessions.

Fixed

• Sandboxed commands on Linux start more reliably without intermittent loopback setup failures
• Back from MCP resource details stays on the list during live metadata refreshes
• Native chats can start and finish while optional managed plugin downloads continue in the background.
• Double Ctrl+C exits immediately even when the CLI UI is busy
• Catalog search reports proxy authentication requirements for CONNECT proxy challenges

Original source

AI, agents, voice, and physical controls are shifting software development from operating tools to expressing intent—and helping developers stay focused on building.

For most of my career, building software started with the same setup: keyboard, mouse, editor, terminal, browser, and an impressive number of tabs I was definitely going to look at later. The tools changed, but the relationship did not. Like most developers, I learned commands, memorized shortcuts, and adapted my thinking to the machine.

AI is changing that relationship and not because I can prompt my way to some workable code. It’s more because the system behind it can understand a repository, choose the right model, plan work, use tools, edit files, run commands, inspect failures, and keep going within boundaries the developer controls.

We’ve made it possible for a developer to describe an outcome, and GitHub Copilot can gather repository context, inspect symbols and dependencies, edit files, run tests, and revise the implementation. In the IDE, agent mode keeps that loop interactive. GitHub Copilot coding agent can take an issue into an isolated GitHub Actions-powered environment and return a pull request for review. This is not just faster coding. It is the shift from issuing commands to making intent executable. The developer still owns the outcome, but the work looks subtly different.

AI-assisted development compresses that chain of events. We spend less time navigating tools and more time setting direction, supplying context, defining constraints, and reviewing evidence. The development workflow now is about understanding the structure of codebases, the customer, and what a good solution should feel like.

This makes developers’ jobs even more important, and their time more valuable. It makes judgment more valuable. It makes taste more valuable. An agent can generate three implementations before you finish your tea, but someone still has to decide whether the abstraction belongs, the migration is safe, the tests prove anything useful, and the result solves the problem.

That is the most important change in the craft: the developer remains accountable for the outcome, even as more mechanics are delegated.

So what does this mean for the emerging developer workflow? The goal is to embed AI into the workflow, not beside it. It’s more of an ambient intelligence.

That requires portable context. MCP connects agents to tools and services; repository instructions and skills encode conventions; hooks enforce policy and validate output. Simpler interfaces need explicit context underneath.

I see three layers: modality captures intent; the harness plans and acts; the control plane lets developers inspect, redirect, and approve. The best products connect all three without surrendering control.

Together, they let developers move across text, voice, and physical controls without losing context.

Why physical controls are interesting again

I, and many others in the maker community, have been experimenting with ambient control devices, from inexpensive hackable picture frames to ESP32 devices with screens attached. Agentic coding is past just a keyboard and a terminal into alternative interfaces.

Getting this kind of technology into everyone’s hands is something that I’m very passionate about and so over the past 18 months we’ve been working with Logitech on their MX Keypad and how it can help this new way of working.

The Logitech MX Keypad turns familiar developer actions into programmable inputs to accelerate workflows that are ambient and contextual to the work devs are doing. In GitHub Copilot app, a key can submit a parameterized prompt, open or resume a Copilot session, invoke an IDE command, or trigger a multi-step sequence. The hardware earns its place only when that shortcut removes enough friction to keep you in the code, but still gives you control.

Physical controls work when an action repeats often enough that removing a few steps preserves concentration. Not every developer needs another device on the desk, and not every interruption deserves a key. However, with this experience the developer decides which actions earn that shortcut and when the keyboard, command palette, or voice is better. Maintaining flow is the key, and a good interface gives some of that attention back.

GUIs made software visual. Mouse made navigation easier. The web made it connected. Mobile made touch natural. Agents add intent and action. The interface now includes ambient control.

The interface moves into the background

That is why GitHub worked with Logitech to integrate the GitHub Copilot app directly into the experience. Developers can run agentic workflows in control, map a repeated prompt, start or resume a session, and decide through real use whether a physical control helps you stay in flow.

This is still early, so the important questions are engineering questions. How much repository and organizational context should an agent retain? Which tool calls can run automatically? How should credentials, network access, and secrets be scoped? What evidence should accompany a change? How do multiple agents coordinate without duplicating work or creating conflicting pull requests? Products such as MX Keypad let us explore one practical part of that system: how developers invoke, steer, and resume agentic work without losing focus.

For decades, developers learned to speak computer: syntax, commands, APIs, shortcuts, and the occasional incantation copied from a seven-year-old issue comment. Now computers are getting better at meeting us halfway. The best interface will not have the most panels or AI buttons. It will understand enough context, preserve meaningful control, and get out of the way so we can build software that matters.

The goal is not to remove developers from the work. It is to remove friction around the work. Pairing MX Keypad with GitHub Copilot Pro+ gives developers a concrete experiment: choose one repeated interruption, map it to a control, and see whether it preserves focus.

If you want to try it, you can do so here and get three months of GitHub Copilot Pro+.

Original source

You can now download a CSV report of your GitHub Code Quality license usage to reconcile your license count with your own records.

The report includes:

• Each active committer who consumes a Code Quality license.
• The repositories that received their commits in the last 90 days.
• Whether each committer is unique to a single repository or organization.

Use the unique committer details to identify where disabling Code Quality could free up licenses for the next billing period without changing your current license charge.

To download your report, go to the Billing and licensing page in your organization or enterprise, open Licensing, and download the CSV from the Code Quality card.

CSV downloads are available on GitHub Team and GitHub Enterprise Cloud.

For details, see Viewing and managing GitHub Code Quality costs.

Join the discussion in GitHub Community.

The post Download GitHub Code Quality license usage as a CSV appeared first on The GitHub Blog.

Original source

Code scanning

AI Scan for pull requests is now generally available. It complements CodeQL by finding vulnerabilities in pull request changes for languages and frameworks that CodeQL does not currently cover, including PHP, Shell/Bash, Terraform configuration (HCL), Dockerfiles, JSP for Java, Blazor for C#, and more.

How it works

AI Scan runs automatically on pull requests when code scanning and the repository’s effective AI Scan setting are enabled. Findings appear alongside CodeQL results on the Conversation and Files changed tabs, with an “AI” indicator to distinguish them from CodeQL alerts. Findings can include an explanation of the security risk and a suggested autofix.

AI Scan findings are advisory. They do not fail the code scanning check and cannot block pull request merges through ruleset requirements. AI Scan does not run on pull requests from forks or pull requests created by Dependabot.

Availability

AI Scan is available for public repositories owned by organizations or personal accounts. For private and internal organization-owned repositories, GitHub Code Security or GitHub Advanced Security is required. A GitHub Copilot license is not required.

Billing

AI Scan for pull requests consumes Code Security AI Credits. AI Credit usage is displayed in the “AI usage” section of enterprise billing and licensing as the “Advanced Security” product. You can also set SKU-level budgets for Code Security AI Credits. Learn more about usage-based billing.

Learn more about AI Scan for pull requests and billing for GitHub Advanced Security AI features.

Join the discussion in the AI Scan Community discussion.

The post AI Scan for pull requests generally available appeared first on The GitHub Blog.

Original source

Agentic autofix for code scanning alerts is now generally available. It remediates alerts by working across your codebase the way a developer would: it explores relevant files, proposes a fix, and reruns CodeQL to confirm the fix closes the alert before opening a pull request for your review. Agentic autofix is available to GitHub Code Security and GitHub Advanced Security customers on GitHub Enterprise Cloud, including GitHub Enterprise Cloud with data residency.

How it works

When you assign a code scanning alert to Copilot, it:

• Explores relevant files across your codebase.
• Generates a proposed fix.
• Validates the fix works by rerunning CodeQL.
• Iterates if needed, then opens a draft pull request ready for your review.

The pull request includes a summary of the fix, why it closes the alert, and the validation steps Copilot took to confirm that it works. When the pull request containing the fix is ready, you can instruct Copilot to make further changes to it by commenting on the pull request or interacting with the session in the Agents tab of your repository.

How to use it

When enabled, agentic autofix replaces the free Generate Fix option on individual code scanning alerts with an Assign to Copilot button.

You can use agentic autofix:

• From any code scanning alert on the repository’s default branch, by assigning the alert to Copilot.
• In the list of security alerts in your repository or security campaign, by selecting up to 25 alerts for Copilot to fix together in a single pull request.
• Via the Update a Code Scanning Alert REST API by setting assignees to ["copilot-swe-agent[bot]"].

Agentic autofix supports code scanning alerts on the repository’s default branch. Alerts detected only on pull requests or other branches cannot be assigned to Copilot.

Access

Agentic autofix requires an enterprise administrator to enable access to it via the new “Agentic autofix” policy in Advanced Security policies.

Once the policy is enabled by an enterprise administrator, an organization or repository administrator can turn on agentic autofix in the Code Security settings for the organization or the repository.

Access also requires a Copilot billing method to be defined.

Billing

Agentic autofix for code scanning alerts consumes AI Credits from your Code Security budget and GitHub Actions minutes. AI Credit usage will be displayed in the “AI usage” section of enterprise billing and licensing as the “Advanced Security” product. You can also set SKU level budgets for Code Security AI credits. Learn more about Copilot usage-based billing.

Learn more

Learn more about agentic autofix in the documentation.

Join the discussion within the GitHub Community.

The post Agentic autofix for code scanning alerts general availability appeared first on The GitHub Blog.

Original source

As of October 15, 2026, email notifications for repository push events have been retired and are no longer sent.

We shut down this feature to help prevent spam and abuse. Because recipients didn’t have to consent before receiving these emails, the feature could be misused to send unwanted messages through GitHub’s email infrastructure.

To continue sending email notifications for repository push events, you can use a GitHub Actions workflow triggered by push events to send emails through your own SMTP server or email provider.

The post Email notifications for repository push events have been retired appeared first on The GitHub Blog.

Original source

Added

• Add --trust-folder for one-off prompt-mode sessions started with -p or piped stdin
• Install verified Skills and plugins from GitHub install links via copilot plugin install "ghapp://air/install?..."

Improved

• Improve /login for Microsoft Entra by letting you choose a cached account or explicitly sign in with a different account
• Sandboxed git on github.com can use your configured GITHUB_TOKEN from credentials.envVars

Fixed

• HydraFusion keeps a pass expanded while its review runs, passes that were not kept stay expandable until you switch sessions or resume, and passes from an aborted turn say whether they were kept
• Managed account policy and bypass-mode warnings stay accurate after switching accounts, even when a policy cache miss happens.
• Avoid false context exhaustion and rollover refusal when tool definitions are deferred
• Custom agents that declare the documented search, web or todo tool aliases, or name github-mcp-server/web_search, now receive the matching tools
• CLI help and version flags exit reliably after printing their output
• Enterprise-managed ask permissions in Assisted mode now allow safe actions without unnecessary confirmation prompts.
• Keep your selected Microsoft Entra account pinned during sign-in and token renewal
• Up from sessions sidebar header actions wraps to the last visible session

Original source

Added

• Open /share without arguments to view a full-screen action menu for sharing the current session

Improved

• /sandbox can keep sandboxing enabled for the current session without enabling it globally
• Trusted repository plugins install and update automatically before chat runs.
• Rename the built-in browser plugin to browser-use and keep existing browser plugin preferences working after upgrade
• Sandbox allows local network access by default so commands can reach localhost and private-network services.

Fixed

• Plan, autopilot, and shell mode badges stay visible while startup components load and the agent works. The badge replaces the mode suffix that used to trail the activity text (Working - plan), and the startup Loading: row now truncates its diagnostics to keep the status row on one line
• Sandboxed commands can write package and build caches when developer tool access is enabled.
• Windows CLI Git commands now recover from thread-access-denied startup failures.
• A skill allowed-tools rule keeps commas inside its arguments instead of being split apart. Where a list's structure is ambiguous, its unscoped rules now prompt instead of being granted.
• MCP resource dashboard stays interactive while inventory adapters refresh
• Retry image-bearing Responses requests with smaller payload limits when providers reject oversized bodies
• Complete usage reporting no longer shows partial status or phantom unattributed spend after resume when billing data is complete.
• Assisted permissions send nested PowerShell and bash -c commands that only expand plain-data environment variables, single-quoted PowerShell, and PowerShell variable and alias statements to the permission judge instead of requiring unnecessary manual approval
• Path-specific instruction files in the repository root .github/instructions are now applied automatically when the agent reads or edits a matching file
• Start git, shell commands, and MCP servers on Windows when process snapshot thread enumeration fails

Original source

In September, we experienced two incidents that resulted in degraded performance across GitHub services.

Our last update covered content through August. We did not publish another in September while other public content addressed the August 17 outage. This edition covers progress over the past two months.

The short version of August and September: we reduced shared-database pressure, added overload controls, created headroom for GitHub Actions, expanded failure containment for pull requests, and moved more production workloads to Azure. Significant incidents, a capacity pause, and a missed migration target show that the work is not complete.

By October 7, 120 of 160 production services were deployed in Central US, and 13 of 51 primary MySQL databases had moved. Azure also handled 65.4% of read traffic for GitHub’s core application, 48.3% of Git read traffic, and 80.2% of stream-processing traffic. These percentages measure different workloads and should not be added.

We paused Central US deployments and traffic increases on September 11 because capacity was uneven across availability zones. Permanent ramps resumed September 18 after temporary relief, but durable capacity work continues, with a goal of unlocking all available capacity by the end of October. We missed our aggressive September 30 goal to deploy every production service there. During a planned database failover, an automated emergency process disconnected Central US database copies and disrupted customers in that region. We disabled that process during planned handoffs while improving recovery.

Outside the regional migration, 24 authentication-core tables moved off GitHub’s oldest shared database, removing approximately one million queries per second from its replicas. The database cluster supporting issues and pull requests removed approximately 980 million unnecessary edit-history rows, creating an estimated 1.8 terabytes of recoverable storage. Weekly deadlocks fell approximately 77% from their June peak, and continuous cleanup now prevents the same unbounded growth from returning.

Half of sampled pull request traffic can now continue with limited functionality when a shared dependency fails. Production results showed several read operations remained available during a shared-database incident. Database traffic routing can also add capacity automatically during spikes; one group expanded from 14 to 19 instances during a September 23 increase in pull request activity. A production overload control now lets responders protect higher-priority API and web workflows by rejecting lower-priority requests before broader saturation. Operator documentation and training are complete.

GitHub Actions also gained operating headroom. Production changes reduced measured Redis operations by approximately 28% and relative CPU by approximately 30%. A separate infrastructure cache reduced Redis bandwidth by 84%, average response time by 66%, median response time for the primary inventory request by 96%, and queued requests by 95%.

The August 6 actions outage, August 17 github.com outage, September failover disruption, and controlled capacity pause are reminders that measured improvements matter only when they reduce customer risk under real conditions. The principle remains the same: availability, then capacity, then features.

September 13 09:16 UTC (lasting 1 hour and 28 minutes)

What happened?

Impact summary

Duration: approximately 2 hours

Customers may have seen requests fail, run slowly, or remain pending when opening or updating issues and pull requests, calling APIs, creating access tokens, starting GitHub Actions workflows, or signing up.

~96% of the customer requests creating issues through the web interface were impacted during the incident window. In addition, 90% of new customer signup and ~4% of actions workflows also experienced intermittent failures.

What went wrong and why?

A background data-cleanup job increased load on a shared database. The job had a safeguard designed to slow its writes when database replicas fell behind, but the safeguard did not account for incoming load on the primary database server. As a result, the job continued running until the primary reached its connections limit. When the primary ran out of available connections, requests that depended on it could not complete reliably.

Two other factors increased the impact and delayed recovery. First, there was no quick timeout on these database calls, so request handlers waited on the stalled database instead of failing fast. Second, a retry loop around token creation kept resending writes that were already failing, which held the database saturated rather than letting it recover.

How did we respond?

1. A background data-cleanup job began writing to a shared database.
2. The job’s safeguard monitored replica lag but did not account for load building on the database’s primary server.
3. The primary ran out of available connections, causing requests across dependent services to fail or run slowly.
4. Automated monitoring detected the incident, and we traced the failures to load on the shared database.
5. We reduced internal load and paused the background job.
6. The database recovered, and error rates across the affected services returned to normal.

How are we making incidents like this less likely or less impactful?

• We are implementing additional safeguards to improve database resilience and service availability. These measures will better control background processing based on available database capacity, reduce unnecessary retries during failures, and limit the impact of slow database requests.
• We are also improving service startup behavior to ensure that temporary database connectivity issues do not unnecessarily affect service recovery.

September 28 21:16 UTC (lasting 52 minutes)

What happened?

Impact summary

Duration: approximately 2 hours and 45 minutes

This incident impacted Copilot code review across github.com and GHEC data-residency regions. Affected customers saw Copilot remain in a reviewing state without a review appearing, with delays ranging from ~30 minutes to a max of 2 hours.

Some reviews on github.com continued to complete normally during the incident, while reviews in data-residency regions did not. Some customers still received delayed error messages for requests made during the incident.

What went wrong and why?

Copilot code review uses a separate service to run reviews and 2 versions of the results are returned: a limited copy that excludes the review comments and a full copy that includes the completed review. Copilot code review posts reviews only from the full copy. A change to that service began sending the full copy only for some customers. For other customers, only the limited copy was sent.

As a result, Copilot code review could not build a review, but reported that the job had completed successfully. The missing review results were not detected due to lack of monitoring. The incident was detected as some of the reviews remained incomplete for more than 30 minutes, triggering an alert to first responders.

We mitigated the incident by reverting the change.

How did we respond?

1. A change to the service that runs Copilot code reviews began rolling out, and review results stopped appearing on pull requests. The change reached every environment.
2. Reviews began timing out, triggering an alert to the Copilot code review team. We declared an incident.
3. We traced the failures to the change and began reverting it.
4. While the revert completed its required checks, we posted the incident on the GitHub Status page.
5. The revert then reached all the affected regions. We resolved the incident and advised customers to request affected reviews again.

How are we making incidents like this less likely or less impactful?

• We are strengthening the reliability of Copilot code reviews by adding safeguards throughout the review and delivery process. These improvements will help ensure that completed reviews are delivered successfully, allow failed reviews to recover automatically, and provide earlier notification when issues occur.
• We are also improving our monitoring and deployment processes so that problems can be identified and addressed more quickly.

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.

Original source