[Windows] --ui=true starts but HTTP server never listens on v0.8.1

[MrXuanZF]

Version

codebase-memory-mcp-ui-windows-amd64

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

Bug Description

When running codebase-memory-mcp.exe --ui=true --port=9749 on Windows (v0.8.1 UI build), the process starts but the HTTP server never actually listens on the specified port. No error output is shown.

Environment

• OS: Windows 10/11
• Version: v0.8.1
• Build: codebase-memory-mcp-ui-windows-amd64.zip (35.6MB, SHA/checksum verified)

Steps to Reproduce

1. Download codebase-memory-mcp-ui-windows-amd64.zip from v0.8.1 release
2. Extract codebase-memory-mcp.exe (258MB, confirmed UI build with src/ui/httpd.c in THIRD_PARTY_NOTICES.md)
3. Run: codebase-memory-mcp.exe --ui=true --port=9749
4. Run: curl -sI http://localhost:9749 or netstat -an | findstr 9749

Expected Behavior

• HTTP server starts and listens on port 9749
• http://localhost:9749 is accessible in browser
• 3D visualization UI is displayed

Actual Behavior

• Process starts with no error output
• Port 9749 is never listened (confirmed via netstat)
• curl / browser connection fails immediately
• No log output even when redirecting stderr/stdout to file

Additional Info

• Tried multiple ports (9749, 9750) — same result
• Ran codebase-memory-mcp.exe install -y first — same result
• Windows Defender / firewall disabled for testing — same result
• The MCP stdio mode works correctly (index_repository, get_architecture etc. all work fine)

Possible Cause

The HTTP server goroutine in the UI build may not be starting correctly on Windows, or the --ui flag is not being recognized properly in the Windows binary.

Reproduction

Bug Description

When running codebase-memory-mcp.exe --ui=true --port=9749 on Windows (v0.8.1 UI build), the process starts but the HTTP server never actually listens on the specified port. No error output is shown.

Environment

• OS: Windows 10/11
• Version: v0.8.1
• Build: codebase-memory-mcp-ui-windows-amd64.zip (35.6MB, SHA/checksum verified)

Steps to Reproduce

1. Download codebase-memory-mcp-ui-windows-amd64.zip from v0.8.1 release
2. Extract codebase-memory-mcp.exe (258MB, confirmed UI build with src/ui/httpd.c in THIRD_PARTY_NOTICES.md)
3. Run: codebase-memory-mcp.exe --ui=true --port=9749
4. Run: curl -sI http://localhost:9749 or netstat -an | findstr 9749

Expected Behavior

• HTTP server starts and listens on port 9749
• http://localhost:9749 is accessible in browser
• 3D visualization UI is displayed

Actual Behavior

• Process starts with no error output
• Port 9749 is never listened (confirmed via netstat)
• curl / browser connection fails immediately
• No log output even when redirecting stderr/stdout to file

Additional Info

• Tried multiple ports (9749, 9750) — same result
• Ran codebase-memory-mcp.exe install -y first — same result
• Windows Defender / firewall disabled for testing — same result
• The MCP stdio mode works correctly (index_repository, get_architecture etc. all work fine)

Possible Cause

The HTTP server goroutine in the UI build may not be starting correctly on Windows, or the --ui flag is not being recognized properly in the Windows binary.

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Thanks for the clean Windows UI repro. I’ve triaged this under the Windows and UI/server trackers.

Silent success with no listening port is the bug here: --ui=true --port=9749 should either bind and serve the UI, or fail loudly with a useful error. The regression guard should run the Windows UI binary, assert the listener exists on the requested port, and verify startup logs make failures diagnosable.

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

[DeusData]

v0.9.0 includes Windows UI hang/runtime reliability fixes, so this --ui startup path may be resolved. Could you retest on v0.9.0 and confirm whether the HTTP server now listens locally? Marking awaiting-reporter.

[MrXuanZF]

v0.9.0 fixed it ✅

Tested on Windows 11:

• codebase-memory-mcp.exe --ui=true --port=9749 now starts the HTTP server successfully
• Log shows ui.serving url=http://127.0.0.1:9749
• Browser opens the 3D code graph correctly
• Indexed my project through the UI's own /api/index endpoint and it renders the full graph

Thank you for the quick fix and the high-priority triage! 🎉

[DeusData]

Thanks for the thorough retest and confirmation — UI server startup on Windows plus the end-to-end index-and-render check is exactly the verification we hoped for. Closing as fixed in v0.9.0. Much appreciated!