# Reported issues for superlocalmemory Pod holds 17 of 17 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [superlocalmemory](/mcp/superlocalmemory). ## Most discussed ### DAEMON_UNAVAILABLE: owned daemon is unavailable; retry later # CLI loses communication with owned daemon after several minutes while dashboard continues to work v3.8.10 ## Environment * **OS:** Windows 10 * **WSL:** WSL2 * **Distribution:** Ubuntu 24.04.4 LTS * **Mode:** A * **SuperLocalMemory:** Running entirely inside WSL2 * Hermes connects to the local MCP endpoint, and the dashboard is accessed from Windows via the browser. --- ## Issue After starting a fresh WSL session, SuperLocalMemory works perfectly. I can successfully run commands such as [Read the thread](https://github.com/qualixar/superlocalmemory/issues/104) · 2026-08-01 · closed · external user · 7 comments ### 3.8.9 write coordinator regression confirmed — blocks entire daemon, not a database lock issue After further overnight testing, we've isolated the root cause of the DAEMON_UNAVAILABLE and system-wide unresponsiveness in 3.8.9. It is not a recurrence of the old SQLite database is locked issue — that fix from 3.8.6 is working correctly. The problem is a regression in the new write coordinator itself. Symptoms in 3.8.9 (not present in 3.8.8 with identical config): 1. Write coordinator blocks the entire daemon. After a few successful writes, the coordinator stops responding. Even basic comm [Read the thread](https://github.com/qualixar/superlocalmemory/issues/97) · 2026-07-28 · closed · external user · 1 comment ### 3.8.4 / 3.8.5 regression summary — daemon hang, UI config broken, 3.8.3 is the last working version We've done extensive testing across the last three releases on an LXC containerized deployment (Mode B, OpenAI-compatible provider, SLM_DAEMON_HOST=0.0.0.0). Here's the summary: 3.8.3 — The last stable version for us. · Daemon starts and stays responsive. · Dashboard loads correctly and displays the actual config (Mode B, Qwen3-Embedding, etc.). · CLI slm remember / slm status work. · MCP tools via Hub work. · The only issue is the Dashboard Settings "Test Connection" / "Save" buttons returnin [Read the thread](https://github.com/qualixar/superlocalmemory/issues/91) · 2026-07-26 · closed · external user · 4 comments ### HTTP write endpoints broken in 3.8.2 — x-install-token rejected after working in 3.8.1 3.8.1 — Everything worked normally. We had SLM_API_KEY set in systemd and X-SLM-API-Key in MCP Hub headers. Dashboard Settings could save changes, and all MCP tools (including slm_http__remember, slm_http__mesh_summary) functioned correctly. 3.8.2 — After upgrading, we noticed the Dashboard Settings page started showing Failed: Authenticated write capability required on the "Operating Mode & LLM Provider" and "Embeddings & Retrieval" action buttons. What we tried 1. Removed SLM_REQUIRE_API_KE [Read the thread](https://github.com/qualixar/superlocalmemory/issues/90) · 2026-07-24 · closed · external user · 3 comments ### With api_key configured, every MCP remember fails: daemon_request doesn't send X-SLM-API-Key, daemon 401s its own write-through Once `/api_key` exists — which 3.7.2 makes mandatory for remote HTTP MCP — every MCP `remember` fails with ``` Canonical daemon is temporarily unavailable; retry the same remember operation without starting a second writer. ``` even though `/health` is `ready` and reads work fine. A valid `X-SLM-API-Key` from the MCP client doesn't help. Cause chain: 1. `mcp/tools_core.py` routes `remember` through the daemon's own REST endpoint via `daemon_request("POST", "/remember", …)`. 2. The [Read the thread](https://github.com/qualixar/superlocalmemory/issues/71) · 2026-07-17 · closed · external user · 1 comment ### Distributed deployment: mcp/server.py get_engine() deadlocks daemon with sqlite3.OperationalError Problem Description In a distributed/containerized deployment where a master daemon (unified_daemon.py) handles background tasks 24/7 while remote or separate client worker processes invoke MCP tools (e.g., list_recent), the client process frequently crashes with: sqlite3.OperationalError: database is locked This occurs because every cold MCP sub‑process aggressively re‑initializes the database, colliding with the write‑locks already held by the master daemon. Root Cause Analysis The flaw is [Read the thread](https://github.com/qualixar/superlocalmemory/issues/59) · 2026-06-20 · closed · external user · 2 comments ### SLM_REMOTE=1 does not allow HTTP MCP connections from LAN containers (421 Misdirected Request persists) Body: Hi Varun, First of all, thank you for the distributed deployment guide and the SLM_REMOTE=1 update — the Brain page now loads from my remote browser correctly. That part works perfectly. However, I'm unable to get HTTP MCP transport working between containers on the same LAN, even after following the guide exactly. I'm on v3.6.13. My setup: · SLM container: 192.168.50.144 (daemon + HTTP MCP) · Hub container: 192.168.50.143 (SLM Hub MCP client) Environment variables on the SLM contain [Read the thread](https://github.com/qualixar/superlocalmemory/issues/45) · 2026-06-15 · closed · external user · 2 comments ### superlocalmemory pi.dev integration This might be useful as enhanced documentation, for integrating superlocalmemory with pi.dev. It took me some time to understand how to install it with the terminal code tool. Tried to integrate this as model-context-protocol (mcp) with "pi.dev¨, the terminal code agent. after installing superlocalmemory, had to configure the mcp in the local home folder in an `mcp.json` file, located at `~/.pi/agent/mcp.json` ``` { "mcpServers": { "superlocalmemory": { "command": "slm", "ar [Read the thread](https://github.com/qualixar/superlocalmemory/issues/31) · 2026-06-06 · closed · outside contributor · 2 comments ## Most recent ### Follow-up to #102: report_feedback still not fully functional — MCP session killed after first call + Dashboard reads wrong table The fix for report_feedback writing to learning.db is partially effective, but two remaining issues prevent the learning system from functioning in practice. Issue A: MCP session manager kills session after first feedback call After a fresh daemon restart, the first report_feedback call succeeds and writes to learning_feedback correctly. However, every subsequent call returns "success": true but does NOT write to the database. This is 100% reproducible. Logs show the familiar Terminating sess [Read the thread](https://github.com/qualixar/superlocalmemory/issues/106) · 2026-08-02 · closed · external user · 1 comment ### Two Windows-only bugs in v3.6.22 (`slm doctor` false FAIL + `slm_optimize_stats` crash) ## Summary On Windows, two independent POSIX-only assumptions cause failures in an otherwise healthy install: 1. **`slm doctor` always reports `[FAIL] Embedding worker: [WinError 10038] An operation was attempted on something that is not a socket`** — even when the embedding worker is loaded and semantic search is fully operational. The check uses `select.select()` on a subprocess **pipe**, which is invalid on Windows. 2. **The optimize/cache stats path crashes with `module 'os' has no attribu [Read the thread](https://github.com/qualixar/superlocalmemory/issues/65) · 2026-07-10 · closed · external user · 1 comment ### Claude complains on the output of "slm hook start" Claude complains on the output of the hook "slm hook start" THe output contains a line with "MANDATORY" and Claude gets confused by that. Have asked Claude to update itself and it now adds to ignore that particular output this way: Image I have asked Claude to give me a good bug ticket description, here you go: **Summary**: slm hook start (registered as a SessionStar [Read the thread](https://github.com/qualixar/superlocalmemory/issues/64) · 2026-07-09 · closed · outside contributor · 1 comment ### Distributed deployment feedback + OpenClaw plugin suggestion Hi Varun, I've been running SLM v3.6.13 in a fully distributed LXC setup (SLM, MCP Hub, OpenClaw each in separate containers) for a few weeks now. Everything is finally stable — thank you for the rapid updates that made this possible. I wanted to share some detailed feedback from this experience, and a suggestion for the future. ### Minor Issues in Distributed Deployment These are all things I encountered while debugging. None of them block functionality, but they made the setup process much h [Read the thread](https://github.com/qualixar/superlocalmemory/issues/46) · 2026-06-15 · closed · external user · 1 comment ### v3.6.12: SLM_REMOTE=1 partially working — /internal/token still returns 403 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 injecte [Read the thread](https://github.com/qualixar/superlocalmemory/issues/41) · 2026-06-14 · closed · external user · 0 comments ### v3.6.10: Three Remaining Frontend/Auth Issues in Distributed LAN Deployments Hi Varun, First of all, sincere thanks for continuing to ship updates even over the weekend. The rapid release of v3.6.10 really shows your dedication to this project — much respect. After upgrading to v3.6.10, I re-tested the previous fixes in my distributed setup. While some progress has been made, three issues remain. Below are my findings: --- ## My Deployment Environment - **SLM Version**: v3.6.10, clean npm install on Debian 13 LXC - **Mode**: Mode B, using remote llama.cpp endpoints [Read the thread](https://github.com/qualixar/superlocalmemory/issues/39) · 2026-06-13 · closed · external user · 1 comment ### Request: Document all supported environment variables and config keys Hi, First, thank you for the rapid iteration on SLM — the improvements are impressive. I've been using SLM in a distributed LXC environment and have found it challenging to configure correctly because there is no central documentation of all supported environment variables and configuration keys. For example, when I needed to: Set the bind address to 0.0.0.0 for remote access Allow remote Host headers for HTTP MCP Configure the embedded MCP transport I had to discover SLM_HOST, SLM_MCP_EMB [Read the thread](https://github.com/qualixar/superlocalmemory/issues/37) · 2026-06-11 · closed · external user · 1 comment ### HTTP MCP: Host header restriction and port conflict with stdio in distributed LXC setup Hi, First, thank you for the incredible work on v3.6.7/v3.6.8 — the embedded HTTP MCP transport is a great step forward. I've been testing it in my distributed LXC environment and ran into two blocking issues that I wanted to report. My Environment I run SLM in a distributed setup across multiple LXC containers on Proxmox: SLM container (192.168.50.144): Runs the unified daemon (slm-http.service, a systemd service I created) MCP Hub container (192.168.50.143): Aggregates MCP servers (SLM, qm [Read the thread](https://github.com/qualixar/superlocalmemory/issues/36) · 2026-06-11 · closed · external user · 1 comment ### esh_summary causes daemon crash — heartbeat_active: false and immediate shutdown Hi, I’ve been debugging an issue where the Mesh Peers panel never shows any peers in my distributed setup (SLM, OpenClaw, MCP Hub each in separate LXC containers). After extensive testing, I believe I’ve isolated the problem: calling mesh_summary (via any transport) causes the daemon to crash immediately, preventing the peer from being displayed. This happens consistently, even after I fixed a service configuration conflict that was causing earlier instability. Evidence I called mesh_summary [Read the thread](https://github.com/qualixar/superlocalmemory/issues/34) · 2026-06-09 · closed · external user · 1 comment The remaining reports are on [the project's issue tracker](https://github.com/varun369/SuperLocalMemoryV2/issues).