Stateless Streamable HTTP MCP Server: Token refresh works after short idle, but reconnect loop after long idle

ChatGPT Apps SDK
1

I’ve built a stateless Streamable HTTP MCP server with OAuth 2.1 authentication. It works perfectly with Claude’s MCP connector but exhibits inconsistent behavior with ChatGPT depending on how long the connection has been idle.

Setup

  • Stateless Streamable HTTP transport (no session IDs)

  • OAuth 2.1 with 10-minute access token expiry

  • Server returns 401 with proper WWW-Authenticate header when token expires:

    WWW-Authenticate: Bearer realm="...", resource_metadata="https://...", error="invalid_token", error_description="Token has expired"

Expected Behavior

When a POST /mcp fails with 401 due to expired token, ChatGPT should:

  1. Call the token endpoint to refresh the access token
  2. Retry the POST /mcp with the new token

Actual Behavior

Short idle (~11 minutes) - Works correctly:

  1. POST /mcp → 401
  2. ChatGPT refreshes token via /token endpoint :white_check_mark:
  3. POST /mcp with new token → 200 :white_check_mark:

Long idle (~2 hours) - Broken:

  1. POST /mcp → 401
  2. ChatGPT does NOT call /token endpoint :cross_mark:
  3. GET /mcp with Accept: text/event-stream (attempting SSE reconnect?)
  4. Server returns 400/405 (stateless server, no SSE stream)
  5. Loop/failure

Key Observations

The GET request after long idle looks like this:

Method: GET
Accept: text/event-stream
User-Agent: openai-mcp/1.0.0

It appears ChatGPT has an internal session timeout (perhaps ~1 hour?) after which it treats the MCP connection as “dead” and attempts to re-establish via SSE GET rather than simply refreshing the OAuth token.

Per the MCP spec, a stateless Streamable HTTP server can return 405 on GET requests if it doesn’t offer an SSE stream. ChatGPT doesn’t handle this gracefully after its internal timeout.

Questions

  1. Is this internal session timeout intentional?
  2. Should stateless Streamable HTTP servers (no SSE) be supported after long idle periods?
  3. Is there a workaround other than implementing a dummy SSE endpoint?

Environment

  • MCP Protocol Version: 2025-06-18
  • ChatGPT connector
1 Like
2

I have the exact same problem. I am building a stateless MCP server (SSE is disabled) with C# .Net core MCP SDK. My server only answers to POST requests and the /GET causes a 405 error. At random, openai client (via portal) tries a GET to my /mcp, fails and returns an error.

1 Like
3

I’m seeing this exact issue as well. Glad to see I’m not crazy! Following this thread..

1 Like
4

Follow up. It appears that at least as of today this is no longer an issue. I haven’t changed anything in my remote connector MCP server, but as of this morning I’m not seeing this issue.

I’m assuming that OpenAI must have deployed some kind of change that either accidentally or intentionally fixed this issue.

1 Like