GitHub Release Notes

Added

• Add enterprise permissions.limitTo to enforce managed domain boundaries for network requests

Improved

• Model picker updates the recommended list to prioritize GPT-6.1 Sol, GPT-6 Astra/Luna, and Claude 5.5 models.

Fixed

• GitHub.com Connector users can expand GitHub CLI permissions in place and retry connections without switching sign-in methods.
• Honor --context long_context at startup and show accurate context allowance in /context
• Connecting a Connector without the required GitHub scope now prompts to update your authorization instead of failing with an authentication error

Removed

• Read user settings only from ~/.copilot/settings.json; user-setting keys in ~/.copilot/config.json are ignored.

GitHub stacked pull requests are now generally available. Break large changes into smaller, focused pull requests that you can review independently and merge together.

Since the feature went into public preview, repositories using stacks have seen a 9% increase in merged code compared to peers. Over two-thirds of the top 1% of repos now use stacked pull requests and have seen a 5% improvement in time-to-merge.

With this general availability release, we’re introducing several improvements to make stacks easier to create, review, and merge. Thank you to everyone who provided feedback and input during the preview period.

More flexible merging and rebasing

• Approvals stay in place for unchanged code. When an otherwise unchanged stack is updated after its base branch, such as main, moves ahead, Rebase stack now preserves approvals, even in repositories that dismiss stale approvals.
• Rebased commits stay signed. GitHub creates signed replacement commits during Rebase stack, preserving original authorship. Automatic rebases after partial merges also sign replacement commits when branch rules require signatures or any original commit was signed.
• Bypass permissions apply to stacks. Users with permission to bypass repository rules can now use those permissions to merge the lowest unmerged pull request in a stack. …

Organization and enterprise administrators can now see AI Scan for pull requests enablement status in the security overview coverage view. The code scanning summary shows enabled and not enabled repository counts, while repository rows show each repository’s effective AI Scan enablement.

You can filter the coverage view with code-scanning-ai-scan-pr-scan:enabled and code-scanning-ai-scan-pr-scan:not-enabled. Coverage CSV exports now include a Code Scanning AI Scan for pull requests column with enabled and not-enabled values.

This visibility helps you track adoption and manage AI Scan for pull requests enablement across your organization or enterprise.

Learn more about assessing adoption of security features and join the AI Scan Community discussion.

social

The post Code scanning AI Scan enablement status in security overview appeared first on The GitHub Blog.

2026-10-05

• Add copilot config subcommands to list, read, set, and remove settings.
• Add a pre-conversation Ctrl+E environment picker to switch between local and cloud runs
• Entra-protected MCP servers can silently renew access-token-only credentials.
• Legacy HTTP+SSE MCP connections no longer hang indefinitely when a message POST is never acknowledged; the acknowledgement is bounded by the server's configured timeout
• Voice runtime install errors name why the download from nuget.org failed, not only the fallback feed's 401
• Compaction keeps your latest prompt when requests exceed context limits
• Large Anthropic requests rejected by provider size limits now retry after downscaling images or removing attachments
• Custom agent model entries keep model-bound reasoning effort only when that model is selected
• Shell tool calls now stream live stdout and stderr output reliably in the timeline
• Usage reporting preserves provider-reported reasoning token totals when available
• Sessions no longer slow to a crawl for minutes after the agent writes a very large file in one step
• Sandboxed shells now withhold ambient GITHUB_TOKEN unless explicitly configured.
• Plan usage reflects the current billing period after quota resets
• Custom agents launched through ACP task calls now resolve and run correctly
• Remote session resume now uses your configured GitHub auth for --resume and --connect …

Secret scanning now detects new secret types from Lovable Labs, Pydantic Services Inc., and Supabase.

New secret scanning partner

The following provider joined the secret scanning partnership program. When one of their secrets is found in a public repository, GitHub forwards it to the partner so they can revoke or rotate the credential before it can be abused.

Provider

Secret type

Lovable Labs

lovable_api_key

Detectors added

Secret scanning now automatically detects the following new secret types in your repositories.

Provider

Secret type

Lovable Labs

lovable_api_key

Pydantic Services Inc.

logfire_token

Pydantic Services Inc.

