Port in use

[wacky444]

After using mcp for a while in windows since it starts the server automatically each time unity recompiles the code it ends up throwing port already in use and the mcp server doesn't respond.

Maybe an option to disable auto start.

I'am using copilot in visual studio code.

[Prikalel]

Yes i have the same trouble
Using cline in vs code

[SujanMishra]

yes same thing
Port 6400 is already in use. Ensure no other instances are running or change the port.
UnityEngine.Debug:LogError (object)
UnityMcpBridge.Editor.UnityMcpBridge:Start () (at Library/PackageCache/com.justinpbarnett.unity-mcp/Editor/UnityMcpBridge.cs:91)
UnityMcpBridge.Editor.UnityMcpBridge:.cctor () (at Library/PackageCache/com.justinpbarnett.unity-mcp/Editor/UnityMcpBridge.cs:53)
UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes (System.Type[])

[RandomNameQ]

same

[zhengjianhua1]

same, close vscode then start bridge is ok

when vscode is opening

The close method of TCPListener in Unity code does not work

when close Unity

netstat -ano | find "6400"
TCP 127.0.0.1:6400 0.0.0.0:0 LISTENING 39392

Unity's pid is 39392, but the process does not actually exist

[radaelilucca]

Same issue. Looks like vscode is starting its own server on same port.

[RainlandLuo]

same issue happens after worked a while, the error shows in unity console

[Efe-Oral]

Did you find a solution for Error:Port 6400 is already in use. Ensure no other instances are running or change the port.

[manntera]

Hi, I'm a Japanese user and I'm using AI to help me write this in English, so I apologize in advance if anything sounds strange or incorrect.

I encountered the same issue described in Issue #103 regarding UnityMCP always using port 6400, which was already in use on my machine.

When I checked using the following commands:

netstat -an | findstr 6400
netstat -aon | findstr :6400
tasklist | findstr 3988

I found that port 6400 was being used by svchost.exe (PID 3988), so UnityMCP could not start correctly due to a port conflict.

To resolve this issue, I modified the source code to change the port number from 6400 to another unused port (in my case, I used 6401). I updated all relevant files where port 6400 was hardcoded:

• UnityMcpBridge.cs
• UnityMcpEditorWindow.cs
• DefaultServerConfig.cs
  (located under Library\PackageCache\com.justinpbarnett.unity-mcp@<commit-hash>\Editor\...)

Additionally, I also updated the following Python config file:

• UnityMcpServer\src\config.py
  (typically located at something like:
  C:\Users\<your-username>\AppData\Local\Programs\UnityMCP\UnityMcpServer\src\config.py
  — please adjust for your environment)

After making these changes, the port conflict was resolved and UnityMCP worked as expected.

I hope this helps others facing the same issue.

Thanks!

[manntera]

After changing the port to 6401, the connection was initially successful. However, when I restarted the Unity MCP Bridge, the startup failed again because svchost.exe was once more occupying the same port.

It seems that once Unity MCP Bridge uses a port, that port becomes unavailable for reuse in future sessions — even if it was previously working. This behavior was the root cause of the original issue, and I finally understood what was actually going on. Sorry for the confusion earlier — I may have gone off-topic a bit in my previous message.

I hope this additional information helps clarify the issue for others.

[manntera]

Hi again,
After posting my previous comment, I continued testing and discovered a more specific issue in my environment that might help clarify what's happening. Here's a summary of my setup and what I found:

---

✅ Setup and Purpose

• Environment:

  • An AI agent running persistently on Ubuntu via WSL2
  • Unity running on Windows with unity-mcp
  • Unity MCP Bridge launched on Windows, with the AI agent in WSL2 connecting to the MCP server

• Purpose:

  • To control Unity from the AI agent in WSL2 by connecting to the Unity MCP server over a specific port

---

❗ Problem Observed

1. I successfully connected to the Unity MCP Bridge once.

2. However, after stopping and restarting the Bridge, I got the following error:

   "An attempt was made to access a socket in a way forbidden by its access permissions."

