How SonarQube matches Copilot users?

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • SonarQube Server v2025.5 (113872) / Developer Edition
  • Docker
  • what are you trying to achieve
    • Enable Autodetect AI-Generated Code feature

Hello

i’m trying to enable Autodetect AI-Generated Code feature of SQ, on an already existing and working integration between our SQ instance and our GitHub.com organization.

  • On GitHub side, user accounts are manually created, and are configured with public email address matching user company email (usually in lowercase)

  • On SonarQube side, user accounts are automatically created at first logging, populating data from internal LDAP. Email associated to account are not in lowercase (Firstnam.Lastname@domain.com).

On SQ web.log side, i can see it properly fetches the Copilot seats, but it is not able to associate properly with SQ users (only 1 found)

2025.12.06 10:11:38 INFO  web[com.sonar.x.j.j.x] [Copilot] Fetching Copilot seats information for 1 Github App configurations
2025.12.06 10:11:39 INFO  web[com.sonar.x.j.j.j.h] [Copilot] Fetched 76 Copilot seats for organization ... and installation 30548568
2025.12.06 10:11:39 INFO  web[com.sonar.x.j.j.x] [Copilot] Successfully fetched 76 Copilot seats information
2025.12.06 10:11:39 INFO  web[com.sonar.x.j.j.x] [Copilot] Found 1 users matching Copilot seat assignment
2025.12.06 10:11:39 INFO  web[com.sonar.x.j.j.x] [Copilot] Updated Copilot AI tool usage for 1 users

How can we “debug” this issue? Is there a documentation page describing how users are mapped between those 2 platforms?

Thanks

2

Hi,

I suspect you’ve already come pretty close to identifying the issue (case) but can you enable debug logging (Administration → System → Logs level) and re-run this? Note that debug-level logging gets big, fast, so you’ll want to return to INFO level quickly.

 
Ann

3

Thanks for the advice, but before enabling debug logs, do you know how to trigger the Copilot seats fetch?

I see in logs it is executing daily at same time, but not sure how to trigger the action…

4

Hi,

I think you might be able to trigger this by toggling Autodetect AI-Generated code off and back on.

Separately, double-checking the docs, I find

  1. If you are using SonarQube Server with the GitHub Enterprise Server (the self-hosted version of the GitHub platform) or SSO, a SonarQube administrator must set up an SCM account for each Copilot Business subscription user so that the users’ Copilot login matches their GitHub Enterprise Server login.

So for the non-syncing users, I think it’s worth creating an additional SCM Account in lower case. Can you give that a try on at least one user and see if that works?

 
Thx,
Ann

5

Hello

i was not able to manually trigger the Copilot seats fetch, so had to wait for the scheduled operation.

Sadly, DEBUG logs are not giving any more details so i still don’t know how user mapping is performed.

I’m following your advice and just created 2 SCM accounts for 2 users, let’s see if those are found during seats fetch.

Does it sound reasonable to maybe request an option to perform a “case-insensitive” match during Copilot seats fetch, to prevent such mismatch?

Manually creating SCM accounts containing same email as registered in user account, but lowercase, seems a bit overkill…

6

Hi,

Yes, it sounds imminently reasonable to me. But let’s make sure it’s the case thing first. :slight_smile:

 
Ann

7

Hello

bad news, still same situation, the users with added SCM account (lowercase email) are not detected during Copilot seats match.

As a side note, we use LDAP integration to authenticate users against our AD, and create user account on first login.

In order to go farther in debug, could it be possible to know:

  • how to manually trigger the Copilot seats fetch?
    • would an instance restart “work” as a workaround?
  • how to capture detailed logs about the Copilot seats fetch and match process?
    • even when enabling DEBUG logs, i see nothing interesting. Would TRACE level work?
    • Idea would be to get printed user id / emails to understand how the matching is performed…
8

Hello

Happy new year!

Could it be possible to get some guidance here to move forward in debugging our issue?

Thanks in advance

10

Hi,

Sorry for the delay in responding. I guess you saw the pinned post with the Holiday notification?

I’m not sure where to go from here. I’ve flagged this for the team.

 
Ann

1 Like
12

Hi,

Note that each user must have used Copilot to be eligible for matching. I.e., if the 2 users you have on SQ have not both used Copilot actively, they will be ignored (being assigned a seat is not enough). Are you sure both users actually used Copilot?

For how it works, the users are matched the same way we match SCM data. We get the user ID, username, and email from Copilot (which should be your GitHub Account data), and then try to match them to the SonarQube user’s external_id (this will match if you use GitHub OAuth as your IdP, which is not your case), username, and email. If none match then it will cycle through the SCM accounts and try to match the GitHub username and email to each SCM account.

13

Hi

Thanks for those explanations @Wouter_Admiraal

I’m sure about the Copilot usage, but good to know :+1:

What makes this issue complicated to investigate is:

  • no detail in log about the matched user (could also list in DEBUG the fetched Copilot users). I am not able to identify who is our only matched user ^^
  • no simple way to trigger a Copilot user fetch

Currently, for a user named John Doe, we have this setup:

GitHub

SonarQube (LDAP auth)

For 2 of our active users, i have added the following SCM account data:

  • email in lowercase
  • GitHub account id

Let’s see if SQ can find match those 2 accounts on the next fetch.

Note that in GitHub, you need to explicitly make your email as public in order for this info to be available from API

1 Like