Synapse v2.1.7 — "no dead ends"¶
Patch release fixing a live-observed connection failure right after 2.1.6 shipped. No schema migrations.
Fixed¶
POST /mcp/server(no trailing slash) 307-redirected, breaking claude.ai's OAuth connector: live evidence — claude.ai completed the entire OAuth 2.1/PKCE handshake added in 2.1.6 (/register→ 201,/authorize→ 302 with a code,/token→ 200 with a minted access token, all successful) and then reported "Synapse returned an error when connecting." Every subsequentPOST /mcp/serverin the server logs came back307 Temporary Redirect, never 200.
Root cause (pre-existing since 2026-07-13, unrelated to the OAuth work itself):
Starlette's Mount always requires a trailing slash in its match regex
(self.path + "/{path:path}"). A request to the bare mount path (/mcp/server, no
trailing slash) never matches the Mount, so the outer router's redirect_slashes
fallback fires a 307 to /mcp/server/ — before the request ever reaches
BearerAuthMiddleware or FastMCP. This had been true the whole time; it was simply
never exercised end-to-end by a client that both authenticates successfully AND
refuses to follow a 307 on POST (a reasonable SSRF-defensive default that claude.ai's
remote-MCP client apparently applies).
Fixed by registering an explicit route at the bare mount path that forwards to the
SAME guarded ASGI app, manually replicating the scope adjustment a successful Mount
match performs — no HTTP redirect is involved for the bare path anymore, so no client
can choose not to follow it. /mcp/server/ (with trailing slash) continues to work
exactly as before. See
ADR-0090
for the full analysis.
Upgrade notes¶
No schema migrations. If you tried to add the Synapse remote MCP server as a claude.ai "Custom connector" after upgrading to 2.1.6 and it reported "Synapse returned an error when connecting" right after authorizing, retry — it should now connect successfully.