On February 9th, 2026, Docker and Docker Compose will be updated on all Windows and Ubuntu runner images except ubuntu-slim. This update allows you to take advantage of the latest features in these tools.

New Versions

• Docker Engine: v29.1
• Docker Compose: v2.40 (or higher if new v2 minor versions release before our change)

You may need to update your workflows if you rely on Docker functionality slated for removal in v29.

Keep up to date on upcoming runner image changes

We regularly update runner images for improved performance, enhanced functionality, and security improvements. You can find a list of other upcoming changes, updates, and deprecations to runner images in the runner-images repository. Check regularly to confirm that your runner images will not be impacted by any scheduled updates.

The post Docker and Docker Compose version upgrades on hosted runners appeared first on The GitHub Blog.

GitHub Codespaces is now available in public preview for GitHub Enterprise Cloud with data residency. You can now use secure, configurable, instantly available cloud development environments while maintaining strict compliance with your data residency requirements. Functionality is identical to Codespaces on the general GitHub platform, with the available regions limited to those within your account’s selected region.

What’s new

Codespaces for data resident customers provides:

• Full feature parity: Access to the complete GitHub Codespaces feature set, including all policies and configurations available in the general offering.
• Data residency compliance: All sensitive data remains within your selected region.
• Regional availability: Codespaces are available in the following data residency regions:
  • Australia
  • EU
  • US
  • Japan (coming during preview, before general availability)

Important considerations

To maintain strict data residency, enterprise or organization-owned codespaces are required. User-owned codespaces are not supported for GitHub Enterprise Cloud with data residency accounts. Please ensure your enterprise or organization policies are configured to set proper ownership for Codespaces usage. More information can be found in our documentation on codespace ownership.

Learn more about GitHub Codespaces and GitHub Enterprise with data residency.

The post Codespaces is now in public preview for GitHub Enterprise with data residency appeared first on The GitHub Blog.

CodeQL is the static analysis engine behind GitHub code scanning, which finds and remediates security issues in your code. We’ve recently released CodeQL 2.24.0, which adds support for new language versions, expands framework coverage, and improves query accuracy across multiple languages.

Language and framework support

Swift

• We’ve updated CodeQL to support analysis of apps built with Swift 6.2.2 and 6.2.3.

C#

• We’ve added support for .NET 10 and C# 14.

JavaScript/TypeScript

• CodeQL now treats JavaScript files with an average line length greater than 200 as minified and won’t analyze them. For scenarios where minified JavaScript files should be analyzed, you can set the environment variable CODEQL_EXTRACTOR_JAVASCRIPT_ALLOW_MINIFIED_FILES=true.
• We’ve added support for Next.js 16’s use cache directives.
• We’ve added support for the React useRef hook, with improved data flow tracking through the current property.

Python

• The py/decompression-bomb query now supports the compression.zstd library (added in Python 3.14).
• We’ve added taint flow models for urllib.parse and remote flow sources for the python-socketio package.
• The extractor now analyzes files in hidden directories by default.

Java/Kotlin

• We’ve added sink models for com.couchbase supporting SQL injection and hardcoded credentials queries.
• We’ve added more dataflow models of org.apache.commons.fileupload.FileItem, javax/jakarta.servlet.http.Part, and org.apache.commons.fileupload.util.Streams.

C/C++

• We’ve added support for more Windows APIs, including file read functions, command-line and environment variable APIs, and flow models for SQLite and OpenSSL libraries.

Rust

• Method resolution now considers the Deref trait, which means method calls on receivers implementing the Deref trait will correctly resolve to methods defined on the target type.
• We’ve added support for the Axum web application framework.
• We’ve improved type inference for raw pointers, including type inference for the raw borrow operators and dereferencing of raw pointers.

Query changes

C#

