[Jayko001]

Summary

MCP clients that cached mcp.onkernel.com's own OAuth endpoints (from its /.well-known/oauth-authorization-server or saved /register, /authorize, /token URLs) still go through the TypeScript OAuth routes. The Kernel API does not recognize the tokens those routes issue: GET /auth/context finds no org record for the JWT, so every MCP request fails with 401 Organization context not found. This happens even right after a successful authorization or refresh.

Production request logs show the pattern across several clients. The client gets a 401 on /mcp, refreshes at mcp.onkernel.com/token (200, outcome: success), and gets 401 again with the new token. Clients registered against auth.onkernel.com are unaffected.

This PR sends those clients to the hosted Go authorization server instead of keeping the TypeScript path alive:

• On mcp.onkernel.com and mcp.dev.onkernel.com, /authorize, /register, /token and /.well-known/oauth-authorization-server now return a 308 to the same path and query on auth.onkernel.com / auth.dev.onkernel.com. 308 preserves the method and body for POST /token and POST /register.
• OPTIONS preflights still reach the existing route handlers, so browser clients get CORS headers before following the redirect.
• Local, preview and any other host keep serving OAuth from this app, using the same host mapping as oauthResourceMetadata. hostedAuthorizationServer is factored out of it.
• /mcp and /.well-known/oauth-protected-resource/mcp are unchanged; they already point at the hosted server.

Behavior for existing credentials

Credentials issued by the TypeScript routes are intentionally not migrated:

• Client IDs registered through the TypeScript /register exist only in Clerk, not in the Go server's client registry, so the Go server rejects them.
• Refresh tokens issued here have no context the Go server can find, so the Go server answers invalid_grant / re-authorize.

Affected clients need to reconnect once. Re-registration now lands on the Go server. Clients whose HTTP stack does not follow redirects on POST /token see a failed refresh and prompt the user to reconnect. Clients that pinned https://mcp.onkernel.com as the issuer and validate RFC 9207 iss strictly may also need a reconnect.

Follow-up, not in this PR: remove the now-unreachable TypeScript OAuth handlers and the Redis proxy path they depend on.

Testing

• bun test: 1140 pass, 0 fail. New cases in src/proxy.test.ts cover both hosted origins, the Host header behind Next, OPTIONS passthrough, non-hosted origins (localhost, preview, look-alike host), and /mcp plus resource metadata staying put.
• bunx tsc --noEmit is clean.
• bun run format:check flags only AGENTS.md, which also fails on main.
• Not exercised against a deployed preview; the redirect only triggers on the production and dev hostnames.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
mcp	Ready	Preview	Oct 30, 2026 9:35pm UTC