Copilot custom-property suggestions need clear definitions

GitHub Copilot can now suggest allowed values when an administrator creates a custom property for repositories. The September 15 announcement puts the feature in public preview for Copilot Business and Copilot Enterprise. It addresses a small but consequential part of managing many repositories: agreeing on the metadata used to group them.

A consistent set of values helps teams apply rules to the right repositories. But choosing those values and deciding which value belongs on a repository are separate jobs. The new feature assists with the first. Administrators still need a clear process for the second, especially when the property will determine where a ruleset applies.

Copilot suggests the choices in a property definition

Custom properties are structured metadata attached to repositories. GitHub lets administrators use them to target repositories with rulesets. Instead of maintaining a separate list of repositories for each policy, a team can use a shared property to describe the relevant group.

The new Copilot feature works while an administrator creates a property definition at the enterprise or organization level. GitHub gives the example of a single-select property named internet-facing, for which Copilot can suggest yes and no. It also describes suggestions for a multi-select property named FedRAMP. An administrator can accept a suggestion in one click.

Those examples describe suggested vocabulary. The announcement does not say that Copilot inspects a repository to determine whether it is internet-facing or establishes its compliance status. A suggested value is an option that a repository can later receive, not a finding about that repository.

Enterprise and organization owners can control availability through the Repository custom property suggestions Copilot policy. If your organization wants to try the preview, that policy and the supported Copilot plan are the first things to check.

Define what each value means before assigning it

The practical benefit is a faster starting point for a shared vocabulary. GitHub says inconsistent metadata makes governance harder across a large set of repositories. AI assistance may reduce the effort of proposing values, but the people who maintain the repositories need to agree on their meaning.

For internet-facing, a team might mean code that serves requests from the public internet. Another team might include every library used by a public service. Both interpretations could produce a plausible yes; they would select different repositories for the same rule.

Our recommendation is to put that distinction in the property's description before assigning values broadly. State what the property describes, who is responsible for assigning it, and when a value needs to change. Use terminology the teams already recognize rather than accepting a longer list simply because the assistant offers one.

GitHub's custom-property documentation separates adding a property from setting values on repositories. That is a useful division of work: agree on the definition, then review the actual repositories against it. For compliance-related properties, the assignment should follow the organization's evidence and approval process, not the wording of a suggestion.

Defaults can place unreviewed repositories in a group

Defaults deserve attention before a property controls policy scope. GitHub lets administrators require a property for all repositories and provide a default value. Repositories without an explicit value inherit that default.

For example, choosing no as the default for internet-facing would make an unclassified repository inherit no. That does not establish that someone checked how its software is exposed. If a ruleset targets only repositories marked yes, that inherited value can matter to which repositories it reaches.

This is a consequence of the documented default behavior, not a separate behavior introduced by the Copilot preview. The documentation also says that repositories without an explicit value still inherit the default when Require explicit user-specified values is enabled. Do not read that setting as a guarantee that all existing repositories have been reviewed.

Before using a new property for rule targeting, inspect the repositories that have not received an explicit value. Decide how those repositories should be handled while classification is incomplete. Depending on the property design, a team could use a distinct value for unreviewed repositories or keep broader protection in place until assignments are complete. These are configuration choices for the team, not values promised by Copilot.

GitHub supports searching and filtering repositories by custom-property values. Use that view to compare the selected set with repositories you expect to include and exclude. Check ambiguous cases with their owners before changing policy scope. After the ruleset is in use, Rule Insights can help investigate evaluations and bypasses; that is a later check, not a substitute for a clear property definition.

Keep repository metadata suitable for its audience

Custom properties are not a private notes field. GitHub documents that property visibility follows repository visibility: anyone can view properties on a public repository, while properties on private or internal repositories are visible to accounts with repository read access.

Use labels suitable for that audience. Avoid putting credentials, sensitive incident details, or confidential customer information in a property value or description. A short classification can point staff toward an approved internal process without copying the underlying evidence into repository metadata.

For a first trial, choose a property the organization already understands. Compare Copilot's suggestions with the existing vocabulary, resolve unclear meanings, and inspect the repository assignments before using the property to change ruleset coverage. The useful outcome is not a larger collection of labels. It is a definition that repository owners can apply consistently and administrators can use with confidence.

Sources

• GitHub Changelog: GitHub Copilot suggests custom properties definitions, September 15, 2026. Preview scope, examples, and availability policy.
• GitHub Docs: Managing custom properties for repositories in your organization, accessed September 15, 2026. Property definitions, assignments, defaults, visibility, and filtering.