Repo level CodeQL default setup is not persisting in Azure Repos

Question

Repo level CodeQL default setup is not persisting in Azure Repos

Kayla 0

Now that GitHub Advanced Security for DevOps can have a basic CodeQL setup at the org/proj/repo level instead of only writing YML pipes, I was trying to enable that for my instance. I was able to configure the pool and schedule at the org level and set it to enabled for new projects, and within the project, I'm able to set it to enabled for new repos.

My issue is getting existing repos to have a CodeQL analysis with the default setup. When I click the checkbox, everything is fine, but if I navigate away and come back, the box is unchecked.

From looking at the network tab in DevTools, the initial state of my repo is codeQLEnabled: null

Then, checking the box does a PATCH with a payload of { "advSecEnablementFeatures": { "codeQLEnabled": true } }
It gets back a 204 No Content
After refreshing the repo settings page, the state of the settings is still codeQLEnabled: null

The advSecEnablementLastChangedDate changes after the PATCH, which suggests the request actually is accepted or processed, but the CodeQL field isn't working. The other repo adv sec settings, like blocking secrets on push and scanning the default branch for dependencies, still work, as does selecting CodeQL's View Details and manually triggering a run. This occurs on repos that have had previous YML CodeQL runs and those that have not.

Pravallika KV 16,605 Reputation points Microsoft External Staff Moderator

2026-06-01T18:26:14.2866667+00:00
Hi @Kayla ,

Please check if below steps helps:

Confirm you’re enrolled in the CodeQL default setup public preview

Make sure your org has the preview feature flag enabled (public preview still requires opt-in).

Verify your permissions

You need to be a Project Collection Administrator (or have no explicit Deny on “Edit policies”) and/or hold the Advanced Security: manage settings permission on each repository. If your user is missing those rights, the PATCH will succeed (204) but won’t actually update the codeQLEnabled flag.

Double-check the “default setup” UI at the org level

Go to Organization settings → Repositories → expand CodeQL default setup configurable options. Confirm the agent pool, schedule and “enabled for new repos” setting look correct there.

Try the REST API as a fallback

GET the repo’s advSecEnablementFeatures (you’ll see codeQLEnabled: null)

PATCH { "advSecEnablementFeatures": { "codeQLEnabled": true } }

If it still returns 204 but stays null, it usually points back to a permissions or preview-flag issue.

If you’ve verified the above and it still doesn’t stick, it may be a public-preview bug. In that case, could you share:

Your exact user role/permissions on that repo (check the Security tab)

The URL of one of the affected repo settings pages

Any browser console or network-tab errors beyond the 204 No Content

That info will help us drill in. Hope this helps get your existing repos on board with the default CodeQL setup!

References:

Set up code scanning – Configure default setup options

CodeQL default setup public preview

Permissions for GitHub Advanced Security
Kayla 0 Reputation points

2026-06-01T18:57:00.5866667+00:00
@Pravallika KV Thanks for the help!

I assume so, since it's in every GitHub Advanced Security for DevOps settings page.

I'm the org owner, and directly in the Project Collection Administrators. And in each project I'm trying this in, I'm one of the project admins.

Yep, it's using the general pool, not one of our managed ones, and is set to scheduled runs on Saturdays

It might take me a while to set that up, but I can't imagine it'd have any different results if I'm doing the same REST calls in a Python script as the UI is doing

As mentioned earlier, I have full perms in the org, so it shouldn't be anything permissions-based

I'm not logged into this account on my work computer, so I can't copy and paste a URL, but I could try to copy down some GUIDs if that would help?

Every fetch call is 20x within the repo settings, no errors
Pravallika KV 16,605 Reputation points Microsoft External Staff Moderator

2026-06-03T01:18:06.8066667+00:00

@Kayla , Given that the PATCH returns 204, advSecEnablementLastChangedDate updates, and other Advanced Security settings persist correctly, this doesn't seem like a permissions issue. The fact that codeQLEnabled consistently returns to null suggests the backend is accepting the request but not actually transitioning the repository into the default CodeQL setup state.

Does this happen on a brand-new repository with no existing CodeQL workflows or history? If so, it may point to a bug in the current default setup implementation rather than a repo-specific configuration issue.
Pravallika KV 16,605 Reputation points Microsoft External Staff Moderator

2026-06-03T23:36:44.4966667+00:00

@Kayla , Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Kayla 0 Reputation points

2026-06-05T18:39:05.37+00:00

@Pravallika KV Yes, I tried in a repository that has never had CodeQL runs, and still, enabling CodeQL default runs does not persist.

At this point, I might just try again in a few weeks, assuming it's a Microsoft issue that I cannot fix as an end user, and manually kick off runs in my largest repos every week.

1 answer

Your answer

Pravallika KV 16,605 Reputation points Microsoft External Staff Moderator

2026-06-01T18:26:14.2866667+00:00

Hi @Kayla ,

Please check if below steps helps:

Confirm you’re enrolled in the CodeQL default setup public preview

Make sure your org has the preview feature flag enabled (public preview still requires opt-in).

Verify your permissions

You need to be a Project Collection Administrator (or have no explicit Deny on “Edit policies”) and/or hold the Advanced Security: manage settings permission on each repository. If your user is missing those rights, the PATCH will succeed (204) but won’t actually update the codeQLEnabled flag.

Double-check the “default setup” UI at the org level

Go to Organization settings → Repositories → expand CodeQL default setup configurable options. Confirm the agent pool, schedule and “enabled for new repos” setting look correct there.