• We’ve extended the Missing cross-site request forgery token validation query to support ASP.NET Core.
• We’ve added NHibernate.ISession.CreateSQLQuery, NHibernate.IStatelessSession.CreateSQLQuery, and NHibernate.Impl.AbstractSessionImpl.CreateSQLQuery as SQL injection sinks.
• We’ve added implicit reads of System.Collections.Generic.KeyValuePair.Value at taint-tracking sinks and at inputs to additional taint steps. As a result, taint-tracking queries will now produce more results when a container is tainted.

JavaScript/TypeScript

• We’ve fixed a bug in the Next.js model that would cause the analysis to miss server-side taint sources in files named route or page appearing outside api and pages folders.
• new Response(x) is no longer seen as a reflected XSS sink when no content-type header is set, since the content type defaults to text/plain.

Java/Kotlin

• Java thread safety analysis now understands initialization to thread-safe classes inside constructors.
• We’ve added a sanitizer to java/ssrf to remove alerts when a regular expression check verifies that the value is safe.
• URI template variables of all Spring RestTemplate methods are now considered as request forgery sinks, which may lead to more alerts for the query java/ssrf.

C/C++

• We’ve improved the accuracy of the cpp/constant-comparison query to reduce false positives.

Rust

• We’ve improved the accuracy of the rust/unused-variable, rust/unused-value, rust/access-invalid-pointer, and rust/access-after-lifetime-ended queries to reduce false positives.
• We’ve extended the rust/hard-coded-cryptographic-value query with new heuristic sinks identifying passwords, initialization vectors, nonces, and salts.

For a full list of changes, please refer to the complete changelog for version 2.24.0. Every new version of CodeQL is automatically deployed to users of GitHub code scanning on github.com. The new functionality in CodeQL 2.24.0 will also be included in a future GitHub Enterprise Server (GHES) release. If you use an older version of GHES, you can manually upgrade your CodeQL version.

The post CodeQL 2.24.0 adds Swift 6.2 and .NET 10 support, and improves file handling for minified JavaScript appeared first on The GitHub Blog.

We know how important data residency is for compliance and regional requirements. To that point, the Copilot usage, code generation dashboards, and corresponding API are now available to customers on GitHub Enterprise Cloud with data residency.

What’s included?

Customers on GitHub Enterprise Cloud with data residency can now see the following information:

• Copilot usage dashboard: Get clear, actionable insights into how your teams are using GitHub Copilot. The dashboard provides visibility into code completion activity, IDE usage, lines of code generated, and more.
• Code generation dashboard: Observe Copilot’s output by quantifying the lines it suggested, added, or deleted across completions, chat, and agent features.
• Fine-grain permissions: Access the APIs and dashboard if you are assigned the View enterprise Copilot metrics enterprise role. This means that all users assigned this role, not just enterprise admins or billing managers, are empowered to view granular Copilot usage metrics for the enterprise.
• Organization usage: Programmatically access your organization’s own Copilot adoption and usage metrics, including usage statistics for various Copilot features, user engagement data, and feature adoption metrics. For more information, see our API documentation.
• API access: Programmatically access Copilot usage data across your organization for custom reporting, monitoring, compliance, and advanced analytics.

Availability

• For existing GitHub Enterprise Cloud customers migrating to GitHub Enterprise Cloud with data residency, note that usage data will be split across enterprises. Historical usage will remain associated with your existing enterprise, while usage after migration will be attributed to the new data residency enterprise due to account changes.
• If users are logged into multiple GitHub accounts within the IDE, usage generated will all be attributed to the GitHub Enterprise Cloud with data residency account and not shared across other accounts.
• To access the dashboard, navigate to your enterprise account → “AI Controls” → “Copilot” → “Metrics” → “Copilot usage metrics”. You should then see the dashboard under “Insights” → “Copilot usage” or “Code generation”. Please also ensure you are either an enterprise administrator, billing manager, or have the proper fine-grained permissions that grant you access to Copilot metrics.
• For API access, visit our Copilot usage metrics API documentation.

Join the discussion within GitHub Community.

The post Copilot metrics in GitHub Enterprise Cloud with data residency in public preview appeared first on The GitHub Blog.

