Thanks for your report. This is not the right place to raise the issue, but I will contact the team maintaining code scanning and they will get back to you.

Hey, thanks for reporting and sorry for the delay in getting back to you - I had to check how the summaries were generated. Unfortunately the summaries are a data field, so we cannot post-process them for links easily, so we need to change the generation. That makes it a slightly larger change, but I have created an internal issue for us to track it.

To help getting it prioritized would you mind sharing a bit about how you are using the summaries?

No worries. This is fairly low impact and something I can work around in multiple ways. Nobody else on my team has even mentioned that the links don't work, so I may be the only one who tried them. Thus it seems pretty low priority. Offsetting that slightly, this looks like it a relatively trivial fix (once you find the right spot and information). and is clearly faulty in its current state.

I have a webhook installed on the repo that, long story short, posts check_run.output.summary in a Microsoft Teams message (as a sections[].text). This worked well for travis build pass/fail messages when we used travis, though it is a little verbose for CodeQL. The travis link is a properly rooted https://app.travis-ci.com/github/{org}/{repo}/builds/{id}; the CodeQL link is not, so when I click it in MSTeams, it opens in the browser to https://teams.microsoft.com/{org}/{repo}/...

I could probably postprocess the link myself, as it already passes through another custom layer to convert GitHub outgoing webhook format to MSTeams incoming webhook format. It may be worth it just to optimize the message's visual footprint. (Maybe using the content of check_run.output.title (e.g. No new or fixed alerts) as a link to check_run.html_url (e.g. https://github.com/{org}/{repo}/runs/{id}) would suffice; that page includes the same contents as the summary, and the link works there.)

Thanks for sharing! That makes a lot of sense.