3. Checking with netstat -aon, I found that even after the Bridge was stopped, the port (e.g., 6400 or 6401) was still in LISTENING state, now occupied by svchost.exe (specifically, the IP Helper Service: iphlpsvc).

---

🔍 Root Cause

I realized that the issue was due to this command I had used to enable port forwarding from WSL2 to Windows:

netsh interface portproxy add v4tov4 listenport=6401 listenaddress=0.0.0.0 connectport=6401 connectaddress=127.0.0.1

This portproxy rule causes the Windows IP Helper Service (iphlpsvc) to permanently bind the specified port, even when the Unity MCP Bridge is not running.
As soon as the Bridge is stopped and the port is freed, iphlpsvc takes it over again, preventing the Bridge from reusing it upon restart.

---

🛠 Workaround I Used

✅ Removed all portproxy rules:

netsh interface portproxy delete v4tov4 listenport=6400 listenaddress=0.0.0.0
netsh interface portproxy delete v4tov4 listenport=6401 listenaddress=0.0.0.0

Confirmed with:

netsh interface portproxy show v4tov4

→ The list was empty.

---

✅ Restarted Unity MCP Bridge using a different, unused port (16401)

• I modified all hardcoded references to port 6400 in the Unity MCP source and changed them to 16401
• After rebuilding, the Bridge started successfully and could be restarted without any port binding issues

---

✅ Final Summary

Item	Description
Problem	Unity MCP Bridge fails to bind to its port after restart
Cause	netsh portproxy makes iphlpsvc permanently occupy the specified port
Solution	Delete all portproxy rules and use a new unused port (e.g., 16401) for MCP Bridge

---

I hope this information is useful for anyone else trying to connect from WSL2 or dealing with persistent port binding issues.
Again, I'm using AI to help write this in English, so I apologize if anything is unclear or sounds strange.

Thanks!

[manntera]

Hi again,
Following up once more — I believe I’ve finally found a complete and reliable solution to the port conflict and restart issues with Unity MCP Bridge, especially when used in a WSL2 + Windows setup.

---

✅ Root Cause of the Reconnection Error and Final Solution

Item	Details
Fundamental Fix	I switched WSL’s network mode to mirrored, which allows direct localhost communication between WSL2 and Windows. With this, portproxy is no longer needed and iphlpsvc no longer grabs the port.
Steps:

1. Create or edit %USERPROFILE%\.wslconfig with:

   [network]  
   mode = mirrored  

2. Run wsl --shutdown or reboot Windows

3. Confirm that WSL can now access Unity MCP Bridge directly via localhost:6400 (or whichever port you're using)
   (References: [Microsoft Docs][1], [MS Dev Blog][2]) |
   | Rollback | - Removed all netsh interface portproxy rules

• Also deleted unnecessary firewall exceptions using:

  netsh advfirewall firewall delete rule name="Unity MCP Bridge"  

(In mirrored mode, additional rules for localhost communication are usually not required) |
| Result | Unity MCP Bridge now starts and reconnects successfully every time, using either port 6400 (the original hardcoded value) or 16401, with no port collision or binding errors. |
| Recommendation | - It would be helpful if Unity MCP Bridge could accept its port via environment variable or CLI argument, so users can easily avoid conflicts in the future.

• For setups where mirrored networking is not available, possible alternatives include:

  • Separating the portproxy port and the Bridge port
  • Reserving the Bridge port via OS-level excludedportrange settings |

---

Thanks again for this great project — I hope this info is helpful to others encountering similar issues with WSL2 and port binding!

(As before, I'm using AI to help express this in English, so please forgive any awkward phrasing.)

[bpiltz]

same here. It did not reliably keep the connection, when checking nothing else was using the port. The only thing that helps is restarting the computer. I think it is happening when recompiling or so. Pretty soon. No solid solution atm. Using it under windows 11 with unity6.

[firststef]

same for me in 2025

[msanatan]

This should be fixed in #192, which will be a new version. Thanks for the reports everyone!