(sse) mcp restarts breaks communication

[f1-outsourcing]

Before submitting your bug report

• I've tried using the "Ask AI" feature on the Continue docs site to see if the docs have an answer
• I'm not able to find a related conversation on GitHub discussions that reports the same bug
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

Description

I have been getting familiar with llm's, mcp etc now even changing some code. I noticed that when the mcp is restarted continue is not re-establishing the session. I think it just wants to continue with the old session.

You should adapt the code that if communication fails you try and get a new session. Currently I have only been working on sse mcp's maybe the http streaming protocol does not have this disadvantage.

To reproduce

No response

Log output

[Aigen-Protocol]

Good catch. The root cause is a session-vs-connection lifetime mismatch in the SSE transport.

What's happening

In the SSE MCP transport, a session is established via the handshake at connection start. The session ID that comes back is only valid for the lifetime of that SSE stream. When the MCP server restarts, the stream closes — but the client holds onto the old session ID and tries to reuse it on the next request, which the restarted server rejects (it has no memory of that session).

The protocol doesn't guarantee session portability across connections. Each new SSE connection needs to start fresh with a new exchange.

The fix pattern

On detecting SSE stream close (or any response from the server with an unknown-session error), the client should:

1. Discard the current session ID
2. Wait for reconnect
3. Re-send before any tool calls — treat it like a cold start, not a resume

This is a missing reconnection policy, not a bug in the protocol itself. The spec leaves reconnection behavior up to the implementer.

Why is cleaner here

The HTTP streaming transport (as you guessed) sidesteps this because sessions are optional — each POST to can either carry a session ID or omit it. Omitting it means stateless mode: the server processes the request without needing prior context. Reconnection is just a new POST.

The tradeoff is that streaming HTTP requires the client to hold the response stream open, but per-request reconnection is trivial since there's no separate session establishment step.

Practical workaround while the fix lands

If you need this working now: after an MCP restart, manually disconnect and reconnect Continue from the IDE (not just retry) to force a new . The CLI flag may also help if it's wired to a full session reset rather than a stream-level retry.