GitHub Release Notes

GitHub Enterprise Server (GHES) 3.21 enhances deployment efficiency, monitoring capabilities, code security, and policy management. Here are a few highlights in the 3.21 release:

Organization custom properties are now generally available, giving enterprise administrators a way to tag organizations with metadata and automatically target enterprise rulesets. For more information, see organization custom properties.

Hierarchy view for GitHub Projects is now generally available. You can now view your full issue hierarchy directly in project table views, giving you clear visibility into complex work breakdowns without losing context or switching views. For more information, see hierarchy view.

REST API version 2026-03-10 is now available and introduces breaking changes. Existing integrations on version 2022-11-28 will continue to be fully supported for at least 24 months from the 3.21 release date. For more information, see REST API version 2026-03-10.

GitHub Actions workflow pages now successfully render workflows with more than 300 jobs. We’ve implemented lazy loading to smoothly handle large workflows. In addition, you can now filter jobs based on status (e.g., failed or in-progress) directly from the workflow pages. For more information, see improved performance for GitHub Actions workflows page.

This version includes improvements to alert-level and enterprise-level permissions for secret scanning. You can now more easily manage secret scanning alerts, custom patterns, and push protection bypasses. For more information, see enterprise governance and policy improvements for secret scanning.

Configuring multiple data disks to host MySQL and repository data is now generally available. This applies to standalone and high availability topologies and is available in the latest patches of 3.17, 3.18, 3.19, and 3.20, and in 3.21. For more information, see configuring multiple data disks.

To learn more about GHES 3.21, check out the release notes, or download it now. If you have any issues upgrading to version 3.21 or experience any issues using these new features, please contact our support team.

Join the community discussion to share your feedback and ask questions.

The post GitHub Enterprise Server 3.21 is now generally available appeared first on The GitHub Blog.

Pull requests created by the github-actions[bot] are now able to run your CI/CD workflows with user approval. Requiring approval is a security measure to ensure generated code does not automatically run workflows which may have access to sensitive information. This matches the behavior of Copilot-generated pull requests.

Previously, pull requests generated by github-actions[bot] were not able to run CI/CD workflows, allowing pull requests to be accidentally merged without having gone through CI. This change allows all pull requests, even bot-generated changes, to run configured CI/CD workflows if approved by a user with write access to the repository.

The post Bot-created pull requests can run workflows if approved appeared first on The GitHub Blog.

Your AI usage reports now reflect GitHub AI Credits usage in the standard report fields.

To monitor AI credit usage going forward, use quantity for AI credit quantity and gross_amount for the dollar amount. These fields now provide the same signal that aic_quantity and aic_gross_amount previously provided during the preview period.

We added aic_quantity and aic_gross_amount as a preview before AI credits became the native billing model on June 1. After that change, those preview fields were no longer meaningful for AI credit usage and should have been zeroed. A bug caused those values to persist until a fix was deployed. That fix retroactively zeroed those columns for AI credit usage from June 1 forward.

Reports from before June 1 are unchanged, so your historical analysis will continue to work as expected.

This fix is already available for GitHub Enterprise Cloud customers.

The post AI usage report updates appeared first on The GitHub Blog.

One command, three ways to use it

GitHub Copilot CLI now has a unified, schema-driven home for configuration. The new /settings slash command combines the scattered commands like /theme, /streamer-mode, and /experimental with options that previously required manually editing your settings file into a single, discoverable surface.

/settings works whether you want a guided UI, a quick one-liner, or a scripted change in a copilot -p invocation:

• /settings opens a full-screen, sectioned dialog where you can browse and edit every user setting.
• /settings sets a value inline (e.g., /settings autoUpdate true, /settings sessionSync.level full).
• /settings reset restores the default for a setting.

Keys are dotted paths into the CLI’s settings schema, and tab completion surfaces every available key — along with the description and the allowed values for booleans, enums, and enum-or-string unions — right next to your prompt. No more guessing key names or types.

A dialog that fits each setting

Open /settings with no arguments and you get a searchable, alt-screen dialog with editors built for each setting type:

• Boolean toggles, enum pickers, and enum-or-string union pickers.
• Free-form string and number editors, with a multi-line editor for prose.
• Dedicated editors for string and number arrays and generic records.
• A $EDITOR fallback for complex JSON containers.

Your settings file is only written after the new value parses and passes schema validation, so a typo can’t silently break your next session.

Press / to search, Ctrl+R to reset the focused setting to its default, and Ctrl+E to open the active settings file in your editor. Setting changes that have side effects (like colorMode or streamerMode) apply live the moment you save, whether you toggled them inline, reset them, or edited the file directly.

Want to jump straight to a specific setting? /settings and /settings reset open the dialog focused on that key.

Get the update

Update GitHub Copilot CLI by running copilot update in your terminal, then run /settings to take it for a spin. Share feedback with the /feedback command in a CLI session, or open an issue in our public repository.

The post Copilot CLI: Configure everything from one place with /settings appeared first on The GitHub Blog.

Ubuntu 26.04

Two new GitHub-hosted runner images for GitHub Actions are now available in public preview for all users, giving you early access to test your workflows on the latest platforms before they reach general availability.

The Ubuntu 26.04 image is now available for both x64 and arm64 architectures. To start using it, update your workflow file to use runs-on: ubuntu-26.04 or runs-on: ubuntu-26.04-arm. Ubuntu 26.04 base images are also available for larger runner users.

Some users may notice differences in their workflows as the Ubuntu 26.04 image has different tools and tool versions compared to earlier images. For the full list, head to the runner-images repository.

Windows 11 arm64 with Visual Studio 2026

A new Windows 11 arm64 image with Visual Studio 2026 is now available under the label windows-11-vs2026-arm. This image provides an early, stable environment to validate your CI workloads against the Visual Studio 2026 toolchain on Windows arm64 without disrupting existing pipelines. See the runner-images repository announcement for more information.

This image runs in parallel with the existing Windows 11 arm64 image for a limited period, allowing you to adopt and test at your own pace. At the end of the public preview in early September, the existing windows-11-arm image label will migrate to the vs2026 image. We will notify users ahead of the migration to give them time to prepare.

If you spot any issues with your workflows when using these new images, or if you have feedback on the software installed, head to the runner-images repository.

While these images are in preview, you may experience longer queue times during peak usage hours.

The post New runner images in public preview appeared first on The GitHub Blog.

GitHub Agentic Workflows is now in public preview. With agentic workflows, you can automate reasoning-based tasks like issue triage, CI failure analysis, and documentation updates by leveraging coding agents inside GitHub Actions.

Define your automation in natural language Markdown files, and GitHub Agentic Workflows compiles them into standard Actions YAML. Because these are just actions, they reuse your existing runner groups and policy constraints.

“With GitHub Agentic Workflows, we’re able to expand how we apply agents to real engineering work at scale, including changes that span multiple repositories. The flexibility and built-in controls give us confidence to leverage agentic workflows across complex systems at Carvana.”

– Alex Devkar, senior vice president, Engineering and Analytics at Carvana

“Our developers were losing hours every sprint to repetitive work such as triaging issues, remediating vulnerabilities, maintaining dependencies, and reviewing routine changes. With GitHub Agentic Workflows, we’ve built a catalogue of reusable workflows spanning security, quality, and delivery that our teams can adopt across any repository. What once required hours of engineering effort can now be completed autonomously in minutes, meaning our teams can spend more time focused on innovation and delivering value to customers.”

– James Hoare, CTO, Engineering at Marks & Spencer

Security-first by design

GitHub Agentic Workflows incorporates layered safeguards to your automation. Agents access GitHub content respecting the integrity filter rules, run with read-only permissions by default, and execute inside a sandboxed container behind the Agent Workflow Firewall. The outputs are validated through the safe outputs process, and a dedicated threat detection job scans all proposed changes before they are applied.

“Getting an agent to open a pull request was never the hard part. Trusting it enough to merge is. GitHub Agentic Workflows put agents to work across the whole SDLC, automating the checks that make sure your code won’t degrade performance or break production. With agentic workflows, we can give our customers confidence that their ‘ready to merge’ PRs are actually safe to merge.”

– May Walter, CTO at Hud.io

Get started

Follow the quickstart guide to install the CLI extension and trigger your first workflow in minutes. Explore prebuilt workflows in GitHub Next’s agentics repository for ready-to-use examples covering triage, reporting, compliance, and more.

Join the conversation and share your feedback in the community discussion.

The post GitHub Agentic Workflows is now in public preview appeared first on The GitHub Blog.

You can now use GitHub Agentic Workflows with GitHub Actions’s built-in GITHUB_TOKEN.

This means that you no longer need to create and store a personal access token (PAT), eliminating the operational and security risks of managing long-lived PATs for automations at scale.

When you use the Actions token in an agentic workflow running in an organization-owned repository, AI credits consumed by your agentic workflow are billed directly to the organization.

Configuring organization billing for Copilot CLI in GitHub Agentic Workflows

In order to use this feature, you must enable the “Allow use of Copilot CLI billed to the organization” Copilot policy. This is enabled by default if you have the existing “Copilot CLI” policy enabled.

Once enabled, you can configure agentic workflows to bill directly to the organization by adding copilot-requests: write to the permissions section in the frontmatter of your agentic workflow markdown file, then compiling and pushing your updated lockfile.

Note: You must be on the latest version of the Agentic Workflows CLI. Use $ gh extension upgrade aw to upgrade.

Controlling cost while billing to your organization

User-level inference budgets are not considered when billing directly to the organization, because the cost is not attributed to a user. There are multiple ways to manage spend when using this billing method:

• Configure cost centers for the relevant organizations. Cost centers allow cost attribution to groups of organizations, and budgets can be applied to cost centers.
• Use the cost management tools in GitHub Agentic Workflows to monitor, manage, and cap token usage per agentic workflow run.

To learn more, see the GitHub Agentic Workflows documentation about authentication.

This feature is available for all Copilot plans: Copilot Free, Copilot Pro, Copilot Pro+, Copilot Business, and Copilot Enterprise.

The post Agentic workflows no longer need a personal access token appeared first on The GitHub Blog.

GitHub Discussions now has a first-class home in GitHub CLI through the new gh discussion command group. This means you can browse, create, and update discussions right where you already work, without falling back to raw gh api calls.

The new command group covers the core workflows you reach for most:

• gh discussion list to scan recent discussions in a repository
• gh discussion view to read a discussion and its replies in the terminal
• gh discussion create to start a new discussion
• gh discussion edit to update an existing discussion
• gh discussion comment to comment on a discussion

Install or upgrade to GitHub CLI v2.94.0 to get started on any repository where GitHub Discussions is enabled.

Have feedback or found an issue? Open an issue in the cli/cli repository.

The post List, view, and create discussions in GitHub CLI appeared first on The GitHub Blog.

GitHub CLI now exposes issue types, parent and sub-issue relationships, and issue dependencies directly from the terminal. This means you can structure and track work without dropping into the browser or writing raw gh api scripts. These are exactly the workflows that both developers, and the coding agents that increasingly rely on gh as their interface to GitHub, run every day.

Advanced issue features in gh issue

As of v2.94.0, you can now work with issue hierarchy, types, and dependencies directly from gh:

• Issue types: Set a type on create or edit, and filter by type in gh issue list.
• Sub-issues: Link, change, or remove a parent with --parent, --set-parent, and --remove-parent.
• Issue dependencies: Mark blocked-by and blocking relationships with the new --blocked-by and --blocking flags, plus their --add-* and --remove-* variants.

gh issue view and gh issue list also expose parent, sub-issue, type, and dependency data as new JSON fields, so your automation can read and act on issue structure reliably.

Anyone on GitHub CLI v2.94.0 or later can use the new hierarchy and dependency support in any repository where those features are available. Issue types are configured at the organization level, so type support applies to issues in organizations that have defined them.

Install or upgrade to GitHub CLI v2.94.0 today to get started.

Have feedback or found an issue? Open an issue in the cli/cli repository.

The post Manage sub-issues, types, and dependencies from GitHub CLI appeared first on The GitHub Blog.

We’ve improved the handoff experience between Copilot Chat and Copilot cloud agent on the web. We’ve also enabled new functionality which allows you to search and query past agent sessions in chat.

What’s changed

When you kick off an agent session by asking chat to create a session, create a pull request, or do deep research on a repository, chat now reflects the status of your in-progress session. When a session is complete, you can ask follow-up questions on the session or kick off another session from chat.

Two new tools have been enabled in Copilot Chat:

• Get agent logs: Pull in session logs from a Copilot cloud agent’s work on a pull request so you can ask about what changed, what was validated, and why. And you can do this right in the conversation.
• Session search: Find and summarize past agent sessions by topic, title, or recency, making it easy to pick up where previous work left off.

Join the discussion within GitHub Community.

The post Copilot Chat now sees your agent sessions appeared first on The GitHub Blog.

The maximum number of cost centers you can create per enterprise has doubled from 250 to 500.

If your enterprise spans hundreds or thousands of business units, departments, or product groups, you can now map cost centers more closely to your internal structure. That means more granular tracking, allocation, and reporting of usage and spend across your organization, without running into the previous limit.

This higher limit is available now for GitHub Enterprise Cloud customers and applies automatically, so there is nothing you need to turn on.

Learn more about creating and managing cost centers.

The post Enterprises can now create up to 500 cost centers appeared first on The GitHub Blog.

You can now run a security review on your code changes directly from GitHub Copilot CLI. The new /security-review slash command is shipping as an experimental feature in public preview, giving you a fast, AI-driven way to catch security vulnerabilities before they reach production code.

What it does

/security-review analyzes your local code changes and returns:

• High-confidence security findings, scored by severity and confidence.
• Actionable suggestions you can apply without leaving the terminal.
• A focused review that lives in your existing workflow.

The scan is tuned to flag common, high-impact vulnerability classes such as injection flaws, cross-site scripting, insecure data handling, path traversal, and weak cryptography.

This is a Copilot-driven scan that doesn’t rely on GitHub code scanning, Dependabot, or GitHub secret scanning. It complements those tools by giving you a lightweight, on-demand way to review your changes before you commit.

This is an experimental command. To try it, turn on experimental mode in Copilot CLI, then run /security-review in any project to scan your current changes.

