WEPoll loopback connection fails when mcp-proxy-all.jar is launched as subprocess by Claude Desktop on Windows 11

[shivamkumarcyber]

Note: This issue was initially reported to PortSwigger Technical Support via email, and they directed me to raise it here on GitHub for proper tracking.

Environment

• OS: Windows 11 Pro Build 26200.8246
• Burp Suite Professional (latest)
• Claude Desktop (.exe non-Store version)
• Tested with: Burp bundled JRE, OpenLogic JDK 21.0.9, Eclipse Adoptium JDK 17

Summary
When Claude Desktop launches mcp-proxy-all.jar as a child process, it consistently fails with a WEPollSelectorImpl loopback connection error. Running the exact same command manually from PowerShell works perfectly.

Error from logs
java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.init(PipeImpl.java:96)
at sun.nio.ch.WEPollSelectorImpl.(WEPollSelectorImpl.java:78)
at sun.nio.ch.WEPollSelectorProvider.openSelector(WEPollSelectorProvider.java:33)
Caused by: java.net.SocketException: Invalid argument: connect
at sun.nio.ch.UnixDomainSockets.connect0(Native Method)

Steps to reproduce

1. Install Burp Suite Professional on Windows 11
2. Install the Burp MCP Server extension
3. Enable MCP server on 127.0.0.1:9876
4. Install Claude Desktop (.exe version)
5. Click Install to Claude Desktop in Burp MCP extension
6. Start Burp Suite first, then open Claude Desktop
7. Check MCP logs at: C:\Users[user]\AppData\Roaming\Claude\logs\mcp-server-burp.log

Expected
Claude Desktop connects to Burp MCP server and tools are available.

Actual
Every attempt fails with WEPoll loopback connection error. SSE connection times out after 15 seconds.

Key observation
Running manually works perfectly:
java.exe -jar mcp-proxy-all.jar --sse-url http://127.0.0.1:9876
INFO SseClient - Successfully connected to SSE server at http://127.0.0.1:9876

But the same command launched as subprocess by Claude Desktop fails every time.

Workaround found
Claude Code (command line tool) connects to Burp MCP successfully without any WEPoll errors. The issue is specific to Claude Desktop spawning the subprocess, confirming the bug is in how the jar handles the restricted subprocess environment.

Things already tried (none worked)

• Multiple JDKs (Burp JRE, OpenLogic JDK 21, Adoptium JDK 17)
• Adding -Djava.net.preferIPv4Stack=true and -Djava.net.preferIPv4Addresses=true flags
• Batch script wrapper instead of direct Java command
• Reinstalling Claude Desktop (both Store and .exe versions)
• Resetting Windows network stack (netsh winsock reset)
• Changing TEMP/TMP environment variables to C:\Temp
• Running loopback exemption via CheckNetIsolation
• Disabling Windows Defender real-time protection completely
• Full Windows reboot after every major change

Root cause hypothesis
The mcp-proxy-all.jar uses Ktor's WEPollSelectorProvider which requires Unix domain socket loopback pipes. These fail when Java is spawned as a child process by Claude Desktop but work fine when launched directly from terminal. The jar should fall back to a different selector provider when WEPoll fails.

Request
Please patch mcp-proxy-all.jar to fall back to a different selector provider when WEPoll fails.

Evidence
java.io.IOException: Unable to establish loopback connection

Caused by: java.net.SocketException: Invalid argument: connect

Please find the attached log file mcp-server-burp.log from Claude Desktop's MCP logs directory for your reference

mcp-server-burp.log