pydantic_ai_gateway_api_key

Supabase

supabase_oauth_access_token

Supabase

supabase_scoped_personal_access_token

Partner secrets are automatically reported to the secret issuer when found in public repositories through the secret scanning partnership program. User secrets generate secret scanning alerts when found in public or private repositories.

Learn more …

Added

• Add copilot config subcommands to list, read, set, and remove settings.

Improved

• Improve first-run startup by extracting the bundled CLI package in a child process
• Improve startup responsiveness when connecting many MCP servers at once
• Canvas actions can now return images to the model in invoke_canvas_action.

Fixed

• Legacy HTTP+SSE MCP connections no longer hang indefinitely when a message POST is never acknowledged; the acknowledgement is bounded by the server's configured timeout
• Voice runtime install errors name why the download from nuget.org failed, not only the fallback feed's 401
• Compaction keeps your latest prompt when requests exceed context limits
• Large Anthropic requests rejected by provider size limits now retry after downscaling images or removing attachments
• Custom agent model entries keep model-bound reasoning effort only when that model is selected
• Shell tool calls now stream live stdout and stderr output reliably in the timeline
• Usage reporting preserves provider-reported reasoning token totals when available
• Sessions no longer slow to a crawl for minutes after the agent writes a very large file in one step
• Sandboxed shells now withhold ambient GITHUB_TOKEN unless explicitly configured.
• Plan usage reflects the current billing period after quota resets
• Custom agents launched through ACP task calls now resolve and run correctly …

Added

• Add a pre-conversation Ctrl+E environment picker to switch between local and cloud runs

Fixed

• Keyboard, paste, and mouse input now stay ordered and responsive during rapid interaction.
• Sandboxed shell commands offer a network bypass prompt whenever the proxy blocks a destination
• Sandboxed scripts that run Git now authenticate with masked credentials and SSH remote rewrites
• Sub-agents keep working after you replace your GitHub authentication credentials

Removed

• Remove retired models from the model picker and supported CLI selections

The staged rollout of the stateless GitHub App installation token format, which began on April 27, 2026, is complete. By default, all newly minted GitHub App installation tokens will be in the stateless ghs_APPID_JWT format, which makes token issuance and validation faster and improves the reliability of the GitHub API.

What’s changed

Installation tokens still start with the ghs_ prefix, but they’re now about 520 characters long instead of 40.

Token permissions, repository scoping, the one-hour expiration, and the installation access token REST API endpoint are unchanged. Tokens minted before the change continue to work until they expire.

What to expect going forward

The temporary X-GitHub-Stateless-S2S-Token request header, which we introduced so you could validate the new format on demand, will be deprecated on November 30, 2026. After that date, GitHub will no longer respect the header, and all eligible apps will always receive stateless tokens. To learn more about the temporary header, see our original changelog for its release.

Once you’ve validated your apps and workflows with both token formats, remove the header from your production code before November 30, 2026.

Check your integrations …

You can now request a GitHub Copilot code review through the REST and GraphQL APIs and set the review effort level for each request. Balanced is also now the default review effort level. These changes are generally available to Copilot Pro, Pro+, Max, Business, and Enterprise plans.

🔌 Request Copilot code review with the API

You can now request a review from Copilot using the supported REST and GraphQL APIs. When you make a request, you can optionally set the review effort level for that review.

This lets you bring Copilot code review into your own scripts, workflows, and internal tools, so reviews can start from the systems your team already uses.

⚖️ Balanced is now the default review effort level

As announced on August 28, 2026, the Default review effort level now uses Balanced for new and existing repositories and organizations using Copilot code review. If you explicitly selected Lite in your settings, that selection was respected. This change took effect September 28, 2026.

⚙️ Configure your review effort level

If you prefer Lite or want to try out the options available to you, you can change the review effort level from Default to Lite at the level you manage: …

Unvalidated npm trusted publishing configurations now expire 48 hours after creation and can no longer authorize publishing. This limits the risk of trusting a repository or project name that changes ownership.

Your configuration becomes validated and exempt from expiry after its first successful publish. Changing the repository or project identity requires a new trust relationship with a fresh 48-hour validation window—ordinary edits don’t restart the deadline.

