Skip to content

memtrace mcp --ui binds the dashboard on 0.0.0.0 and ignores MEMTRACE_UI_HOST #63

Description

@Regis-RCR

Summary

I observed memtrace mcp --ui (and MEMTRACE_MCP_UI=1 memtrace mcp) listening on all IPv4 interfaces even when I set MEMTRACE_UI_HOST=127.0.0.1. With the same variable, memtrace start --headless listened only on 127.0.0.1. Two commands serve the same dashboard/API and disagree on the default bind host, and mcp --ui does not honor the host variable at all.

Version

memtrace 0.8.63, macOS arm64.

Steps to reproduce

  1. With the engine already reachable, I ran MEMTRACE_UI_HOST=127.0.0.1 memtrace mcp --ui.
  2. In another terminal: lsof -nP -iTCP:3030 -sTCP:LISTEN.

Observed:

memtrace ... TCP *:3030 (LISTEN)
  1. I stopped it, ran MEMTRACE_UI_HOST=127.0.0.1 memtrace start --headless, and repeated the lsof.

Observed:

memtrace ... TCP 127.0.0.1:3030 (LISTEN)

Expected

I expect mcp --ui to honor MEMTRACE_UI_HOST, and to default to loopback like start unless a wildcard bind is explicitly requested.

Impact

On my machine, mcp --ui opens a wildcard IPv4 listener despite my explicit loopback setting. The environment reference describes this dashboard API as unauthenticated, so on a shared network (a LAN, a VPN or mesh interface, a container network) other hosts can reach it where the firewall allows, and read the graph, episodes, and search results. The split is easy to miss: same server, two commands, opposite defaults, and MEMTRACE_UI_HOST ignored on the mcp --ui side.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions