Three Dashboard UI Issues — Root Causes, Verified Fixes, and Suggested Official Solutions (v3.6.11)

[unfall103-debug]

Hi Varun,

I spent some time tracing the root causes of the three Dashboard issues I reported earlier. All three appear to be frontend / API data-mapping issues rather than backend engine problems. Below are my findings, including the exact code changes that resolved them in my environment.

IMPORTANT NOTE: I've only tested the Dashboard UI behavior. I have not tested whether these fixes affect deeper backend functionality, nor have I checked for other code paths that might have similar issues. Please review carefully.

MY ENVIRONMENT:

• SLM v3.6.11, npm install on Debian 13 LXC
• Mode B, remote llama.cpp endpoints (no API key required)
• Dashboard accessed from Windows on the same LAN (192.168.50.x)
• SLM_DAEMON_HOST=0.0.0.0, SLM_MCP_ALLOWED_HOSTS=*

==============================
ISSUE 1 (CRITICAL): BRAIN PAGE FAILS TO LOAD FROM REMOTE BROWSER

ROOT CAUSE:
The /internal/token endpoint is hardcoded to only accept requests from 127.0.0.1.

FILE: src/superlocalmemory/server/routes/token.py

Line 61:
if not is_loopback(client_host):
return JSONResponse({"error": "loopback only"}, status_code=403)

Line 66:
if not _origin_is_loopback(origin):
return JSONResponse({"error": "origin not allowed"}, status_code=403)

VERIFIED FIX (Temporary, for reference only):
Modifying these two checks to also accept my LAN subnet (192.168.50.*) immediately resolved the issue.

Line 61 after modification:
if not is_loopback(client_host) and not client_host.startswith("192.168.50."):
return JSONResponse({"error": "loopback only"}, status_code=403)

Line 66 after modification:
if not _origin_is_loopback(origin) and not origin.startswith("http://192.168.50."):
return JSONResponse({"error": "origin not allowed"}, status_code=403)

After this change, the Brain page loaded correctly from a remote browser, confirming this is the exact root cause.

SUGGESTED OFFICIAL FIX:
Allow /internal/token to also respect SLM_MCP_ALLOWED_HOSTS, so trusted LAN IPs can fetch the install token. Alternatively, a global SLM_REMOTE=1 switch could open all loopback-restricted endpoints at once.

==============================
ISSUE 2 (MEDIUM): LLM SETTINGS PANEL SHOWS WRONG ENDPOINT / TEST CONNECTION FAILS

ROOT CAUSE:
A field name mismatch between the config file and the Dashboard frontend.

In config.json, the custom endpoint is stored under "base_url", but the Dashboard frontend reads it from an "endpoint" field. Additionally, the /api/v3/config API returns an empty llm object ({}), so the backend is not exposing the custom endpoint at all. This causes the Dashboard to always fall back to https://api.openai.com/v1, and the connection test fails with 401 when no API key is provided.

HOW I VERIFIED:

1. Confirmed config.json correctly stores the custom endpoint under "base_url".
2. Called /api/v3/config — the returned llm object is empty ({}).
3. The Dashboard displays the default OpenAI URL instead of the user's configured endpoint.

SUGGESTED OFFICIAL FIX:
Either change the Dashboard frontend to read "base_url" instead of "endpoint", or change the backend API to expose the custom endpoint under the "endpoint" field.

==============================
ISSUE 3 (MEDIUM): DASHBOARD RATE LIMITING (429 TOO MANY REQUESTS)

ROOT CAUSE:
SLM's built-in HTTP rate limiter triggers after repeated failed authentication attempts during debugging. The rate limit is not currently configurable via environment variables.

HOW I VERIFIED:
After multiple failed attempts to load the Brain page (before fixing Issue 1), the browser received "429 Too Many Requests" with "retry-after: 60".

SUGGESTED OFFICIAL FIX:
Expose the rate limit window and thresholds as environment variables (e.g., SLM_RATE_LIMIT_WINDOW, SLM_RATE_LIMIT_READ, SLM_RATE_LIMIT_WRITE) so users can adjust them for their environments.

==============================
SUMMARY

Issue 1 | Backend (token.py) | Hardcoded loopback check on /internal/token
Issue 2 | Frontend + Backend API | Field name mismatch (base_url vs endpoint)
Issue 3 | Backend (rate limiter) | No environment variable to adjust thresholds

All three are UI/API-level issues. I have not tested whether deeper backend functionality is affected. Please review the suggested fixes carefully. The code changes I provided for Issue 1 resolved the issue in my environment, but I am not a professional developer and cannot guarantee they are the best long-term solution.

Thanks again for your continued work on SLM.

Best regards,
sinking

[varun369]

Hi @unfall103-debug — thank you for the exceptional root-cause work. Your tracing of each issue (and the verified fixes you proposed) was spot-on and made this fast to resolve.

All three are fixed in v3.6.12 — now live on PyPI, npm, and GitHub:

