[Bug]: Closing an interactive Unity instance stops the shared HTTP MCP server for all remaining instances

[yyyyyp233]

What happened?

With two or more interactive Unity Editor instances open for different projects, each connected to MCP for Unity over the same local HTTP endpoint, multi-instance discovery and explicit routing work correctly. However, closing any one Editor instance shuts down the HTTP MCP server and disconnects every remaining Editor instance.

This is not an instance-routing problem: before closing an Editor, the client can list all instances and successfully target each one explicitly. The failure occurs during the quitting instance's cleanup path.

Expected behavior

Closing Project A should disconnect only Project A's bridge/session. The shared HTTP server and the MCP sessions for still-running projects (for example, Project B) should remain available.

Actual behavior

Closing Project A causes the local HTTP MCP server to stop. Project B remains open, but its MCP connection is lost and the client can no longer use its tools until the server/session is started again.

Reproduction steps

1. Open Project A in a normal interactive Unity Editor (not batch mode), enable MCP for Unity with HTTP Local transport, and confirm it is connected.
2. Open Project B in another normal interactive Unity Editor with MCP for Unity configured to use the same local HTTP endpoint.
3. From the MCP client, confirm both instances appear in mcpforunity://instances, then call tools against each explicit instance ID successfully.
4. Close only Project A.
5. Observe that the HTTP MCP server stops and Project B, although still running, loses its MCP session.

The issue reproduces whichever interactive Editor instance is closed.

Environment

• OS: Windows
• Unity: 2022.3.62f2
• MCP for Unity package: 9.7.1 (installed from #main)
• MCP server: mcpforunityserver==9.7.1 via uvx
• Transport: HTTP Local, http://127.0.0.1:8080, with --project-scoped-tools
• MCP client: Codex

Related issue

This appears related to #1196, which fixed the same broad symptom for batch-mode Editors by skipping McpEditorShutdownCleanup.OnEditorQuitting() in batch mode.

This report is intentionally separate: it reproduces with normal interactive Editors, so the batch-mode guard does not apply. The current cleanup path still runs for interactive Editors and calls StopManagedLocalHttpServer().

A likely ownership/isolation concern is that the local HTTP server handshake/tracking is stored using global EditorPrefs, while the PID file itself is project-local. When several interactive projects share one HTTP endpoint, an exiting instance must not terminate a server that still has plugin sessions from other live instances.

Additional notes

I have not included project paths, instance tokens, or proprietary project logs. I can provide a sanitized server-log excerpt around the shutdown if maintainers need it.

[yyyyyp233]

Reopening after a current-release retest.

I had closed this issue temporarily to upgrade and verify it. The issue still reproduces with both projects updated to MCP for Unity package v10.1.0 and mcpforunityserver==10.1.0.

Both interactive Editors use HTTP Local at http://127.0.0.1:8080. Before closing either Editor, both instances appear in mcpforunity://instances and can be explicitly routed to. I do not click “Stop Server” or “Disconnect”; I only close one Unity Editor normally.

Closing either Editor still stops the shared HTTP MCP server and disconnects the remaining Editor.

The latest package's quit path appears relevant: McpEditorShutdownCleanup.OnEditorQuitting() calls StopManagedLocalHttpServer(). Its local-server handshake is stored in globally named EditorPrefs keys such as MCPForUnity.LocalHttpServer.LastPidFilePath and MCPForUnity.LocalHttpServer.LastInstanceToken, without a project or instance scope. Multiple projects can therefore overwrite the tracked server ownership before either Editor exits.