v0.6.1 macOS arm64: --ui=true persists config but HTTP server never starts

[Nick-CHI]

Summary

--ui=true --port=9749 parses, persists to ~/.cache/codebase-memory-mcp/config.json, but the embedded HTTP graph UI never binds the port. No ui.serving log is ever emitted. UI is unreachable.

Environment

• Binary: codebase-memory-mcp 0.6.1 (CLI --version)
• serverInfo.version over MCP: 0.10.0 (mismatch with CLI version — possible release-tag drift)
• File: Mach-O 64-bit executable arm64, 240.8 MB
• Install path: /Users/nick/.local/bin/codebase-memory-mcp
• macOS 26.4.1 (Darwin 25.4.0 arm64), Apple Silicon
• update -y reports "Already up to date (0.6.1)"

Reproduction

codebase-memory-mcp config set ui_enabled true
codebase-memory-mcp config set ui_port 9749
cat ~/.cache/codebase-memory-mcp/config.json
# {"ui_enabled": true, "ui_port": 9749}

tail -f /dev/null | codebase-memory-mcp --ui=true --port=9749 2>err.log &
sleep 3
lsof -iTCP:9749 -sTCP:LISTEN   # empty
cat err.log
# level=info msg=mem.init budget_mb=18432 total_ram_mb=36864

No process listens on 9749 (or any other port). No child process forked. Only stderr line is mem.init.

What I tried

• --ui=true --port=9749 (flag form)
• --ui true --port 9749 (space-separated)
• --ui alone
• Persisted config + no flags
• TTY via script -q /dev/null …
• After full MCP handshake + tools/call list_projects (returns data correctly — 3 indexed projects, so DB layer is fine)
• CBM_DIAGNOSTICS=1 (only adds diagnostics.start log, no UI log)

Display bug (secondary)

config set ui_enabled true echoes ui_enabled = true and writes the JSON, but config list shows only auto_index / auto_index_limit. The ui_* keys are persisted but hidden from list.

Strings in binary suggesting UI is wired

ui_enabled
ui_port
ui.config.saved
ui.config.corrupt
ui.config.write_fail
ui.no_assets
ui.unavailable
ui.serving
ui.index.start
ui.index.fork
ui.index.done
ui.http.mcp_fail
/api/layout*
/api/index
/api/index-status
/api/project*
/api/browse*
/api/adr*
/api/project-health*
/api/processes
/api/logs*
/api/process-kill
/index.html
/assets/*
http://127.0.0.1:%d
axum / hyper

So the code path exists; it just never runs in the 0.6.1 release binary.

Hypothesis

UI startup branch is gated behind a check that fails silently in the published macOS arm64 build (missing embedded assets? feature flag not enabled at compile time? early return before bind?). The absence of ui.no_assets / ui.unavailable / ui.serving in stderr suggests UI init isn't even reached.

Ask

1. Confirm whether --ui is supposed to work in 0.6.1 macOS arm64 release, or if it's a main-only feature.
2. If shipped: add a stderr log at the UI init entrypoint (success or failure) so users can tell why it's silent.
3. Fix config list to display ui_enabled / ui_port.
4. Reconcile CLI --version (0.6.1) with MCP serverInfo.version (0.10.0).

[mosi-kha]

I also have this issue

[DeusData]

Thanks for the detailed report — and the version mismatch you spotted (--version → 0.6.1 vs serverInfo.version → 0.10.0) is the key clue.

Root cause. The embedded graph UI is only present in the UI build of the binary. At startup the server starts the HTTP UI only when the binary actually carries the embedded frontend assets (CBM_EMBEDDED_FILE_COUNT > 0). A standard (non-UI) binary accepts --ui=true, persists it to config.json, but then can't start the server — so you see the config change with no ui.serving log and no bound port. The one diagnostic that did fire (ui.no_assets) was routed to the log-file sink, not your terminal, so from your side it looked completely silent. Your 240 MB binary with the version drift was a standard build, not the UI build.

Fix (commit 6657044). When --ui=true is passed explicitly to a binary without the embedded UI, the server now prints a clear message to stderr:

codebase-memory-mcp: --ui requested, but this binary was built without the embedded UI, so the HTTP server will not start.
Use the UI release asset (codebase-memory-mcp-ui) or rebuild with: make -f Makefile.cbm cbm-with-ui

So instead of a silent no-op you now get told exactly why and what to use.

To actually get the UI: grab the codebase-memory-mcp-ui asset from the release (the project ships both a standard and a UI binary), or build with make -f Makefile.cbm cbm-with-ui. That binary serves the graph UI on --port.

Separately, the --version vs serverInfo.version drift you noticed is worth its own look — if you can reproduce a fresh install where update -y says "up to date" while serverInfo reports a different version, please open a focused issue with the install method (npm/pip/script) and I'll chase the release-tagging. Closing this one as addressed (clear feedback + UI-binary guidance). Thanks!