[Bug]: Windows desktop does not start MCP daemon (no listening port, Cursor/OpenCode cannot connect)

[SKYIOUS]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

The Windows desktop application starts normally, but its local MCP daemon never starts.

Because of this, OpenCode, Cursor, and other MCP clients cannot communicate with Open Design.

The MCP client attempts to connect to:

http://127.0.0.1:40778

but the connection is refused because no process is listening on that port.

I verified this using:

Test-NetConnection 127.0.0.1 -Port 40778

and

netstat -ano | findstr 40778

Both confirm there is no listening daemon.

I also searched the repository and documentation and noticed references to ports 7456 and 5175. Testing those ports also shows no service listening.

The desktop application itself appears to work normally (projects can be created, settings open, etc.), but the MCP daemon never becomes available, making all MCP integrations unusable.

Steps to reproduce

1. Install Open Design Desktop 0.12.0 on Windows 11.

2. Launch the desktop application.

3. Keep Open Design running.

4. Configure an MCP client such as OpenCode or Cursor to use Open Design.

5. Invoke any Open Design MCP tool.

6. The MCP client reports that it cannot reach the daemon at:

http://127.0.0.1:40778

7. Verify using:

Test-NetConnection 127.0.0.1 -Port 40778

TCP connection fails.

8. Verify using:

netstat -ano | findstr 40778

No process is listening.

9. Testing ports 7456 and 5175 also shows no listening service.

Expected behavior

Starting the Windows desktop application should automatically start the local MCP daemon.

A local TCP port should become available so MCP clients such as OpenCode and Cursor can connect successfully.

If the daemon cannot be started, the desktop application should indicate the failure and provide diagnostic information.

Open Design version

0.12.0 , Channel: stable, Runtime: Packaged app, Platform: win32, Architecture: x64

Platform

Windows

Logs (optional)

OpenCode reports:

Cannot reach the Open Design daemon at:

http://127.0.0.1:40778

PowerShell:

Test-NetConnection 127.0.0.1 -Port 40778

WARNING: TCP connect to (127.0.0.1 : 40778) failed

netstat -ano | findstr 40778

(no output)

Test-NetConnection 127.0.0.1 -Port 7456

WARNING: TCP connect failed

Test-NetConnection 127.0.0.1 -Port 5175

WARNING: TCP connect failed

Screenshots (optional)

No response

Additional context

No response

[open-design-bot]

🎉 ✨ Welcome to Open Design, @SKYIOUS!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @SKYIOUS — thanks for the very exact Windows repro. The Test-NetConnection + netstat output is helpful here.

A couple of things are clear from the current code: in packaged desktop mode the daemon is not expected to stay on the fixed dev port 7456 — the packaged launcher asks the OS for an ephemeral loopback port and then reports the real URL to MCP clients (apps/packaged/src/sidecars.ts, apps/daemon/src/mcp-install-info.ts). So 127.0.0.1:40778 itself is not the suspicious part; the suspicious part is that nothing is listening there after the app comes up. I also checked #4852 / PR #4865: that work is fixing the copied Windows MCP guide when od is not on PATH, but it does not explain a discovered loopback port refusing connections.

The missing piece now is the packaged-sidecar failure reason. Could you export diagnostics from Settings → About → Export diagnostics while the app is running and attach the zip here? If exporting the bundle is inconvenient, the next-best artifact is the current daemon/latest.log plus desktop/latest.log from that zip. That should let us separate “daemon sidecar crashed during startup” from “desktop stayed up in fallback mode but never got a live daemon.”

[SKYIOUS]

As requested, I've attached the diagnostics ZIP generated from Open Design → Settings → About → Export diagnostics.

open-design-diagnostics-2026-06-29T13-09-53Z.zip

[lefarcen]

Hey @SKYIOUS — thanks for attaching the diagnostics bundle. This changes the diagnosis in a useful way.

From the logs in the zip:

• the packaged daemon is running and reported http://127.0.0.1:31137
• the packaged web sidecar is also running
• so in this capture, the desktop app did not fail to start the daemon
• but the OpenCode log is still trying to call http://127.0.0.1:40778/api/..., which is a different port

