Cursor MCP client does not restart session on 404 Session not found

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

MCP specification in transports section 2.5 regarding session management it is clearly stated that if server returns 404 Session not found client MUST reinitialise the session, however cursor client does not do that. So, if for example stateless server gets redeployed client usually silently stop using MCP or if forced jsut complains about an error without trying to reinitialise it.

Restarting agent helps

Steps to Reproduce

Deploy and MCP server that does not persist sessions outside in process memory
Use it in the chat
Stop and redeploy server with fresh session list
Ask in the same chat cursor to use MCP

Expected Behavior

When server gets redeployed I expect client retrying and reinitialising session again.

Operating System

MacOS

Version Information

2026.05.16-0338208

For AI issues: which model did you use?

Composer 2 Fast

Additional Information

We use official python sdk for MCP server development. It also could be related to ambiguity in the return codes Clarify JSON-RPC error code for 'session not found' responses · Issue #1821 · modelcontextprotocol/python-sdk · GitHub

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @Pavel_Plotnikov!

Thanks, I can reproduce this. Cursor (the IDE) respects the spec, but the CLI doesn’t right now. I’ve filed a bug with the team. Unfortunately, until that’s resolved, you’ll need to exit and re-run agent whenever the MCP server gets redeployed. That gets you a fresh session and the tool calls work on the first try again.

If it’s easy on your end, running the MCP server with persistent session state (something durable rather than in-process memory) would also sidestep this.

8

Cool, thank you for reproducing it and moving it forward! I do appreciate fast response.

We actually might have a solution for this problem that is okay for our specific use case.

Since our MCP server does not really need session so python MCP sdk has this flag stateless python-sdk/src/mcp/server/streamable_http_manager.py at e8e64842781c66b613872cf394de6e7d6f6925bf · modelcontextprotocol/python-sdk · GitHub .

So when it is True it will create and close session on every request. I will verify this solution in production today or tomorrow but seems works for us.

However, i would appreciate a fix from client side anyway since in the future we might start using sessions :wink:

12

I can reproduce this on Cursor Agent CLI 2026.09.18-9a7762b, including after ordinary idle session expiry—not only server redeployment.

Environment

  • Client: Cursor Agent CLI 2026.09.18-9a7762b
  • OS: Arch Linux ARM64 (Omarchy VM)
  • Server: Noema 0.22.0-rc.1, using Rust MCP SDK (rmcp) 3.1.2
  • Transport: Streamable HTTP over HTTPS
  • Authentication: static bearer token
  • Server session inactivity timeout: five minutes

Reproduction

  1. Establish a fresh MCP connection and successfully invoke a read-only tool.
  2. Wait approximately six minutes without invoking Noema MCP tools.
  3. Confirm independently through the shell that the server PID and service start time are unchanged.
  4. Invoke the same read-only tool.

The call fails with:

Tool execution error. Streamable HTTP error: Error POSTing to endpoint: Not Found: Session not found

Manual reconnection restores successful tool calls without restarting the server.

I also observed the following during the stale-session failure:

  • Tool discovery through GetDynamicTools succeeds, and namespaceStatus remains ready.
  • CallDynamicTool fails for both read and write tools.
  • An unrelated MCP server remains functional.
  • Direct HTTP requests using a freshly initialized session succeed.
  • Direct HTTP requests using an unknown session ID return the same HTTP 404 and response text.

I reproduced failure after a server restart as well. The separate idle test held the PID and service start time constant, showing that a restart is not required.

This is consistent with the client retaining an expired session ID without successfully re-initializing. I have not captured Cursor’s HTTP traffic, so I cannot say whether it attempts an initialization internally; no successful automatic recovery is visible.

Is a fix available after 2026.09.18-9a7762b, or would additional client logs help investigate?

Addendum: cursor-agent mcp CLI does not recover an in-chat stale session

I also tried recovering from a side shell without restarting the agent chat:

  cursor-agent mcp disable noema
  cursor-agent mcp enable noema
  cursor-agent mcp login noema

After that:

• cursor-agent mcp list still reported noema: ready
• cursor-agent mcp list-tools noema successfully listed tools (35)
• The same still-open agent chat continued to fail CallDynamicTool with:

Tool execution error. Streamable HTTP error: Error POSTing to endpoint: Not Found: Session not found

So disable / enable / login refresh approval / CLI loading for that CLI process, but they do not replace the Streamable HTTP Mcp-Session-Id held by an existing agent session. That matches the earlier observation that discovery / ready can look healthy while tool calls remain stuck on a dead session.

Workaround that still works: reconnect MCP in the UI for that session, or start a new agent chat / restart the agent. The CLI toggle is not a substitute for per-session re-initialization after 404 Session not found.