Feature Request: Native multi-tenancy support and built-in user authentication / access control

[ForeverAngry]

What problem does this solve?

Currently, the codebase-memory-mcp lacks native support for separating data across multiple tenants, as well as built-in user authentication and access control mechanisms, which blocks multi-user deployment environments.

Proposed solution

Add native multi-tenancy support so that multiple organizations/users can securely share the same instance, along with built-in user authentication and role-based access control (RBAC).

Alternatives considered

No response

Confirmations

• I searched existing issues and this is not a duplicate.

[DeusData]

Thanks for filing this, and for stating the blocker plainly — multi-user deployment really is not possible today, and you are right about that.

Grounding where the project actually stands, so the size of the request is visible:

There is no server-side identity concept anywhere in the codebase. Indexes are per-project SQLite databases under a per-user cache directory (~/.cache/codebase-memory-mcp/<project>.db), and the built-in UI binds to IPv4 loopback only — hardcoded at src/ui/httpd.c:248 (htonl(0x7F000001)), with the invariant restated in src/ui/httpd.h:12 as "Binds 127.0.0.1 only (IPv4 loopback). Never any other interface." Request validation compares Origin/Host against that literal loopback expectation (src/ui/http_server.c:78, :91, :1636).

In other words, the current security model is: the operating-system user account is the tenant, and loopback is the authentication boundary. There is no auth layer to extend because the process assumes exactly one trusted local user.

So native multi-tenancy plus RBAC is not an increment on that model — it would mean introducing a server deployment mode, an identity and session system, per-tenant data isolation across the graph store, and an authorization check on every MCP tool and query path, for a tool whose distribution model is a single static C binary that a developer runs beside their editor. That is a change of product category rather than a feature, which makes it a direction question for the maintainer rather than something triage should accept or decline. I am recording it as such rather than giving you a yes or a no I am not entitled to give.

Two things that may help in the meantime, depending on which half of the problem is more pressing for you:

If your actual need is isolation, that already exists at the OS-user level: separate accounts get separate cache directories and separate loopback-scoped UIs, with no shared state between them. If your need is shared access to one instance, note that #1210 requests a configurable bind address for a related deployment reason, and it runs into the same missing-auth-layer problem from the other side — the two requests are really the same gap approached from different ends, so it is worth following that thread too.

One thing that would genuinely help whoever picks this up: could you say more about your deployment shape? Specifically whether the tenants are separate humans on one server, separate organizations, or CI/agent identities — and whether they need to share a single index or each need their own. "Multi-tenancy" covers designs with very different costs here, and the answer materially changes which parts are hard.

Thanks for raising it — the fact that the request is coherent is precisely why it needs a deliberate decision rather than a quick reply.