Upon further thought, this should probably be given special considerations:

a) We would generally want all links returning 401 or 403 to be flagged as broken if the link was posted on a publicly facing section of the Composr site (e.g. can be viewed by Guest). For example, links in the docs / tutorials would definitely want to be flagged as broken if they return 401 or 403 because such links should be viewable by the general public. And if not, we should consider removing or changing the link.

b) However, when a link is posted in a restricted section of a Composr site that is not viewable by Guest, such as a forum, we might not want broken URL checking to flag a link returning 401 or 403 as broken. For example, a user might post a direct link to a Tweet on X, but X requires everyone to log in before they can view a Tweet. This does not necessarily mean that the link is "broken", it just means it is not "public". And therefore, a non-public link posted in a non-public section of Composr probably should not be flagged as broken if it throws a forbidden status.

c) Redirects: Actually, these should probably also be flagged as broken in certain cases. For instance, links posted in the docs / tutorials should definitely be flagged as broken if they return a redirect. That way, developers are informed of the stale link and are then encouraged to get the updated link and update the tutorials / docs accordingly. But any links posted on a Composr site itself which throw a redirect, except maybe for public links that can be viewed by Guest, probably should not be flagged as broken. While they may appear wrong on the site as they will have the old link, clicking on them will simply take the user to the new page. Though, we also need to consider that some websites will use redirects instead of 404 not found when trying to access a post or blog that no longer exists.

This is a generalised response to a pattern I am seeing in a number of issues:

This should be under the main "Composr" project with a severity of "Feature-request". I can understand why someone may want more control/functionality/clarity from the tool than they are getting, but that's a gap between desire and implementation, not a bug. The feature is operating as designed. Even if someone is correct in identifying a feature is useless to everyone as it isn't doing enough for anyone, it still doesn't follow that improving that feature should be considered a bug fix - other options would include removing the feature entirely, or documenting its limitations and the need for investment.
Extending functionality is a broader planning process to be had outside of the context of bug fixing, and should be subject to that, not slipped through as feature creep.

I was under the impression this was not working as it was designed for the indicated status codes. Due to this issue, the broken URL notifications get populated very quickly if anyone links things that require login (such as anything on X).

Oh, we're talking about Comcode? I thought we were talking about the standalone tool.
I'd agree checking in Comcode should have a much higher bar for "broken".

I'm not sure. It's whatever creates the notifications for it. I believe Health Check. Comcode does the same thing though.

Right. That makes more sense to me.