bug: jmp mcp serve crashes with cancel scope RuntimeError in asyncio context

[dustinblack]

Environment

• Jumpstarter: release-0.9 branch tip (v0.1.dev1+gfe31f664b)
• Python: 3.13.13
• OS: Fedora 43
• jumpstarter-mcp: installed from release-0.9 branch

Problem

jmp mcp serve crashes when launched as a subprocess from an asyncio application (via MCP stdio transport). The error is:

RuntimeError: Attempted to exit cancel scope in a different task than it was entered in

The traceback points to anyio._backends._asyncio.py line 464.

Reproduction

The MCP server is launched via:

await mcp_client.connect_command(
    command="jmp",
    args=["mcp", "serve"],
    name="jumpstarter",
)

This worked with jumpstarter 0.8.1. With the release-0.9 branch packages, the subprocess starts but the parent process receives a CancelledError, triggering an agent hard-stop.

Context

We use jmp mcp serve to give AI agents access to Jumpstarter device tools (jmp_run, jmp_connect, etc.) via the MCP protocol. The MCP server runs as a stdio subprocess managed by the MCP client library.

Additional notes

• jmp mcp serve is not included in the install.sh package set — the jumpstarter-mcp package must be installed separately
• The CLI entry point in jumpstarter_cli/jmp.py conditionally imports MCP — this is working correctly
• The crash appears to be in the anyio cancel scope handling when the gRPC channel is created inside the MCP server's event loop

[dustinblack]

Update: downgrading anyio from 4.14.2 to 4.9.0 does not resolve the issue. The cancel scope RuntimeError persists at commit cc2706f on release-0.9 with anyio 4.9.0.

The crash happens consistently when the MCP server subprocess (jmp mcp serve) is started via the Python MCP client library (using StdioServerParameters + stdio_client). The subprocess launches, the MCP session initializes, but the parent process receives a CancelledError during the client session's async generator cleanup.

Key versions tested:

• jumpstarter: 0.9.0rc2.dev5+gcc2706f5f (commit cc2706f)
• anyio: 4.9.0 (also tried 4.14.2)
• Python: 3.13.13
• mcp (client library): 1.28.1

Note: this same commit previously worked in a different container environment. The difference may be in the MCP client library version or other transitive dependencies.

[dustinblack]

Root cause identified

The crash is in the MCP client library's stdio_client async generator (mcp/client/stdio/__init__.py:189), not in Jumpstarter code directly. Full traceback:

File "mcp/client/stdio/__init__.py", line 189, in stdio_client
    yield read_stream, write_stream
GeneratorExit

File "mcp/client/stdio/__init__.py", line 183, in stdio_client
    anyio.create_task_group() as tg,
File "anyio/_backends/_asyncio.py", line 821, in __aexit__
    ...
RuntimeError: Attempted to exit cancel scope in a different task than it was entered in

The stdio_client creates an anyio TaskGroup to manage the subprocess I/O. When the parent disconnects (our __aexit__ on the context manager), the GeneratorExit propagates into the task group's cancel scope from a different task context than it was created in.

This affects jmp mcp serve specifically because it's launched as a subprocess via the MCP stdio transport. Other Jumpstarter operations (gRPC direct via ListExporters, CreateLease, etc.) work fine.

Versions tested:

• mcp client library: 1.18.0, 1.28.1 — both crash
• anyio: 4.9.0, 4.14.2 — both crash
• jumpstarter: 0.9.0rc2.dev5+gcc2706f5f (commit cc2706f)
• Python: 3.13.13

What previously worked: This same Jumpstarter commit worked in an earlier container environment. The difference is likely the MCP client library version — it was probably < 1.0 in that environment (the mcp PyPI package started at 0.9.1).

Potential fix: The issue may be in how jumpstarter-mcp's server interacts with the MCP stdio transport's task group lifecycle. If the server's async generators aren't properly scoped to the transport's task group, the cleanup path breaks.

[dustinblack]

Root cause identified: MCP Python SDK bug, not Jumpstarter

This is modelcontextprotocol/python-sdk#577 — a known P1 bug in the MCP client library's async generator cleanup. The cancel scope RuntimeError occurs when the transport context manager (stdio_client, sse_client, streamablehttp_client) is exited from a different asyncio task than it was entered in.

We confirmed this by hitting the identical error connecting to a completely unrelated MCP server (Domain MCP via StreamableHTTP) — same traceback, same cancel scope error, no Jumpstarter code involved.

Jumpstarter is not at fault. The jmp mcp serve process works correctly. The crash is in the MCP client library's transport layer.

This affects all MCP transports (stdio, SSE, StreamableHTTP) on Python 3.13 + anyio 4.x + mcp >= 1.0. The MCP SDK team has labeled it P1 'ready for work' but it's unassigned with no fix timeline.

[dustinblack]

Resolution path identified — fix is on our side

The cancel scope crash only occurs during error/cancellation cleanup paths, not during normal operation. Our disconnect() method uses asyncio.wait_for() which can create task boundary crossings that trigger modelcontextprotocol/python-sdk#577.

We've confirmed that:

• Normal connect → use → disconnect works fine (same task)
• The crash happens when agents are hard-stopped (CancelledError from orchestrator) and cleanup runs from a different task context
• Both stdio and network transports are affected identically

We're implementing a resilient disconnect() that catches the RuntimeError during cleanup. This will fix the Jumpstarter MCP crashes without any changes needed on the Jumpstarter side.

No action needed from the Jumpstarter team. The underlying MCP SDK bug (python-sdk#577) remains open but our workaround handles it.

[dustinblack]

Fix expanded: connection setup cleanup

Our initial fix (removing wait_for from disconnect) only addressed the cleanup path. The Jumpstarter MCP crash also happens during connection setup — when an agent task is cancelled mid-_connect_transport, the stdio_client context manager's __aenter__ has been called but __aexit__ never runs in the same task.

Additional fix: wrap the entire connection sequence in try/except. On any failure or cancellation, clean up partially-entered context managers (session + transport) in the same task before re-raising. This prevents the abandoned context's eventual cleanup from crossing task boundaries.

Both fixes together cover:

1. Connection setup cancelled (agent hard-stopped during attach_jumpstarter_mcp) — new fix
2. Disconnect after cancellation (agent hard-stopped after connection established) — previous fix

Upstream PRs: atheurer/agentic-perf#362 (disconnect), atheurer/agentic-perf#361 (full transport refactor including both fixes).