Join the discussion and share your feedback within the GitHub Community.

The post Dedicated security review command now available in Copilot CLI appeared first on The GitHub Blog.

2026-06-09

Polish /agents picker and Create New Agent wizard with consistent borders, headers, and styled inputs

Fixed a bug where resuming a session could leave the screen blank

Add /settings interactive dialog to browse and edit all user settings in one place

Resuming a local session with memory disabled no longer crashes the UI to a blank screen

/after and /every commands now appear in the /experimental slash command list

Auto-load MCP servers from .github/mcp.json workspace config file

/env output hides internal hooks and shows full file paths for hook sources

Prevent crashes from malformed UTF-8, oversized string buffers, and terminal disconnect errors

Add support for Claude Fable 5 model

Gemini models work correctly with MCP tools that use nullable schema types

Number-key selection in pickers (e.g. /agent) works for items 10 and beyond

GitHub issue and PR references inside existing links no longer create broken nested autolinks

Bash tool correctly handles multi-byte UTF-8 characters (em dash, curly quotes, etc.) in command input

Symlinked directories now appear in @-file picker suggestions

MCP OAuth re-authentication correctly uses the saved OAuth client ID for remote servers

Pasted images no longer leak into the main prompt after a permission dialog closes

Press '/' in the /agent picker to filter agents by name

Configure home tab bar visibility, order, and hidden tabs via the tabs setting in settings.json

grep and glob tools correctly handle single path arguments, preventing missed search results

Hook progress status lines marked as temporary collapse in place instead of accumulating in the conversation timeline

/fork shows a "Creating fork..." progress notification while the fork is being created

/mcp search works correctly with external registries

Use natural language with /every and /after to schedule tasks using cron expressions, calendar times, or relative durations

Light theme secondary background color is now rendered correctly

Search bar match count stays inside the prompt frame

GitHub theme adapts to light terminals with an authentic GitHub Primer light color palette

Add mTLS and private-CA support for OTLP telemetry export over HTTPS

Fixed false positives in shell command validation that could block harmless commands containing words like "kill" in string literals or embedded documents (heredocs).

Add full screen scrollbar

Grep searches in large monorepos use an indexed search engine for significantly faster results

/sessions now navigates to the Sessions tab instead of opening an overlay

Add http/protobuf OTLP HTTP export via standard OTel protocol env vars

Prompt mode surfaces model-load errors on stderr instead of exiting silently

Add /worktree command (aliased /move) to create a new git worktree and switch into it, moving any uncommitted changes along

Plugin install enforces managed marketplace policy even when settings cannot be fetched due to network errors

/help now lists $HOME/.copilot/instructions/**/*.instructions.md alongside the other user-level instruction locations

Colors render correctly in WSL and tmux sessions instead of falling back to a degraded palette

Exit shell mode by pressing Esc or Ctrl+C on an empty prompt, in addition to Backspace

Add beepOnSchedule setting to disable completion beeps for scheduled /every and /after runs

Our next npm major version, v12, introduces security-related default changes to npm install.

All these changes are available behind warnings in npm today on 11.16.0 or newer, so you can prepare before the upgrade. v12 is estimated to release in July 2026.

Each change turns an npm install behavior that runs automatically today into one you explicitly opt into:

• allowScripts defaults to off: npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds (i.e., a package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild for it). prepare scripts from git, file, and link dependencies are blocked the same way. To see what would be blocked, run npm approve-scripts --allow-scripts-pending. Then allow the packages you trust with npm approve-scripts and block the rest with npm deny-scripts. The resulting allowlist is written to package.json and should be committed. If your install routine runs scripts, you can observe warnings in npm 11.16.0+.
• --allow-git defaults to none: npm install will no longer resolve Git dependencies (direct or transitive) unless explicitly allowed via --allow-git. This closes a code-execution path where a Git dependency’s .npmrc could override the Git executable, even with --ignore-scripts. This change was previously announced on 2026-02-18 and is available in npm 11.10.0+.
• --allow-remote defaults to none: npm install will no longer resolve dependencies from remote URLs, such as https tarballs (direct or transitive), unless explicitly allowed via --allow-remote. This flag is available in npm 11.15.0+. The related --allow-file and --allow-directory flags are not changing their defaults in v12.

How to prepare

Upgrade to npm 11.16.0 or later, run your normal install, and review the warnings. Use npm approve-scripts --allow-scripts-pending to see which packages have scripts, approve the ones you trust, and commit the updated package.json. After that, only the scripts you approved keep running once you upgrade. Anything you leave unapproved will stop. More details are available in our docs at npm approve-scripts, npm deny-scripts, and allow-scripts config (for npx and global installs). Please share your comments and questions in our community discussion.

The post Upcoming breaking changes for npm v12 appeared first on The GitHub Blog.