What happened?
Summary: When a Streamable HTTP MCP server reaps an idle session, it returns HTTP 404 with a JSON-RPC -32603 error (Session not found: ). Per the MCP spec, on a 404 to a request bearing an Mcp-Session-Id, the client must start a new session (re-initialize). The Auggie/Cosmos client instead keeps sending the stale session ID, so every subsequent call fails identically until the MCP server is manually reconnected/reloaded.
Evidence: Two independent sessions (a992387e… and c73779bb…) both expired after the same idle window and both showed the no-recovery behavior. Error surfaces from HttpServletStreamableServerTransportProvider.doPost → Endpoint.process as JSON-RPC -32603.
What did you expect to happen?
Per the MCP spec, on a 404 to a request bearing an Mcp-Session-Id, the client must start a new session (re-initialize).
Expected: Client transparently re-initializes a new session on 404 and retries. Actual: Client wedges on the stale session until manual reconnect.
Steps to reproduce
- Connect to a Streamable HTTP MCP server (Jenkins mcp-server plugin, http://jenkins...:8080/mcp-server/mcp).
- Make a successful tool call (session established).
- Leave the session idle past the server's idle timeout (empirically ~65 min; ≤64 min succeeds, ≥70 min fails).
- Make another tool call → fails with Session not found.
- Retry immediately → fails identically, reusing the same dead session ID.
Expected: Client transparently re-initializes a new session on 404 and retries. Actual: Client wedges on the stale session until manual reconnect.
Auggie version
v0.29.0
Request ID
597084df-a915-45bc-8cb6-7b10e3d4707b
Environment details
Environment
- OS: Rocky Linux release 8.10 (Green Obsidian)
- Shell: zsh
- Tool/CLI version: auggie v0.29.0
Anything else we need to know?
Cosmos session ID: 01KV4DWQZXWG0JVR65NBY945GX
What happened?
Summary: When a Streamable HTTP MCP server reaps an idle session, it returns HTTP 404 with a JSON-RPC -32603 error (Session not found: ). Per the MCP spec, on a 404 to a request bearing an Mcp-Session-Id, the client must start a new session (re-initialize). The Auggie/Cosmos client instead keeps sending the stale session ID, so every subsequent call fails identically until the MCP server is manually reconnected/reloaded.
Evidence: Two independent sessions (a992387e… and c73779bb…) both expired after the same idle window and both showed the no-recovery behavior. Error surfaces from HttpServletStreamableServerTransportProvider.doPost → Endpoint.process as JSON-RPC -32603.
What did you expect to happen?
Per the MCP spec, on a 404 to a request bearing an Mcp-Session-Id, the client must start a new session (re-initialize).
Expected: Client transparently re-initializes a new session on 404 and retries. Actual: Client wedges on the stale session until manual reconnect.
Steps to reproduce
Expected: Client transparently re-initializes a new session on 404 and retries. Actual: Client wedges on the stale session until manual reconnect.
Auggie version
v0.29.0
Request ID
597084df-a915-45bc-8cb6-7b10e3d4707b
Environment details
Environment
Anything else we need to know?
Cosmos session ID: 01KV4DWQZXWG0JVR65NBY945GX