티스토리 수익 글 보기

In July, we announced a default model policy for generally available GitHub Copilot models on Copilot Business and Copilot Enterprise plans. Starting today, we’re gradually rolling out enforcement of the policy through September 1, so it will take effect at different times for different enterprises. Previously unconfigured and new generally available models will inherit the global policy state. Administrators can make durable decisions for individual models at their discretion. Open-weight models and any models that require data retention are disabled by default.

What’s changing

Once the policy takes effect for your organization or enterprise:

• Models you haven’t previously configured will change their state to “Delegate to default policy”, and they’ll begin following your policy setting. If your policy is enabled — which is the default — those models will become available to your users.
• “Delegate to default policy” is a live, dynamic state that always tracks your policy. You can change the policy at any time, and all applicable models follow that state change.
• We always preserve explicit choices. If you’ve deliberately enabled or disabled a specific model, we do not change that setting.
• We exclude open-weight models (e.g., DeepSeek and Kimi K2) and models not covered by GitHub’s data retention agreement (e.g., Fable 5) from default enablement, regardless of your policy.

After the rollout, each model in your settings shows one of four states:

• Enabled: You’ve explicitly turned the model on.
• Disabled: You’ve explicitly turned the model off.
• Delegate to enterprise teams/apps or organizations: The model follows a setting inherited from your enterprise team or organization.
• Delegate to default policy: The model follows your default enablement policy.

To learn more, see default model availability.

What’s next

We are looking for your feedback in the community discussion below. We’re evaluating making the global model policy state an explicit decision and removing the “Delegate to default policy” state. This would help ensure that every policy reflects an explicit, intentional choice rather than an inferred one.

Join the discussion within GitHub Community.

The post Global model policy generally available appeared first on The GitHub Blog.

Enterprise owners can now grant a GitHub App access to enterprise billing data. When you create or configure a GitHub App, you can select the enterprise billing permission and choose one of two levels: read or read and write.

Previously, the only way to read usage or manage budgets and cost centers through the API was a personal access token belonging to an enterprise owner or billing manager. That tied your billing automation to one person’s token, so it broke when that person changed roles or left.

Now an app installation access token that carries the enterprise billing permission can call the enterprise billing REST API endpoints. Use it to pull usage data into your finance and BI systems, reconcile invoices, and manage budgets and cost centers, all without relying on an individual’s token. As an added benefit, you also get higher rate limits than a personal access token.

The enterprise billing permission is available on GitHub Enterprise Cloud. To learn more, see Choosing permissions for a GitHub App.

The post GitHub Apps can now access enterprise billing data appeared first on The GitHub Blog.

The rule insights dashboard is now generally available at both the repository and organization levels. You get a visual, high-level view of how GitHub evaluates and enforces your GitHub repository rulesets, so you can spot trends and report on governance without stitching data together by hand.

Organization-level dashboard

The organization-level dashboard we shipped in public preview is now generally available. In your organization’s Settings > Repository tab, you get an aggregated view across every repository, which helps your governance and compliance teams report across the whole organization instead of individually checking each repository. At the organization level, you can:

• Review aggregated rule evaluation metrics for all repositories in your organization.
• Identify your top repositories by bypasses to focus your review where it matters most.
• Filter results by evaluation status, branch, ruleset, and date range to focus on the activity you care about.

Repository-level dashboard

The repository-level dashboard we shipped in public preview is now generally available. In your repository’s Settings > Rules tab, you can see successes, failures, and bypasses over time, along with the most active bypassers for your rulesets. Each chart links back to the rule insights page with filters prefilled, so you can quickly drill into specific statuses, bypasses, or time ranges.

Whether you’re responding to an incident or auditing bypass activity, the dashboard helps you spot trends at a glance and drill into the details when you need them.

Availability

The rule insights dashboard is generally available at both the repository and organization levels, and you can export the data to CSV at either level for reporting and record keeping. To learn more, see our docs about GitHub repository rulesets.

Join the discussion within GitHub Community.

The post Rule insights dashboard generally available appeared first on The GitHub Blog.

GitHub Copilot is more useful when it works with the tools, knowledge, and workflows your team already relies on.

The new Customize tab in the GitHub Copilot app brings MCP servers, plugins, skills, and canvases together in one place. Explore featured customizations, browse by type, and find new ways to tailor Copilot to how you and your team work.

With the Customize tab, you can:

• Discover more ways to customize Copilot across MCP servers, plugins, skills, and canvases.
• Start with featured customizations selected from each section.
• Find MCP servers faster by exploring trending options and browsing by category.

Bring the tools your team uses into Copilot

Featured canvases help you move from understanding work to acting on it while keeping the relevant context visible.

Delegate backlog work from Azure DevOps

Triage issues, prioritize backlogs, assign follow-ups, and hand work to Copilot to investigate, implement, or prepare for review.

Explore every type of customization

The Featured view brings selected customizations from across the GitHub Copilot app into one place, giving you a simpler starting point when you do not already know which MCP server, plugin, skill, or canvas you need. You can also browse dedicated sections for each type of customization to find options that fit the way you work.

Get started

Open the GitHub Copilot app and select Customize to explore featured customizations or browse by type.

Install the GitHub Copilot app.

The post GitHub Copilot app Customize tab is generally available appeared first on The GitHub Blog.

You can now block a user directly from a security advisory page in public repositories owned by either an organization or a personal account. This brings the streamlined moderation experience available for issues and pull requests to security advisories.

Security advisories contain user-created content and, like other collaborative surfaces, can attract spam or abuse. Previously, addressing this required navigating to organization settings, personal settings, or the user’s profile.

With this update, you can:

• Block a user from the three-dot menu in a security advisory description or comment without leaving the page.
• Review a clear confirmation of what blocking the user means before taking action.
• Keep the security advisory intact while removing the source of spam or abuse.

In organization-owned repositories, only organization moderators or administrators can initiate a block. In personal account-owned repositories, the account owner can initiate a block.

Join the Community discussion to share your questions or feedback.

The post Block users directly from security advisories appeared first on The GitHub Blog.

You can now configure push rules more granularly by exempting specific file paths, so a rule applies everywhere in scope except the paths you choose. Path exceptions are in public preview.

Push rules give you strong control over what enters a repository. Sometimes a rule needs a narrow exception, and until now your options were to relax it for everyone or enforce it outside of GitHub. You can now keep the rule in place and exempt only the paths that need it.

Where to find it

When you configure either supported rule, expand Allowed exceptions and add the path patterns the rule should skip. GitHub validates your patterns when you save the ruleset, so you can fix mistakes right away.

Two push rules support exceptions today:

• Restrict file paths: Block a file type across the repository while allowing it at a specific path, such as blocking JAR files everywhere except **/gradle/wrapper/*.jar.
• Restrict file size: Enforce a size limit while exempting paths that already exceed it, so you can adopt the limit without changing those files first.

For pattern syntax and the full list of push rules, see available rules for rulesets.

Join the community discussion to share feedback.

The post Push rules in rulesets now support path exceptions appeared first on The GitHub Blog.

Managing blocked users is now faster and clearer for personal accounts and organizations. With this update, you can:

• Search by username, full name, or email.
• Sort and paginate long lists.
• Filter by block reason (e.g., Spam, Misconduct, or Harassment).
• Add private notes to preserve moderation context.
• View and edit block settings.
• See who applied an organization block and when it expires.

The updated experience also clearly separates searching the blocked-user list from blocking a new user, helping you find cases faster and avoid accidental blocks.

To get started, go to Settings → Moderation → Blocked users for your personal account or Organization settings → Moderation → Blocked users for an organization you administer.

Leave a comment in our Community discussion if you have any questions or feedback.

The post Better tools for managing blocked users appeared first on The GitHub Blog.

The GitHub integration in Slack now brings the agentic capabilities of GitHub Copilot CLI and the GitHub Copilot app into Slack in public preview. You can work with @GitHub to plan changes, investigate problems, and hand off coding tasks from the conversations where your team coordinates work. GitHub is also a launch partner for Slack Code, a new type of channel designed for agents.

Bringing Copilot into the flow of conversation helps your team turn shared intent into shippable work.

What you can now do with @GitHub

Mention @GitHub in a direct message, channel, or thread to start an agent session. Copilot can use the conversation and permitted GitHub context to:

• Answer questions about your code and GitHub activity.
• Triage bug reports, update existing issues, or create and label new issues.
• Investigate failures, implement changes, and validate its work in a secure cloud sandbox.
• Open a pull request and provide a link to the conversation for review.

GitHub Copilot continues working asynchronously while you’re in a meeting, commuting, or focused on something else. You can direct the session from Slack as it works, then continue from the pull request in your terminal, the GitHub Copilot app, or your IDE.

Slack Code and GitHub Copilot

GitHub Copilot can also create a dedicated code channel that keeps the task focused without adding noise to the original conversation.

Inside the code channel, your team can follow the plan, inspect the diffs, review output previews like HTML artifacts, and iterate with Copilot. Anyone can join the channel from the original thread, add context, redirect the approach, or stop the session.

The power of multiplayer

Agent sessions in Slack are shared, so your team can collaborate on the work where the request began instead of one person working privately with an agent.

Working in the open also makes effective agent workflows easier to learn. Developers can see how their teammates prompt the agent and learn from each other. Issues and pull requests created from the conversation are attributed to the Copilot app identity, and actions remain bounded by existing GitHub permissions and controls.

Availability and getting started

The public preview is available to organizations on GitHub Copilot Business and GitHub Copilot Enterprise plans. Usage counts against your existing Copilot entitlements and can be managed with existing Copilot cloud agent budgets.

To get started:

1. Make sure an administrator has enabled the Copilot cloud agent policy for your organization.
2. Install or upgrade the GitHub app for Slack.
3. Link your GitHub account and mention @GitHub in a conversation.

Repository administrators can require an additional approval for any pull request attributed to the Copilot app identity before it can merge. Requiring an additional approval keeps a human in the loop before agent-authored work ships. Your team moves fast without losing compliance oversight.

For setup details and supported workflows, see how to use Copilot coding agent with Slack.

The post The new GitHub Copilot experience in Slack appeared first on The GitHub Blog.

Turn a Microsoft Teams discussion into a collaborative agent session everyone can see and help direct. Mention @GitHub in a channel, thread, or direct message to start a GitHub Copilot cloud agent session. Anyone in the conversation can ask questions, add context, and help plan or steer the work. Participants with write access to the repository can trigger Copilot to make changes.

Turn meeting decisions into ready work

When a meeting produces an action item, hand it to Copilot during a discussion or in the meeting chat before it ends. For example, ask Copilot to investigate a problem while you discuss it in your team’s standup and start resolving it before the meeting ends. Everyone can see the agent’s investigation and direct it further if needed.

Editor’s note (August 21, 2026): Updated the language to align with Teams terminology.

Continue work across GitHub Copilot surfaces

Start a task from Teams and let Copilot work asynchronously in a secure cloud sandbox. Follow progress in the channel thread, then continue working with the agent-generated artifacts from your terminal, the GitHub Copilot app, or your preferred IDE. For more information, see our documentation about cloud sandboxing.

Availability and getting started

The public preview is available with paid GitHub Copilot plans. GitHub Copilot cloud agent sessions started in Microsoft Teams consume AI credits. For organizations, cloud agent AI credit usage is governed by usage-based billing budgets. Cloud sandbox usage is billed separately and can be controlled with a product-level or SKU-level budget.

To get started:

1. For users in an organization or enterprise, make sure an administrator has enabled GitHub Copilot cloud agent and cloud sandboxes. Cloud sandbox policies share the same configuration as cloud agent policies.
2. Install the GitHub app for Microsoft Teams.
3. In Teams, mention @GitHub and follow the prompts to connect your GitHub account.
4. For public channels, configure a default repository if prompted. Direct messages don’t use a default repository.
5. Mention @GitHub, followed by your task. You can also use @GitHub help to see available commands.

Maintain compliance oversight

Repository administrators can now require an additional approval for any pull request attributed to the Microsoft Teams Copilot integration identity before it can merge. If you require two approvals in a repository, with this enabled you will need three for Copilot-created pull requests. Requiring an additional approval keeps a human in the loop before agent-authored work ships. Your team moves fast without losing compliance oversight.

For setup details, permissions, repository and branch selection, and supported workflows, see how to integrate GitHub Copilot cloud agent with Microsoft Teams.

The post Shared agentic work with GitHub Copilot in Microsoft Teams appeared first on The GitHub Blog.

Pinning saved views to the repository issues sidebar

You can now pin saved views⁠ to the repository issues sidebar, making the views you use most just one click away, even when the sidebar is collapsed.

Other Improvements

You can now see profile avatars for reactions on issues.

You can now adjust the Issues Dashboard density to see more issues at once

You can now hide closed sub-issues, making it easier to focus on the work that’s still open.

The issue dependency REST API endpoints (blocked_by, blocking, and relates_to) now filter results based on the token’s granted scope.

Join the discussion within GitHub Community.

The post Pinning saved views to the repository issues sidebar is generally available and more appeared first on The GitHub Blog.