Workspace deploy: root /.well-known/* is routed to Dispatch and ignores the app path suffix, so OAuth discovery for a spoke app's MCP server fails with invalid_request

[efernandezr]

Workspace deploy: root /.well-known/* is routed to Dispatch and ignores the app path suffix, so OAuth discovery for any spoke app's MCP server lands on Dispatch's authorization server and fails

Version: @agent-native/core 0.178.1, dist/deploy/workspace-deploy.js (Vercel routes: { src: "/\\.well-known/(.*)", dest: "/dispatch-server" }; the Netlify and gateway variants do the same), dist/mcp/oauth-route.js (handleAuthorize, getMcpOAuthAudiences).

What happens. In a path-mounted workspace (/chat, /documents, /brand-assets, /dispatch on one host), a spoke app's MCP endpoint advertises itself correctly: GET /chat/mcp returns WWW-Authenticate: Bearer resource_metadata="https://host/chat/.well-known/oauth-protected-resource", and that document names authorization_servers: ["https://host/chat"], whose /chat/.well-known/oauth-authorization-server points at /chat/mcp/oauth/authorize. Claude (claude.ai custom connector) resolves the metadata with the RFC 8414 / RFC 9728 path-insertion form at the site root instead: GET https://host/.well-known/oauth-authorization-server/chat (and /.well-known/oauth-protected-resource/chat/mcp). The deploy routes every /.well-known/* request to the Dispatch server, and Dispatch's handler ignores the suffix, so both documents come back with issuer: https://host/dispatch and authorization_endpoint: https://host/dispatch/mcp/oauth/authorize. Claude then opens /dispatch/mcp/oauth/authorize?...&resource=https://host/chat/mcp; Dispatch's getMcpOAuthAudiences only contains its own /dispatch/mcp prefixes, so handleAuthorize answers {"error":"invalid_request","error_description":"Invalid OAuth authorization request"}. Observed 2026-09-12 on a Vercel production deployment for the Chat, Documents and Assets connectors; the Dispatch connector works because its resource is its own.

Why. Path-insertion discovery is what the RFCs prescribe for resources that live under a path, and popular hosts use it. The root well-known route exists so the workspace has one discovery document, but it is not suffix-aware, and the spoke apps' authorization servers are never reachable through it.

Expected. One of: the root /.well-known/oauth-authorization-server/<app>[/mcp] and /.well-known/oauth-protected-resource/<app>/mcp routes forward to that app's own documents (a route per registered workspace app, or a suffix-aware handler in Dispatch); or Dispatch acts as the workspace authorization server for every app and getMcpOAuthAudiences accepts every registered app's /<app>/mcp resource; or the docs state that in a path-mounted workspace only the Dispatch connector supports OAuth hosts and spoke apps need the bearer fallback.

Impact. In a path-mounted workspace no spoke app can be added to claude.ai (or any host using path-insertion discovery) as its own connector; users get an opaque invalid_request page after clicking Connect.

Workaround in Joney. Use the Dispatch connector (/dispatch/mcp, verbs list_apps, ask_app, open_app) from claude.ai; for hosts that accept a static header (Claude Code, Cursor), mint a token on /<app>/mcp/connect.

[steve8708]

@builderio-bot please run /address-feedback in the repo to address this feedback. Read the address-feedback, address-feedback-with-replies, review-latest-feedback, and review-prs skills as relevant, inspect the linked evidence, and fix the owning boundary. Please send a PR when ready.

Factory item: ebad13383c8da384a1c15f6cc9fe924366fd9e66c9eaf031b46acf078a2f808a

Source: #4866

Why this is a clear bug: Concrete reproducible OAuth discovery failure in path-mounted workspaces: root /.well-known routes ignore the app suffix, return Dispatch metadata, and the resulting authorization request fails with invalid_request for spoke-app MCP connectors. The issue includes affected routes, observed behavior, expected routing options, and a workaround.

Error report:

Workspace deploy: root /.well-known/* is routed to Dispatch and ignores the app path suffix, so OAuth discovery for any spoke app's MCP server lands on Dispatch's authorization server and fails

Version: @agent-native/core 0.178.1, dist/deploy/workspace-deploy.js (Vercel routes: { src: "/\\.well-known/(.*)", dest: "/dispatch-server" }; the Netlify and gateway variants do the same), dist/mcp/oauth-route.js (handleAuthorize, getMcpOAuthAudiences).

What happens. In a path-mounted workspace (/chat, /documents, /brand-assets, /dispatch on one host), a spoke app's MCP endpoint advertises itself correctly: GET /chat/mcp returns WWW-Authenticate: Bearer resource_metadata="https://host/chat/.well-known/oauth-protected-resource", and that document names authorization_servers: ["https://host/chat"], whose /chat/.well-known/oauth-authorization-server points at /chat/mcp/oauth/authorize. Claude resolves path-insertion discovery at the site root, but every /.well-known/* request is routed to Dispatch and the suffix is ignored. Discovery returns Dispatch metadata; authorization then fails with {"error":"invalid_request","error_description":"Invalid OAuth authorization request"} because Dispatch only accepts its own MCP audiences. Reproduce with any spoke app MCP connector in a path-mounted workspace.

Expected. Route suffix-aware discovery to the selected app, or make Dispatch accept registered app MCP audiences, or document the bearer fallback clearly.

Impact. Spoke apps cannot be added as independent OAuth connectors; users get an opaque invalid_request page. Workaround: use the Dispatch connector or a static bearer token where supported.

Include the Factory item id and source link in the pull request description.

[steve8708]

Thanks for filing this issue and for the detailed report. The routing fix is in #5010, which is still under review. I’ll mark this resolved after it merges and is available in a release.

[steve8708]

Thanks for the detailed report. Fixed in #5010: path-inserted OAuth discovery now routes to the workspace app instead of Dispatch, and the PR has merged. I am closing this issue; please reopen if a spoke-app connector still returns invalid_request on a release containing the fix.