So the current working hypothesis is: the MCP client is pinned to a stale loopback port, rather than discovering the live packaged daemon endpoint. In packaged mode that port is ephemeral, so a hard-coded 127.0.0.1:<old-port> entry will break exactly like this. That also makes this look related to #4852 / PR #4865 (Windows MCP config/snippet behavior), more than a daemon-start crash.

Could you try one focused check: remove the existing open-design MCP server entry from OpenCode / Cursor, then re-add it from Settings → Integrations using the current MCP install snippet — not a manually hard-coded http://127.0.0.1:40778 config. If it still comes back pointing at 40778, please paste the exact open-design entry from your OpenCode/Cursor MCP config here and we can narrow down which field is preserving the stale port.

[SKYIOUS]

I tried the suggested approach.

• Cursor: I removed the existing Open Design MCP server and added it again using the built-in Open Design integration (I did not manually hard-code http://127.0.0.1:40778).
• OpenCode: As far as I can tell, there isn't an equivalent "Settings → Integrations" (or Settings → MCP server) UI or a built-in option to re-add the Open Design MCP server. If there's a recommended way to refresh or reinstall the Open Design MCP configuration in OpenCode, could you point me to it?

Since I never manually configured 127.0.0.1:40778, I'm not sure where that stale port is coming from.

If it helps, I can also paste my current Cursor/OpenCode MCP configuration. Could you let me know the exact configuration file or entry you'd like me to share?

[lefarcen]

Hey @SKYIOUS, that’s very helpful — especially the part that Cursor was re-added through the built-in integration and you still never manually entered 40778.

For OpenCode, there isn’t currently an equivalent one-click reinstall UI on the OpenCode side. The most useful thing to compare now is the actual saved MCP entries that each client is reading.

Could you paste these two specific snippets (feel free to redact anything unrelated or secret-looking):

1. Cursor — the open-design entry from:

   • %USERPROFILE%\.cursor\mcp.json

2. OpenCode — the open-design entry from:

   • %USERPROFILE%\.config\opencode\opencode.json

And one extra check for OpenCode, because its config can be layered:

3. If your current project/workspace has a local opencode.json file, please include the open-design block from that too.

The reason I’m asking for exactly those files is that our code writes OpenCode’s saved MCP config to ~/.config/opencode/opencode.json under mcp.open-design, while Cursor uses ~/.cursor/mcp.json. If 40778 is still appearing after a clean re-add, the next likely causes are either:

• one client still has an older saved entry on disk, or
• OpenCode is picking up a higher-priority layered config than the global one.

Once we can see those concrete open-design entries, we should be able to tell where the stale port is being preserved. EOF

[SKYIOUS]

Cursor:

mcp.json

Opencode:

opencode.json

[lefarcen]

Hey @SKYIOUS — these two files are very helpful. They actually rule out one of the main theories.

Both saved MCP entries look correct:

• neither Cursor nor OpenCode has a hard-coded http://127.0.0.1:40778
• both are configured as stdio launches of the packaged Open Design executable
• both include OD_SIDECAR_IPC_PATH, which means the spawned od mcp process should discover the live daemon URL through the named pipe instead of baking an old port

So at this point, 40778 does not appear to be coming from the saved on-disk config.

That narrows it down to two more likely buckets:

1. a stale already-running MCP subprocess that was started before the config refresh, or
2. for OpenCode specifically, a higher-priority layered config (for example a project-local opencode.json) that is still overriding the global file.

Could you try these two focused checks:

1. Fully quit Cursor and OpenCode (not just close the tab/window), then launch them again so they have to spawn a fresh open-design MCP process.
2. For OpenCode, please also confirm whether your current workspace/project has a local opencode.json file. If it does, paste the open-design block from that file too.

If the problem still reproduces after a full client restart, the next most useful artifact will be the fresh error/output after restart — especially whether it still names 40778, and whether that happens in Cursor, OpenCode, or both.

[SKYIOUS]

I tried the additional checks, and unfortunately the behavior is still exactly the same.

Results:

• I fully quit Cursor and OpenCode (not just closed the windows) and launched them again.
• I also restarted Windows to ensure there were no stale MCP subprocesses remaining.
• I completely uninstalled Open Design, verified there were no remaining Open Design processes, then performed a clean reinstall.
• The issue still reproduces after the clean reinstall.
• My OpenCode workspace does not contain a local opencode.json, so there isn't a project-level configuration overriding the global one.

[lefarcen]

Hey @SKYIOUS — thanks for pushing this all the way through restart, reinstall, and the no-local-override check. That rules out a lot.

At this point I think we have a stronger next hypothesis from the code path itself:

od mcp resolves the daemon target in this order:

1. explicit --daemon-url
2. OD_DAEMON_URL environment variable
3. sidecar IPC discovery via OD_SIDECAR_IPC_PATH

Your saved Cursor/OpenCode configs already look correct and include OD_SIDECAR_IPC_PATH, so if the spawned process is still choosing 40778, the most plausible remaining explanation is that OD_DAEMON_URL is set somewhere in the environment and is overriding the named-pipe discovery.

Could you run these in PowerShell and paste the output?

$env:OD_DAEMON_URL
[Environment]::GetEnvironmentVariable('OD_DAEMON_URL', 'User')
[Environment]::GetEnvironmentVariable('OD_DAEMON_URL', 'Machine')

If any of those prints http://127.0.0.1:40778 (or any old loopback URL), that would explain why both clients keep using the stale port even though the saved MCP config is fine.

If they all come back empty, then the next suspect is a Windows-specific bug in the packaged od mcp discovery path itself, and this issue becomes a code-side fix rather than a local config problem.

[SKYIOUS]

PS C:\Users\nanda> $env:OD_DAEMON_URL
http://127.0.0.1:40778
PS C:\Users\nanda> [Environment]::GetEnvironmentVariable('OD_DAEMON_URL', 'User')
http://127.0.0.1:40778
PS C:\Users\nanda> [Environment]::GetEnvironmentVariable('OD_DAEMON_URL', 'Machine')

Also the od command does not work in my pc

[lefarcen]

Hey @SKYIOUS — perfect, that confirms the main cause for this repro.

OD_DAEMON_URL is set at User scope to http://127.0.0.1:40778, and od mcp checks that variable before it falls back to the named-pipe / sidecar discovery path. So even though your saved Cursor/OpenCode MCP entries are correct, the spawned process is still being forced onto the stale loopback port.

Could you try this cleanup in PowerShell:

[Environment]::SetEnvironmentVariable('OD_DAEMON_URL', $null, 'User')
Remove-Item Env:OD_DAEMON_URL -ErrorAction SilentlyContinue

Then fully quit Cursor and OpenCode again and launch them fresh. After that, this should come back empty:

$env:OD_DAEMON_URL
[Environment]::GetEnvironmentVariable('OD_DAEMON_URL', 'User')

One more note: the od command not working on your PC is a separate Windows packaged-install issue — the packaged app currently does not reliably expose od on PATH, which is the same bug family tracked in #4852 / PR #4865. It should not block this specific stale-port fix once OD_DAEMON_URL is cleared.

If you try the cleanup above, let me know whether Cursor/OpenCode still mention 40778 afterwards.

[SKYIOUS]

That was it! Thank you.

I ran the cleanup commands you suggested, fully closed Cursor and OpenCode, then started them again.

After that, both:

$env:OD_DAEMON_URL
[Environment]::GetEnvironmentVariable('OD_DAEMON_URL', 'User')

returned nothing, and both Cursor and OpenCode are now working correctly with Open Design.

I really appreciate you taking the time to track this down Thanks again!

[lefarcen]

Hey @SKYIOUS — amazing, and thank you for sticking with the debugging all the way through.

That confirms the root cause here was a stale User-scoped OD_DAEMON_URL overriding the normal sidecar discovery path. Once that variable was cleared, both Cursor and OpenCode were able to discover the live daemon correctly again.

We'll keep the separate Windows packaged-install od/PATH issue tracked in #4852 / PR #4865, but this MCP-connectivity issue itself is now understood. Really appreciate the detailed repros, diagnostics, and follow-up checks — they made it possible to pin this down cleanly. ❤️