We’ve shipped several improvements to GitHub Actions that make it easier to write, validate, and troubleshoot workflow logic, especially when you rely on if: conditionals to control what runs.

Here are some of the new improvements:

• A new case function for more expressive conditional logic
• Expanded expression logs so you can see why jobs get skipped.
• Better workflow authoring across VS Code, web editor, and other IDEs
• Editor support for action.yml files
• Better if: condition handling

Write more expressive expressions with a case function

GitHub Actions expressions now support a case function which can perform true logical operations, similar to a case expression in SQL. This lets you handle many different types of logical operations including if-else, if-else if, if-else if-else and even switch-case. This function also uses booleans so it avoids the limitations of current workarounds. You can find more information about the case function in the expressions documentation.

Understand why jobs get skipped

When a job is skipped because of an if: conditional, you can now see exactly why. The job logs show the original expression alongside an expanded version with all values from contexts at runtime. You can find details on how to access these logs in the job condition logs documentation.

Better workflow authoring across editors

We’ve brought the enhanced workflow authoring experience from the GitHub Actions VS Code extension to the web editor and other IDEs. Improvements include:

• Smarter autocomplete: Context-aware completions for expressions, event payloads, needs outputs, and matrix values.
• Expression validation: Catches invalid context access, unrecognized functions, and literal text in if conditions.
• Hover documentation: View function signatures and context descriptions inline.
• Standalone binary: Use the language service in NeoVim, Emacs, Sublime, or other editors.
• Plus inline cron schedule hints, smarter syntax completions, and more.

Editor support for action.yml files

Action authors now get the same editing experience as workflow authors. When you open an action.yml file in VS Code, the web editor, or any editor using the standalone binary, you’ll get:

• Autocomplete for action metadata fields (name, description, inputs, outputs, runs, etc.).
• Context-aware runs completions that filter based on your action type (Node.js, composite, or Docker).
• Validation for schema compliance, required fields, and expressions.
• Scaffolding snippets to quickly bootstrap new actions.

Better if: condition handling

We’ve added improvements to catch common pitfalls with if: conditions and other workflow fields. Specifically:

• if conditions with text outside the ${{ }} markers, which makes the whole expression a string (always truthy). This will be caught by editor validation in VS Code and the web editor, and produces an annotation on the workflow run.
• Invalid format strings. This will also be caught by the editor validation.
• Trailing newlines will automatically be trimmed.

What this means in practice

• Fewer surprise jobs and steps from always-truthy strings.
• Earlier feedback on malformed conditions.

From authoring to debugging, your workflow experience just got smoother.

Join the discussion within GitHub Community.

The post GitHub Actions: Smarter editing, clearer debugging, and a new case function appeared first on The GitHub Blog.

Linux and Windows arm64 standard GitHub-hosted runners are now supported in private repositories. You can now use these free-tier eligible arm64 runners in all repositories, letting you take advantage of the performance benefits of arm64 processors and run native multi-architecture builds without the overhead of virtualization or emulation.

Because these are standard GitHub-hosted runners, usage counts towards the free minutes included in your plan.

What’s new

• Linux and Windows arm64 standard hosted runners are now supported in all repositories.
• In private repositories, these runners have two vCPUs; in public repositories, they have four vCPUs.
• These runners use an arm64 processor and images managed by Arm, LLC.

As standard GitHub-hosted runners, they are eligible for use towards your GitHub plan’s free minute allocation in private repositories. macOS arm64 standard runners are already available for private repositories. This update extends private repository arm64 support to Linux and Windows.

This is ideal for teams targeting arm64 production, such as containerized services or multi-architecture builds, who want native performance using standard GitHub-hosted runners in private repositories.

Get started

To start building on arm64, add one of the following supported labels to the runs-on field in your workflow:

• windows-11-arm
• ubuntu-24.04-arm
• ubuntu-22.04-arm

For more details on arm64 runners and usage, see our documentation for standard GitHub-hosted runners.

