You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an organization defines a custom repository property with value_type: multi_select, the Initialize CodeQL step logs a warning and fails to load repository properties entirely:
##[warning]Failed to load repository properties: Encountered an error while trying to determine repository properties: Error: Expected repository property 'products' to have a string value, but got: {"property_name":"products","value":["scan"]}
This occurs because the action expects all repository property values to be strings, but the GitHub API correctly returns multi_select properties as arrays of strings.
Steps to reproduce
Create an org-level custom property with value_type: multi_select (e.g. products)
Set a value on a repository (e.g. ["scan"])
Run CodeQL default setup on that repository — the Initialize CodeQL step will log the above warning
Expected behaviour
The action should handle multi_select property values (arrays of strings) without erroring. It could either:
Treat each element as a separate value to match against, or
Skip property-based filtering for multi_select properties rather than failing entirely
Actual behaviour
The action throws Expected repository property 'products' to have a string value and skips all repository property-based configuration, even for properties that are not the multi_select one.
Impact
CodeQL analysis still runs and completes successfully (the warning is non-fatal)
However, any org-level policy that would be selected based on repository properties is not applied
The warning is noise in logs and may be mistaken for a failure
Activity
[-]Initialize CodeQL fails to handle multi_select repository properties (expects string, gets array)[/-][+]CodeQL Action fails to handle multi_select repository properties (expects string, gets array)[/+]mbg commentedon Mar 9, 2026
Thanks for reporting this, @john-latham! We have merged #3557, which should fix this once we have released a new version of the CodeQL Action.