Custom connector fails to connect to healthy authless SSE MCP server — Claude opens SSE but never completes MCP handshake

### What happened?

## What happened?

I am trying to connect a self-hosted MCP server to Claude.ai using a Custom Connector.

Claude fails to connect and shows:

"Couldn't register with casa os’s sign-in service."

Reference ID:
ofid_1d935f9824ae8312

The MCP server does NOT require OAuth or authentication.

The server is publicly reachable at:

https://docker-mcp.keluargaelf.my.id/sse

The SSE endpoint is healthy and returns:

HTTP 200
Content-Type: text/event-stream

It also returns a valid SSE endpoint event with a session ID.

## Important evidence

The server is running on a self-hosted CasaOS/Docker environment.

When I attempt to connect from Claude.ai, the server logs show that Claude's connection reaches the SSE endpoint:

[supergateway] New SSE connection from ::ffff:172.17.0.1

The connection is then closed:

[supergateway] SSE connection closed (session ...)
[supergateway] Client disconnected (session ...)

A new SSE connection is then opened and closed again.

However, the server never receives the expected MCP POST/message handshake after the SSE connection.

There are no OAuth endpoints or OAuth authentication requirements on this server.

## Expected behavior

Claude.ai should connect to the public SSE MCP endpoint, complete the MCP initialization handshake, and enumerate the available tools.

## Actual behavior

Claude.ai opens the SSE connection but does not complete the MCP handshake.

The Claude UI then reports:

"Couldn't register with casa os’s sign-in service."

This is confusing because the MCP server does not require sign-in or OAuth.

## Troubleshooting performed

1. Verified the MCP server locally.
2. Verified the server through the LAN IP.
3. Verified the public Cloudflare Tunnel endpoint.
4. Public curl request receives HTTP 200 and a valid text/event-stream response.
5. Verified the SSE endpoint returns the MCP message endpoint/session information.
6. Tested multiple simultaneous SSE connections successfully.
7. Fixed an issue in Supergateway 3.4.3 where multiple SSE connections could trigger:
"Already connected to a transport."
8. After the fix, multiple simultaneous SSE connections work correctly.
9. Claude can reach the SSE endpoint, but still does not continue with the MCP handshake.

## Environment

- Claude.ai Web
- Custom Connector
- MCP transport: SSE
- Authentication: None
- Self-hosted MCP server
- CasaOS
- Docker
- Cloudflare Tunnel
- Supergateway 3.4.3
- Node.js 20
- mcp-server-docker 1.0.0

## MCP server

The MCP server is a Docker MCP gateway that exposes Docker management tools for an allowlisted set of containers.

The server works locally and the public SSE endpoint is reachable.

## Question

Could this be a Claude.ai Custom Connector validation/authentication issue?

In particular, why does Claude attempt to register with a sign-in service when the MCP server is explicitly configured as unauthenticated, and why does the connector stop after opening the SSE connection without completing the MCP initialize/POST handshake?

I would appreciate confirmation whether this is a known issue with the Claude.ai Custom Connector infrastructure.

### What did you expect to happen?

Claude.ai should successfully connect to my publicly accessible, unauthenticated MCP server, complete the MCP initialization handshake, and register the available MCP tools.

The MCP server does not require OAuth or any other authentication.

### Steps to reproduce

1. Run a self-hosted MCP server using SSE transport.
2. Make the MCP SSE endpoint publicly accessible through Cloudflare Tunnel.
3. In Claude.ai, create a Custom Connector using:
https://docker-mcp.keluargaelf.my.id/sse
4. Set Authentication to "None".
5. Attempt to connect/register the connector.
6. Claude successfully reaches the SSE endpoint, which returns HTTP 200 and Content-Type: text/event-stream.
7. The server logs show a new SSE connection from Claude's infrastructure.
8. However, Claude does not continue with the MCP initialization/POST handshake.
9. The connection is closed.
10. Claude then reports: "Couldn't register with casa os’s sign-in service."

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Custom self-hosted MCP server (Docker MCP Gateway / mcp-server-docker)

### Error messages or logs

```shell
Claude.ai shows:

"Couldn't register with casa os’s sign-in service."

Reference ID:
ofid_1d935f9824ae8312

The MCP server is configured with no authentication/OAuth.

Server-side logs when Claude attempts to connect:

[supergateway] New SSE connection from ::ffff:172.17.0.1
[supergateway] SSE connection closed (session ...)
[supergateway] Client disconnected (session ...)

A second SSE connection is then opened and closed.

The server does NOT receive the expected MCP POST/initialize handshake after the SSE connection.

The public endpoint returns:

HTTP 200
Content-Type: text/event-stream

and provides the SSE endpoint/session information successfully.

No OAuth request is received because the server does not require authentication.
```

### Additional context

_No response_

The report names no repository files, tests, or entry points. Start by reproducing the Custom Connector flow against the supplied SSE endpoint and compare the Claude-side result with the server logs showing the missing POST/initialize request. Done means identifying whether the failure is in Claude's connector flow or the server integration, with a reproducible diagnosis.

Vom Indexierungsmodell aus dem Issue-Text verfasst.