Try the REST API as a fallback

GET the repo’s advSecEnablementFeatures (you’ll see codeQLEnabled: null)

PATCH { "advSecEnablementFeatures": { "codeQLEnabled": true } }

If it still returns 204 but stays null, it usually points back to a permissions or preview-flag issue.

If you’ve verified the above and it still doesn’t stick, it may be a public-preview bug. In that case, could you share:

Your exact user role/permissions on that repo (check the Security tab)

The URL of one of the affected repo settings pages

Any browser console or network-tab errors beyond the 204 No Content

That info will help us drill in. Hope this helps get your existing repos on board with the default CodeQL setup!

References:

Set up code scanning – Configure default setup options

CodeQL default setup public preview

Permissions for GitHub Advanced Security
Kayla 0 Reputation points

2026-06-01T18:57:00.5866667+00:00

@Pravallika KV Thanks for the help!

I assume so, since it's in every GitHub Advanced Security for DevOps settings page.

I'm the org owner, and directly in the Project Collection Administrators. And in each project I'm trying this in, I'm one of the project admins.

Yep, it's using the general pool, not one of our managed ones, and is set to scheduled runs on Saturdays

It might take me a while to set that up, but I can't imagine it'd have any different results if I'm doing the same REST calls in a Python script as the UI is doing

As mentioned earlier, I have full perms in the org, so it shouldn't be anything permissions-based

I'm not logged into this account on my work computer, so I can't copy and paste a URL, but I could try to copy down some GUIDs if that would help?

Every fetch call is 20x within the repo settings, no errors
Pravallika KV 16,605 Reputation points Microsoft External Staff Moderator

2026-06-03T01:18:06.8066667+00:00

@Kayla , Given that the PATCH returns 204, advSecEnablementLastChangedDate updates, and other Advanced Security settings persist correctly, this doesn't seem like a permissions issue. The fact that codeQLEnabled consistently returns to null suggests the backend is accepting the request but not actually transitioning the repository into the default CodeQL setup state.

Does this happen on a brand-new repository with no existing CodeQL workflows or history? If so, it may point to a bug in the current default setup implementation rather than a repo-specific configuration issue.
Pravallika KV 16,605 Reputation points Microsoft External Staff Moderator

2026-06-03T23:36:44.4966667+00:00

@Kayla , Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Kayla 0 Reputation points

2026-06-05T18:39:05.37+00:00

@Pravallika KV Yes, I tried in a repository that has never had CodeQL runs, and still, enabling CodeQL default runs does not persist.

At this point, I might just try again in a few weeks, assuming it's a Microsoft issue that I cannot fix as an end user, and manually kick off runs in my largest repos every week.

Answer 1

CodeQL default setup for GitHub Advanced Security in Azure DevOps is currently in preview and is still rolling out, and the behavior described matches a backend limitation/bug rather than a configuration issue.

From the documented behavior:

CodeQL default setup is a managed, organization-level feature that runs using Azure Pipelines and is configured centrally for agent pool and schedule at Organization settings → Repositories → CodeQL default setup configurable options.
Default setup is designed to be the quickest way to enable code scanning and runs on a weekly schedule, surfacing results in the Advanced Security tab.
The feature has been in private preview and then public preview, and Microsoft has explicitly called out rollout issues and delays:
- CodeQL default setup (one‑click enablement) was initially in private preview.
- Later release notes state that the rollout of CodeQL default setup has been delayed due to issues discovered during rollout, and the team is working to resolve them.

Given this:

The organization-level configuration (agent pool, schedule, enable for new projects/repos) working, while repo-level toggling for existing repos does not persist, is consistent with an incomplete or problematic rollout of the default setup feature.
The fact that advSecEnablementLastChangedDate updates but codeQLEnabled remains null, despite a 204 response, indicates that the server is accepting the request but not committing the CodeQL default setup state for that repo. This aligns with the known rollout issues mentioned in the release notes.
Other Advanced Security features (secret scanning, dependency scanning, manual CodeQL runs via “View Details”) working confirms that Advanced Security itself is enabled and that the problem is specific to CodeQL default setup persistence.

Workable paths based on the documented options:

Use Advanced setup for CodeQL in affected repos
- Configure CodeQL via pipelines using the Advanced Security CodeQL tasks (AdvancedSecurity-CodeQL-Init@1 and AdvancedSecurity-Codeql-Analyze@1) as described under advanced setup. This gives full control and does not depend on the default setup toggle.
- Note that the CodeQL autobuild task is deprecated; use buildtype: none in AdvancedSecurity-CodeQL-Init@1 instead.
Continue using default setup only where it persists (e.g., new repos)
- Since default setup is recommended as the starting point and is centrally configured, allow it to manage new repositories where the toggle is applied automatically from org/project settings.
Treat the non‑persisting toggle as a product issue
- Because Microsoft has acknowledged rollout issues and even delayed the rollout of CodeQL default setup, the non‑persisting codeQLEnabled flag for existing repos is best handled as a service-side bug rather than further client-side troubleshooting.
- For production needs, rely on advanced setup until the rollout issues are resolved and default setup is fully supported for existing repositories.

In short, the behavior is a limitation/bug in the current preview rollout of CodeQL default setup. Use advanced setup for existing repos that need reliable CodeQL scanning, and rely on default setup only where it is automatically and correctly applied.

References:

Share via

Repo level CodeQL default setup is not persisting in Azure Repos

1 answer

Your answer