These runners are fully supported standard GitHub-hosted runners and are suitable for production CI workloads.

Join the discussion within GitHub Community.

The post arm64 standard runners are now available in private repositories appeared first on The GitHub Blog.

We are closing down three legacy Copilot metrics APIs as part of our transition to newer, more comprehensive usage metrics endpoints. Support for these APIs will be limited, and no new features will be developed.

• The User-level Feature Engagement Metrics API and Direct Data Access API will sunset on March 2nd, 2026.
• The Copilot Metrics API will sunset on April 2nd, 2026.

We strongly recommend transitioning any existing workflows to the latest Copilot usage metrics endpoints to avoid disruption.

What do these APIs do?

These APIs provide visibility into adoption and usage of GitHub Copilot features:

• User-level Feature Engagement Metrics API offers a simplified view of user adoption of specific Copilot features through binary indicators.
• Direct Data Access API provides user-level event data for Copilot code completion activity within supported IDEs.
• Copilot Metrics API provides aggregated usage metrics, primarily focused on IDE usage.

Why?

We have released a new set of Copilot usage metrics APIs that provide significantly more depth and flexibility. By consolidating to our latest APIs, we are able to:

• Provide a single, unified source of truth for Copilot metrics.
• Deliver more granular and valuable insights, including IDE agents, models, languages, lines of code, and fine-grained permissions.
• Reduce support overhead and streamline the product experience.

What’s recommended moving forward?

We recommend transitioning to the latest Copilot usage metrics APIs, which provide comprehensive usage data at the enterprise, organization, and user levels.

These endpoints return aggregated metrics with expanded IDE telemetry, including:

• Edit modes and agent usage.
• Suggested versus accepted lines of code.
• Language and model breakdowns.
• Additional usage dimensions not available in the legacy APIs.

The new APIs are currently in public preview and will be generally available in the near future.

The post Closing down notice of legacy Copilot metrics APIs appeared first on The GitHub Blog.

It’s now easier than ever to find exactly the issue you’re looking for with our improved search for GitHub Issues. Built on our new semantic index, you can now find results based on the meaning of your query, not just the keywords you use.

What’s new

Search for issues using natural language like “authentication failing on mobile” or “funny timeline behavior”, and GitHub returns conceptually similar results, even if the issue titles or descriptions use completely different wording. The more descriptive your query, the better your results.

Our prerelease testing has found that this is a significant improvement for users. Overall, results are 39% better with semantic search compared to traditional search.

How it works

Semantic search activates when you describe what you’re looking for in natural language. To make best use of this, results are now automatically ordered by “Best match” to surface the most relevant issues first.

For searches that need exact matching (e.g. queries with quotation marks) GitHub uses the traditional, lexical search engine to give you the precision you need.

During public preview, you can opt out using the feature preview dialog.

How to try it

Head to any repository’s Issues tab and search using natural language. We’d love to hear what you think. Share your experience in our community discussion post.

Additional improvements to issues and projects

• We’ve fixed a bug causing slow performance when searching for labels on Edge and Safari.
• A Safari based scrolling bug impacting GitHub Issues is now fixed for smoother scroll behaviour.
• Milestone ordering works consistently for both open and closed issues.

The post Improved search for GitHub Issues in public preview appeared first on The GitHub Blog.

GitHub Copilot CLI now implements the Agent Client Protocol (ACP), an industry-standard protocol for communication between AI agents and clients. This enables third-party tools, IDEs, and automation systems to integrate directly with Copilot’s agentic capabilities through an extensible interface.

How it works

You can start Copilot in ACP mode via stdio: copilot --acp

Or connect via TCP on a specific port: copilot --acp --port 8080

ACP clients can then:

• Initialize a connection and discover agent capabilities.
• Create isolated sessions with custom working directories.
• Send prompts with text, images, and context resources.
• Receive streaming updates as the agent works.
• Respond to permission requests for tool execution.
• Cancel operations and manage session lifecycle.

Use cases

