Update 3: Third Independent Capture — 84 Token Verifications for 12 Tool Calls
I just ran another query through ChatGPT with my MCP server connected. I was prompted to re-authenticate seven times during a single conversation turn. The server-side telemetry for that turn is below.
This is a third independent forensic capture, taken hours after the captures in my previous post. The connector behavior has not changed.
The Numbers
┌────────────────────────────────────┬──────────────┐
│ Metric │ Value │
├────────────────────────────────────┼──────────────┤
│ Wall-clock duration │ 14.5 minutes │
├────────────────────────────────────┼──────────────┤
│ MCP sessions created │ 20 │
├────────────────────────────────────┼──────────────┤
│ Active session count (start → end) │ 55 → 73 │
├────────────────────────────────────┼──────────────┤
│ Actual tool calls completed │ 12 │
├────────────────────────────────────┼──────────────┤
│ OIDC token verifications │ 84 │
├────────────────────────────────────┼──────────────┤
│ DELETE requests sent │ 0 │
├────────────────────────────────────┼──────────────┤
│ Session IDs reused across batches │ 0 │
└────────────────────────────────────┴──────────────┘
Let that ratio sink in: 84 token verifications for 12 tool calls. The connector spent 7x more effort on authentication ceremony than on actual work. Every one of those 84 verifications succeeded — valid token, valid scopes, offline_access present, expiry hours in the future. The tokens are fine. They have always
been fine.
Burst Pattern: 5 Re-Initializations in 34 Seconds
The worst burst during this session:
22:46:12Z initialize → new session (active: 63)
22:46:22Z initialize → new session (active: 64) +10s
22:46:31Z initialize → new session (active: 65) +9s
22:46:35Z initialize → new session (active: 66) +4s
22:46:46Z initialize → new session (active: 67) +11s
Five new MCP sessions in 34 seconds. Each one sends mcp_session_id: null, gets session_found: false, creates a new session, makes 0–2 tool calls, then discards the session and starts over. This is what “re-authenticate 7 times in a single query” looks like from the server side.
Session Leak at Scale
By the end of this session, the server was tracking 73 active sessions — all from chatgpt-mcp-connector, all orphaned, zero DELETE requests received. The session count only went down when my server’s 24-hour TTL cleanup ran. Without that cleanup, this would be an unbounded memory leak against every MCP server
OpenAI connects to.
For context, my Claude Code MCP client created 1 session during the same window and reused it for every tool call. Session reuse is not a novel engineering challenge.
This Bug Is Systemic Across OpenAI’s MCP Integration
I’ve now spent considerable time investigating whether there’s anything I can do server-side to work around this. The answer is no — but the investigation revealed something worse.
OpenAI’s own Agents Python SDK has the same bug. Issue #924 (open since June 2025): MCPServerStreamableHttp discards the get_session_id callback from the underlying MCP SDK, retaining only the read/write streams. This makes stateful sessions impossible for anyone using OpenAI’s own SDK to connect to MCP servers.
This means session persistence isn’t just broken in the ChatGPT connector — it was never implemented in the Agents SDK either. The pattern is consistent: OpenAI’s MCP integration treats sessions as disposable at every level of their stack.
The MCP specification (2025-11-25) is unambiguous:
After receiving a session ID, the client MUST include it in the Mcp-Session-Id header on all subsequent HTTP requests to the server.
There is no server-side mechanism in the spec to force a non-compliant client to reuse sessions. A server cannot reject a valid initialize request. The only community “workaround” is stateless_http=True — abandoning MCP sessions entirely, which defeats the purpose of the protocol’s session management.
Timeline
│ Date │ Event │
│ Nov 3, 2025 │ First report (HungryHippo5): “fresh MCP session each invocation”
│ Nov 20, 2025 │ Confirmed regression after brief fix (dannyyy.jimenez)
│ Jan 15, 2026 │ Independent confirmation (Alokai): “every request produces a completely new mcp-session-id”
│ Jan 20, 2026 │ My first report in this thread
│ Jan 21, 2026 │ Root cause identified with header logging evidence
│ Feb 13, 2026 │ Related report (Tarun Agarwal): “ChatGPT does not re-trigger OAuth on 401”
│ Feb 27, 2026 │ Three independent forensic captures with full telemetry
│ Jun 23, 2025 │ OpenAI Agents SDK Issue #924 filed — same root cause in their own SDK
Six reports from independent developers over four months. The user-agent string is still openai-mcp/1.0.0 — unchanged since the first report. No official response from OpenAI on any of these threads.
What I Need From OpenAI
- Acknowledgment that this is a known bug. Four months of silence on multiple independent reports is not acceptable.
- Persist Mcp-Session-Id at conversation scope, not on the SSE transport object. My Capture 1 proved the connector can survive SSE reconnections — the session ID just isn’t stored durably.
- Send DELETE when conversations end. Zero cleanup signals means every MCP server is leaking sessions.
- Fix openai-agents-python Issue #924. The Agents SDK discards get_session_id entirely — this needs to be stored and exposed so that agent developers can build stateful MCP interactions.
I have raw JSONL audit logs for all three captures. I’m happy to provide them, set up a test endpoint, or get on a call. This bug makes stateful MCP servers unusable from ChatGPT, and the re-authentication prompts make even stateless servers painful to use.