pip install -U superlocalmemory   # or: npm i -g superlocalmemory
slm restart

What we did (mapped to your findings)

• Issue 1 — Brain page from a remote browser. Implemented exactly your suggested option: /internal/token now serves the install token to trusted LAN clients, gated by SLM_MCP_ALLOWED_HOSTS, via a single SLM_REMOTE=1 switch (default off). The dashboard CSRF origin guard was relaxed for allowlisted origins too.
• Issue 2 — custom endpoint / base_url vs endpoint mismatch. The Settings UI now reads, displays, sends, and saves the custom endpoint, and the backend persists api_base for any provider (the mode switch now actually persists). A keyless local OpenAI-compatible endpoint (llama.cpp / LM Studio) is probed without an Authorization header, so no more spurious 401.
• Issue 3 — rate limit (429). Now tunable via SLM_RATE_LIMIT_WRITE / SLM_RATE_LIMIT_READ / SLM_RATE_LIMIT_WINDOW, and in SLM_REMOTE mode your allowlisted LAN dashboard is exempt (it polls like the local one).

Remote-dashboard setup (the important part)

The Brain tab — and the other data-heavy panes — are gated by the install token (a per-install secret at ~/.superlocalmemory/.install_token). The browser dashboard auto-fetches it from /internal/token and sends it as X-Install-Token. On localhost that always works; for a remote browser you must (a) enable remote mode and (b) allowlist your browser's IP — otherwise /internal/token returns 403 loopback only and the pane shows "Couldn't load Brain":

export SLM_DAEMON_HOST=0.0.0.0                 # bind on the LAN
export SLM_MCP_ALLOWED_HOSTS=192.168.50.0/24   # your browser's IP or subnet (exact IP, CIDR, prefix*, or *)
export SLM_REMOTE=1                            # LAN mode: token to allowlisted clients + stateless MCP + origin + rate-limit
slm restart

After this the Brain tab (and Mesh/Optimize/all panes) load from the remote browser. If a tab is still blank, it's almost always that your browser's IP isn't matched by SLM_MCP_ALLOWED_HOSTS — the token fetch is what unlocks those panes. Full guide: docs/distributed-deployment.md.

One more thing

You clearly know this codebase well — if you spot something in future, please feel free to open a PR. Given how precise your diagnoses have been, we'll fast-track the review and merge. Thanks again for making SLM better for distributed users. 🙏

[unfall103-debug]

Hi Varun,

Thanks for the quick turnaround on v3.6.12. I've upgraded and set SLM_REMOTE=1, but the /internal/token endpoint still returns 403 from remote browsers on my LAN. Here's my verification:

Environment:

SLM v3.6.12, npm install

SLM_REMOTE=1 confirmed injected into the daemon process

SLM_DAEMON_HOST=0.0.0.0

SLM_MCP_ALLOWED_HOSTS=192.168.50.144:,192.168.50.143:,192.168.50.142:*

Dashboard accessed from Windows on 192.168.50.x

Verified:

1 Environment variables are injected:
SLM_DAEMON_HOST=0.0.0.0
SLM_MCP_ALLOWED_HOSTS=192.168.50.144:,192.168.50.143:,192.168.50.142:*
SLM_REMOTE=1

2 token.py is the new v3.6.12 version (confirmed via grep):
Line 73: if not is_loopback(client_host) and not is_lan_client_allowed(client_host):
Line 78: if not _origin_is_loopback(origin) and not is_remote_origin_allowed(origin):
No old manual modifications present.

3 Browser still receives 403:
GET /internal/token → 403 Forbidden
GET /api/v3/brain → 401 Unauthorized

4 LLM Test Connection also fails:
Returns "Internal/private endpoints are not allowed from a remote client"

Possible Causes:
It seems the new is_lan_client_allowed and is_remote_origin_allowed functions may not be correctly reading from SLM_MCP_ALLOWED_HOSTS, or the SLM_REMOTE=1 flag is not being respected in all the necessary code paths.

Happy to provide any additional logs or run further tests.

Best regards,
sinking

[unfall103-debug]

Hi Varun,

I wanted to follow up after the latest round of releases. v3.6.13 is running great — the Brain page loads normally from remote LAN browsers now, and the overall stability is much improved from where we were a few days ago.

There's one small remaining issue: the LLM Test Connection button in Settings still returns "Internal/private endpoints are not allowed from a remote client", even though the endpoint field now correctly shows my custom URL (http://192.168.50.140:8043/v1). This seems like a separate check on the test-probe path that isn't covered by SLM_REMOTE=1 yet. Not urgent at all — the actual LLM works perfectly through slm recall and MCP tools.

I also want to say a sincere thank you. Watching you ship v3.6.10, v3.6.11, v3.6.12, and v3.6.13 back to back over the weekend, with each release addressing the specific issues I reported, was genuinely impressive. Your dedication to this project is remarkable, especially over a weekend.

The fixes you made have turned SLM from something I had to constantly debug into something that just works. Thank you.

Best regards,
sinking