• IDE integrations: Build Copilot support into any editor or development environment.
• CI/CD pipelines: Orchestrate agentic coding tasks in automated workflows.
• Custom frontends: Create specialized interfaces for specific developer workflows.
• Multi-agent systems: Coordinate Copilot with other AI agents using a standard protocol.

Learn more in our ACP documentation and join the discussion within GitHub Community.

The post ACP support in Copilot CLI is now in public preview appeared first on The GitHub Blog.

The GitHub MCP Server has arrived with improved capabilities to manage GitHub Projects with more efficient usage of the context window, automatic tool filtering based on your token’s permissions, and features including Insiders and HTTP server mode!

Visit the GitHub MCP Server repository to learn more.

Consolidated GitHub Projects toolset

Previously, the Projects toolset, as with other now-consolidated toolsets, used a significant portion of the context window for the tools list. As a result, we’ve reduced token usage by around 23,000 tokens (50%). Managing GitHub Projects is now simpler with a new consolidated set of tools that replace the previous approach. The new projects toolset provides unified access to project management capabilities:

• projects_list: List projects for a user, organization, or repository.
• projects_get: Retrieve detailed information about a specific project, including fields and items.
• projects_write: Create, update, and manage project items with full field support.

The consolidated tools handle owner type detection automatically—you no longer need to specify whether the owner is a user or organization.

OAuth scope filtering

The GitHub MCP Server now manages tool availability based on your authentication method.

When using a classic Personal Access Token (ghp_ prefix), the server automatically detects your token’s OAuth scopes and hides tools you don’t have permission to use. This reduces clutter and prevents errors from attempting operations your token can’t perform. To learn more about creating a personal access token (PAT) for yourself, check out our docs on managing your personal access tokens.

How it works

1. At startup, the server detects if your token is a classic PAT.
2. It discovers your token’s scopes via a lightweight API call.
3. Tools requiring scopes your token doesn’t have are automatically hidden.

Insiders mode for experimental features

We’re introducing Insiders mode, an opt-in mechanism that lets you access experimental and preview functionality in the GitHub MCP Server. This will be available for both local and remote server deployments.

How it works

• Users explicitly opt in by setting a configuration header or using the new /insiders URL.
• When enabled, the MCP Server grants access to experimental features, behavior changes under evaluation, and functionality not yet generally available.
• Removing the header or reverting to the standard URL instantly restores standard generally available behavior.

HTTP server mode with OAuth support

Enterprise users are now able to run the GitHub MCP Server in HTTP mode with OAuth token support.

What’s coming

• HTTP server mode: Run the local MCP server as an HTTP server on a configurable port.
• Per-request OAuth tokens: Support tokens via Authorization header.
• Fallback support: Falls back to GITHUB_PERSONAL_ACCESS_TOKEN if no header is provided.
• Enterprise Server compatibility: Full support for GitHub Enterprise Server deployments.

This allows enterprise teams to deploy a shared MCP server with OAuth token forwarding, eliminating the need for every user to manage their own personal access tokens.

Copilot coding agent tools

The GitHub MCP Server adds new tools and improvements for working with the Copilot coding agent.

The new get_copilot_job_status tool lets you check on Copilot’s progress. You can query by job ID or pull request number.

Both assign_copilot_to_issue and create_pull_request_with_copilot now support a base_ref parameter:

• Feature branches: Start Copilot’s work from any branch, not just the default.
• Stacked PRs: Build on existing work by specifying a feature branch as the base.
• Sequential tasks: Chain multiple Copilot assignments together.

Task assignments now return a job ID or pull request link immediately, so you can track status right away.

The assign_copilot_to_issue tool now supports custom instructions.

Getting started

To get started, enable the copilot toolset.

Visit the GitHub MCP Server repository to learn more.

Try out these features today! If you have feedback, please open an issue in our open-source GitHub MCP Server repository.

The post GitHub MCP Server: New Projects tools, OAuth scope filtering, and new features appeared first on The GitHub Blog.