A valid JSON file is not a working Copilot policy

A platform team changes an enterprise Copilot setting in .github-private. The JSON parses locally, the commit lands, and somebody marks the rollout complete. A week later, a team-specific exception does not behave as expected. Was the team slug wrong, the property unsupported, or did the client simply not receive the setting?

GitHub's September 25 announcement adds a useful first stop: an in-product validator for enterprise managed settings. It flags malformed JSON, unsupported configurations and invalid team mappings, identifying the affected file and JSON path. This changes the configuration repair loop. It does not replace an effective-policy test on the client.

Start with the path, not the symptom

The validator covers copilot/managed-settings.json, copilot/team-mappings.json, and team settings files referenced by the mappings file in the selected .github-private repository. An enterprise owner can open AI controls → Agents → Copilot settings validation and use each file/path issue to find the offending declaration. GitHub's setup documentation says to commit the correction to the repository's default branch, reload the Agents page, and inspect the updated result.

That gives the owner a more precise question than “is Copilot broken?” For a team override, check three linked things: the base key is marked overridable where required; the mappings file names an existing team settings file and the intended enterprise team slug; and the referenced file declares only the intended override. GitHub's documentation illustrates this with model set to auto by default and a no-auto.json override mapped to special-team. Those names are an example, not a recommendation to change model policy.

A disappearing validation section is not a blanket certificate. GitHub says it is hidden when no issues are found; it also says that if validation is temporarily unavailable, existing settings continue to apply. Record the repository commit and the page observation rather than interpreting absence alone as proof of enforcement.

The second check happens on a client

After the source validates, check a supported client with two licensed users: one in the intended team and one outside it. For a low-impact pilot, GitHub's example uses the default model mode, but pick a property actually supported by the client you test. Write down the expected value for each user, the selected enterprise billing context where relevant, client version, observed value and time of observation. If they disagree, stop the rollout and investigate before widening the audience.

GitHub's guide says server-managed settings reach supported clients within about an hour, while restarting or signing in again triggers an immediate refresh. It also cautions that not every client supports every property. If a user gets a Copilot license from more than one billing entity, their “Usage billed to” selection can matter. A clean validator result therefore answers whether the repository configuration has reported issues, not whether every intended client has applied every setting.

This is a different decision from the JetBrains managed-settings pilot, which maps property support and effective client behavior, and from the model-policy inheritance analysis, which considers policy precedence. The new validator supplies a repair location in the server-managed source. Keep the client test and the source check as separate entries in the rollout record.

A compact rollout record

Scroll sideways to see all 3 columns.

Check	Evidence to retain	Stop condition
Source revision	.github-private default-branch commit and changed file paths	Wrong branch or unreviewed mapping
Validator	Dated observation of errors/warnings, file and JSON path; corrected commit and reload	Remaining issue or unavailable result treated as a pass
Client A / client B	Supported client, property, team membership, expected and observed value, refresh time	Either value differs from expectation

This is a proposed verification record, not a report of a live enterprise test. The useful new step is narrow but consequential: fix the declared policy at its exact source path, then independently establish that the effective policy matches the intended users and clients. If your team needs help designing that two-stage check, talk with BaristaLabs about an AI governance rollout.