Allow UI to be exposed on a configurable host (0.0.0.0) for remote/VPS deployments

[arpayidcloud-byte]

What problem does this solve?

Feature Request

Problem

The built-in UI currently appears to be accessible only through localhost.

This works well on a local machine, but it becomes difficult to use when running codebase-memory-mcp on a remote server such as AWS EC2, DigitalOcean, Hetzner, OVH, or other VPS providers.

Even after opening the firewall/security group and allowing port 9749, the UI is not reachable via the server's public IP because the HTTP server seems to bind only to 127.0.0.1.

Proposed Solution

Please add a configurable host option, for example:

codebase-memory-mcp --ui=true --host=0.0.0.0 --port=9749

### Proposed solution

Add a configurable host option for the built-in UI.

For example:

- CLI option:
  codebase-memory-mcp --host=0.0.0.0 --port=9749

- Or environment variable:
  CBM_HOST=0.0.0.0

The default value should remain 127.0.0.1 for security, but users running the application on remote servers (AWS EC2, DigitalOcean, Hetzner, OVH, etc.) should be able to explicitly bind the UI to 0.0.0.0 to allow access via the server's public IP.

### Alternatives considered

I considered using SSH port forwarding or a reverse proxy (such as Nginx), but these approaches do not solve the underlying limitation if the UI is only bound to 127.0.0.1. A configurable bind address would provide a simpler and more flexible solution for self-hosted deployments.

### Confirmations

- [x] I searched existing issues and this is not a duplicate.

[DeusData]

Thanks for the request, and for pre-empting the obvious objection by proposing 127.0.0.1 stay the default — that framing is right, and it is why this deserves a real answer rather than a reflexive no.

Your diagnosis of the current behaviour is correct. The bind is hardcoded at src/ui/httpd.c:248:

addr.sin_addr.s_addr = htonl(0x7F000001); /* 127.0.0.1 */

What I want to flag is that this is not an oversight that a flag can simply un-hardcode. It is an invariant the code states explicitly in three separate places:

• src/ui/httpd.h:12 — "Binds 127.0.0.1 only (IPv4 loopback). Never any other interface."
• src/ui/http_server.h:4 — "Binds to 127.0.0.1:<port> only (localhost)."
• src/ui/http_server.c:13 — same invariant restated at the server entry point.

And the loopback assumption is load-bearing beyond the bind() call. The request-validation path compares incoming Origin/Host against a literal loopback expectation — snprintf(expected, sizeof(expected), "http://127.0.0.1:%d", port) at http_server.c:78 and :91, and again at :1636. That check is what currently stands in for DNS-rebinding protection. Binding to 0.0.0.0 without reworking it would either reject every legitimate remote request or, if the check were loosened to compensate, remove the protection outright.

So the honest scope is not "add a --host flag". It is: choose an authentication and origin-validation model for a UI that would then be reachable from untrusted networks, on a server whose whole purpose is exposing a queryable index of your source code. Note that today there is no auth layer at all — loopback is the auth boundary.

That is a security-posture decision about the project's public surface, and it is not mine to make in triage, so I am not going to accept or decline it here. I have recorded it as a well-argued request with the constraints above, and I have kept your security label because the decision is genuinely one.

Two things that may be useful meanwhile: your SSH-port-forward alternative does in fact work today precisely because the bind is loopback — ssh -L 9749:127.0.0.1:9749 user@host terminates on the server's own loopback interface and satisfies the origin check. An nginx reverse proxy needs proxy_set_header Host 127.0.0.1:9749 to pass the same check. Neither is as convenient as a flag, but neither is blocked by the current design.

Related: discussion #1074 asks the same underlying question about localhost reachability, so I am linking them.

Thanks for writing this up with the deployment context and the default-stays-safe proposal intact — it made the actual trade-off easy to locate.