MCP server frequently disconnects and fails to restart when Unity still owns the configured HTTP port

[JOY]

Summary

Funplay MCP for Unity frequently disconnects or becomes unresponsive in a Unity project, then fails to restart with an HTTP transport bind error even though the port is owned by the same Unity Editor process.

This looks like a server lifecycle / idempotent-start issue: an existing listener can remain alive or partially alive, while a later start path attempts to bind the same port again instead of detecting/reusing/stopping the existing transport cleanly.

Environment

• OS: Windows 11
• Unity: 6000.5.0b8
• Funplay MCP for Unity: v0.3.4
• Transport: HTTP
• Tool exposure: full
• Port used: 8766
• Client configured: Codex

Symptoms

1. The MCP server appears as running in the Unity window.
2. MCP tool calls from the client may later time out or disconnect.
3. Toggling the server off/on, restarting Unity, or domain reload can lead to startup failure.
4. Unity Console reports:

[Funplay MCP Server] Failed to start HTTP transport: Only one usage of each socket address (protocol/network address/port) is normally permitted.
UnityEngine.Debug:LogError (object)
Funplay.Editor.MCP.Server.HttpMCPTransport/<StartAsync>d__12:MoveNext () (at ./Library/PackageCache/com.gamebooom.unity.mcp@b600f4e2b1d3/Editor/MCP/Server/HttpMCPTransport.cs:79)
Funplay.Editor.MCP.Server.MCPServerService/<StartAsync>d__26:MoveNext () (at ./Library/PackageCache/com.gamebooom.unity.mcp@b600f4e2b1d3/Editor/MCP/Server/MCPServerService.cs:111)
Funplay.Editor.MCP.Server.FunplayMCPWindow/<>c__DisplayClass18_0:<BuildUI>b__0 (at ./Library/PackageCache/com.gamebooom.unity.mcp@b600f4e2b1d3/Editor/MCP/Server/FunplayMCPWindow.cs:124)

[Funplay MCP Server] Failed to start transport
UnityEngine.Debug:LogError (object)
Funplay.Editor.MCP.Server.MCPServerService/<StartAsync>d__26:MoveNext () (at ./Library/PackageCache/com.gamebooom.unity.mcp@b600f4e2b1d3/Editor/MCP/Server/MCPServerService.cs:121)

On the same machine, Windows reports the configured port is owned by Unity itself, not by a stale node/client process:

LocalAddress LocalPort State      OwningProcess
::1          8766      Listen     152460
127.0.0.1    8766      Listen     152460
127.0.0.1    8766      CloseWait  152460
127.0.0.1    8766      Established 152460

ProcessName: Unity
Path: D:\Program Files\Unity Hub\Editors\6000.5.0b8\Editor\Unity.exe

Expected behavior

• Starting the MCP server should be idempotent.
• If the transport is already running in the same Unity process, Start should treat it as running or cleanly restart it before binding again.
• Stop/Dispose should tolerate already-disposed listeners without throwing noisy errors.
• Domain reload / assembly reload / Unity restart recovery should not leave the server UI in a running-but-unusable state.

Actual behavior

• The server can show as running but client calls time out.
• A later start path tries to bind the same port again and fails with Only one usage of each socket address....
• The only reliable recovery is usually changing port or fully restarting Unity, and even then the issue may return.

Related observation

A separate stop/dispose error was also seen earlier:

[Funplay MCP Server] Error stopping HTTP transport: Cannot access a disposed object.
Object name: 'System.Net.HttpListener'.
Funplay.Editor.MCP.Server.HttpMCPTransport:Stop () (at ./Library/PackageCache/com.gamebooom.unity.mcp@.../Editor/MCP/Server/HttpMCPTransport.cs:108)
Funplay.Editor.MCP.Server.HttpMCPTransport:Dispose () (at ./Library/PackageCache/com.gamebooom.unity.mcp@.../Editor/MCP/Server/HttpMCPTransport.cs:373)
Funplay.Editor.MCP.Server.MCPServerService:StopSync () (at ./Library/PackageCache/com.gamebooom.unity.mcp@.../Editor/MCP/Server/MCPServerService.cs:155)
Funplay.Editor.MCP.Server.MCPServerDomainReloadHandler:OnBeforeReload () (at ./Library/PackageCache/com.gamebooom.unity.mcp@.../Editor/MCP/Server/MCPServerDomainReloadHandler.cs:65)

This may be related to listener lifecycle cleanup around reloads.

Suggested fix direction

• Add a guard in MCPServerService.StartAsync so repeated Start calls do not create a second HTTP transport when one is already running or starting.
• Make HttpMCPTransport.Stop() and Dispose() idempotent and safe when the underlying HttpListener is already disposed.
• On bind failure, detect whether the current Unity process already owns the port and surface a clearer "already running / stale state" message, or recover by stopping the old listener before retrying.
• Consider cleaning up CloseWait connections or adding a health probe that reconciles UI state with actual listener state.

Thanks for the project. The embedded Unity-side server approach is very convenient when it stays connected; this lifecycle issue is the main blocker in day-to-day use right now.

[Winlifes]

Thanks for the detailed report and the PR.

Fixed in v0.3.6: https://github.com/FunplayAI/funplay-unity-mcp/releases/tag/v0.3.6

What changed:

• MCPServerService.StartAsync is now idempotent across overlapping window/settings/domain-reload start paths. If a start is already in progress, later calls reuse the same in-flight task instead of creating another HTTP transport.
• Failed or cancelled starts now clean up partially initialized transport, request handler, resource provider, and running state.
• HttpMCPTransport.Stop() / Dispose() are now safe when the underlying HttpListener has already been stopped or disposed.
• Address-in-use retry detection now covers Windows variants (10048, 183, Only one usage...) and Mono/Unity listener conflicts such as There's another listener for ....

Validation performed before release:

• Unity compile and domain reload auto-recovery passed.
• MCP JSON-RPC checks (tools/list, resources/list, prompts/list, execute_code) passed after reload.
• Port-occupied restart stress passed: 12 concurrent StartAsync calls while the port was temporarily occupied reused one in-flight startup and recovered after the port was released.
• Listener check showed exactly the expected local IPv4/IPv6 listeners after recovery.
• Unity console and Editor.log checks showed no Failed to start, disposed-listener, address-in-use, or null-reference errors after the final patch.

I also published the wrapper package to NuGet and MCP Registry as 0.3.6. Closing this as fixed, but please comment again if the Windows 11 / Unity 6000.5.0b8 setup can still reproduce it after updating.

[Winlifes]

Fixed and released in v0.3.6.

[JOY]

The PR was made in v0.3.6.

[Winlifes]

Thanks for clarifying. You are right: v0.3.6 fixed the startup race, cleanup, and retry parts of this issue, but it does not fully cover the remaining case you are testing.

The remaining v0.3.6 gap is: an existing Funplay HTTP listener can already be alive and responsive on the configured port, but a fresh transport still attempts to bind the same port instead of reconciling with that existing listener.

I am reopening this issue to track that remaining case. PR #7 is the right follow-up direction, but I still want the final implementation to use a stricter project identity check and clearer attached/listener ownership semantics before merging.

[Winlifes]

Released v0.3.7 with the remaining existing-listener case fixed: https://github.com/FunplayAI/funplay-unity-mcp/releases/tag/v0.3.7

What changed beyond v0.3.6:

• initialize now includes a Funplay project identity derived from a normalized project-path hash, so the raw local path is not exposed.
• When the configured HTTP port is already occupied, the transport probes the existing endpoint and attaches only if both serverInfo.name and funplay.projectIdentity match.
• Attached transports now detach without closing the owning listener; owned transports still close their own HttpListener normally.
• Probe timeout/unresponsive-listener cases are treated as probe failures, not caller cancellation.
• The MCP Server window now distinguishes attached state from owned-listener running state.

Validation before release:

• Unity compile and domain reload recovery passed.
• MCP JSON-RPC checks passed: initialize, tools/list, resources/list, prompts/list, and execute_code.
• New EditMode tests passed for same-project attach, same-name different-project rejection, and unresponsive listener timeout handling.
• Unity console and compilation checks showed no errors or warnings.
• GitHub Release, NuGet funplay.unity.mcp 0.3.7, and MCP Registry io.github.FunplayAI/funplay-unity-mcp 0.3.7 are all published.

Thanks again for the Windows/Unity 6 repro and PR #7. Closing this as fixed in v0.3.7, but please reopen/comment if the same setup can still reproduce after updating.