Skip to content

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 subsequent POST /mcp/server in the server logs came back 307 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.