Repository navigation
CODEOWNERS auth paths do not resolve on main, so the auth team is never auto-requested #2604
Description
What
On main, none of the five auth paths in .github/CODEOWNERS resolve to anything. The * catch-all still matches, so reviews are still requested and nothing looks broken. But @modelcontextprotocol/typescript-sdk-auth is no longer auto-requested on auth changes.
v1.x has a byte-identical CODEOWNERS where all five patterns resolve. The file just wasn't revisited when main became a monorepo; its last two commits are #781 and #803, both from July 2025.
Evidence
Matches against the full main tree (1427 entries, no src/ at root):
| Pattern | main |
v1.x |
|---|---|---|
/src/server/auth/ |
0 | 17 |
/src/client/auth* |
0 | 2 |
/src/shared/auth* |
0 | 2 |
/src/examples/client/simpleOAuthClient.ts |
0 | 1 |
/src/examples/server/demoInMemoryOAuthProvider.ts |
0 | 1 |
A dangling pattern would matter less if code-owner review were advisory, but the org ruleset on the default branch sets require_code_owner_review: true. So the catch-all is carrying every auth review.
Where auth code lives now
Roughly, if it's useful:
packages/core/src/auth.ts—SafeUrlSchema,OAuthProtectedResourceMetadataSchema(RFC 9728)packages/core-internal/src/auth/errors.ts,src/shared/auth.ts,src/shared/authUtils.tspackages/client/src/client/auth.ts,authErrors.ts,authExtensions.ts,authSeam.tspackages/server/src/server/middleware/bearerAuth.ts,oauthMetadata.tspackages/middleware/express/src/auth/—bearerAuth.ts,metadataRouter.ts,types.tspackages/server-legacy/src/auth/— 15 files (handlers, middleware,proxyProvider.ts)- Examples:
examples/oauth/,examples/oauth-client-credentials/,examples/bearer-auth/,examples/bearer-auth-web/,examples/shared/src/auth*.ts,examples/cli-client/host/auth.ts
One thing to flag: demoInMemoryOAuthProvider no longer has a source file on main. Only examples/shared/test/demoInMemoryOAuthProvider.test.ts remains, so a new pattern shouldn't point at the old source path.
Questions before anyone writes a patch
I'd rather ask than guess at the mapping:
- Is the auth team still active? If it was folded into the main team during the v2 work, the right fix is deleting the block, not remapping it.
- Should
packages/server-legacy/src/auth/get the same ownership as the current server, or is legacy deliberately out of scope? - Should the
test/trees be owned alongside their packages?
Happy to open the PR once you tell me which shape you want. This is main-only; v1.x is fine as-is.
AI disclosure, per the org AI_POLICY: I researched and drafted this issue with Claude Code. The path counts, the branch comparison against v1.x, and the auth-file inventory were generated by tooling and checked against the GitHub API rather than by hand.
Activity
Lstarsky0 commentedon Aug 13, 2026
@conorbronsdon I had a go at this locally before spotting that you'd offered to send the PR — happy
to stand down if you're still on it.
For what it's worth, the mapping does resolve cleanly if it's useful either way. I followed rename
history (
git log --follow) rather than filename similarity, which lands on ten patterns: theserver-legacyauth tree, the two runtime-neutral server middlewares from #2420/#2422, the expressauth glue from #1907, the
core-internalauth errors,client/auth*,core/src/auth.ts,core-internal/shared/auth*, and the two examples. Checked with git's own gitignore engine(
git -c core.excludesFile=… check-ignore --no-index), the old block matches 0 files onmainandthe new one matches 35.
The only one that needed a judgement call was
demoInMemoryOAuthProvider.ts, which has no renameedge — but
examples/shared/test/demoInMemoryOAuthProvider.test.tskept the old name while importingcreateDemoAuthfrom../src/auth, soexamples/shared/src/auth*looks like the right target.Your first question is the one that decides the shape, though: if
@modelcontextprotocol/typescript-sdk-authwas folded into the main team during the v2 work, thendeleting the block is the correct fix and remapping it is wrong. I can't see org teams so I can't
answer that one. Same for whether
server-legacyshould stay owned — I'd default to keeping it sincethat's what the old pattern covered, but that's a maintainer call.
@felixweinberger if you can settle the team question, one of us can turn this into a PR quickly.