If your configuration expires, recreate it to start a new 48-hour window. Expired configurations remain visible in trusted publisher settings but don’t count toward per-package limits. Other valid configurations on the package are unaffected.

npm also now rejects trusted publishing tokens from GitHub Actions issue_comment events, alongside the existing pull_request_target restriction. If affected, move publishing to a permitted event such as push, release, or workflow_dispatch.

Join the discussion within GitHub Community.

The post Unvalidated npm trusted publishing configurations now expire appeared first on The GitHub Blog.

You can now create a new npm package with npm stage publish, using a local session or a granular access token, including a stage-only token. This lets you create packages from your automated workflows without a manual first publish.

This works for public scoped and unscoped packages, and private scoped packages. Your first version enters the staged queue and requires a maintainer to promote it before that version becomes available to install. After package creation, you can manage its settings and configure trusted publishing.

Learn more about staged publishing.

Join the npm roadmap discussion in GitHub Community to share feedback and discuss what’s next.

The post npm staged publishing now supports creating new packages appeared first on The GitHub Blog.

As of today, October 2, 2026, we have deprecated the following models across all GitHub Copilot experiences (including Copilot Chat, inline edits, ask and agent modes, and code completions).

Model

Deprecation date

Suggested alternative

Gemini 3.5 Flash

2026-10-02

Gemini 3.8 Flash

Gemini 3.6 Flash

2026-10-02

Gemini 3.8 Flash

Kimi K2.7 Code

2026-10-02

Kimi K3

Claude Opus 4.7

2026-10-02

Claude Opus 5.5

Please update your workflows and integrations to use supported models. Copilot Enterprise administrators may need to enable access to alternative models through their model policies in Copilot settings. As an administrator, you can verify availability by checking your individual Copilot settings and confirming that the policy is enabled for the specific model. Once enabled, you’ll see the model in the Copilot Chat model selector in VS Code and on github.com. No action is required to remove the deprecated models.

GitHub Enterprise customers with questions or concerns are encouraged to reach out to their account manager for further assistance.

Share your feedback

To learn more about the models available in Copilot, see our documentation on models and get started with Copilot today. …

You can now read more of the GitHub Advisory Database directly from the GraphQL API without falling back to the REST API.

The SecurityAdvisory object gained five new fields:

• cveId: The advisory’s CVE identifier.
• sourceCodeLocation: A link to the affected source code relevant to the advisory.
• githubReviewedAt: When GitHub reviewed the advisory.
• nvdPublishedAt: When the National Vulnerability Database (NVD) published its record.
• repositoryAdvisoryUrl: A link to the linked repository security advisory when there is one.

The securityAdvisories query also gained two new filters, severities and isWithdrawn, so you can narrow results on the server instead of downloading everything and filtering it yourself. They work alongside the filters you already use, such as classification, identifier, EPSS, and published or updated since.

This means fewer round trips, one authentication path, and one rate limit budget for integrations that read advisory data. It also makes it easier to build things like severity-based triage feeds, withdrawn advisory audits, and tracking of how quickly advisories move from NVD publication to GitHub review.

These changes are additive and read-only, so your existing queries keep working.

Learn more in the GraphQL API documentation and share your feedback. …

You can now post confidential comments on repository security advisories. Confidential comments are visible only to people with write access to the repository, so you can discuss a report with your team without the reporter or other invited collaborators seeing it.

Previously, every comment on an advisory was visible to all of its collaborators, including the reporter. To discuss suspected abuse, investigation details, or coordination notes, you had to move the conversation somewhere else and lose it from the advisory’s history.

With this update:

• Select Confidential. Only maintainers will see this comment below the comment box before you post.
• Confidential comments are clearly marked in the advisory timeline.
• Reporters and invited collaborators without write access can’t see confidential comments and aren’t notified about them.
• Access follows current repository permissions. If someone loses write access, they can no longer read confidential comments.
• Views of confidential comments are recorded in the audit log.

You can’t switch a comment between confidential and regular after you post it. Confidential comments are available in the GraphQL API, but they aren’t returned by the REST API.

This is available for public repositories with private vulnerability reporting enabled on GitHub Free, GitHub Pro, GitHub Team, and GitHub Enterprise Cloud. …