Reported issues for memtomem
Pod holds 24 of 44 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.
Back to memtomem.
Most discussed
server: legacy flock UX follow-up — liveness probe, clearer stderr, orphan lifecycle (follow-up to #437)
Follow-up to #437 (PR #439 closed that). PR #439 fixed the stale-file axis — when the server exits cleanly, ~/.memtomem/.server.pid is now unlinked on both atexit and SIGTERM, so a later probe won't race on a leftover file.
But a second axis of the same user symptom remains: live orphan holder. Observed today immediately after the fix landed:
Memtomem MCP Server
Status: ✘ failed
Command: memtomem-server
Config location: /Users/pdstudio/.claude.json
```…
[Read the thread](https://github.com/memtomem/memtomem/issues/440) · 2026-04-23 · closed · 3 comments
### wizard: `_detect_project_install` doesn't verify `memtomem` is in project dependencies
## Summary
`mm init` classifies any cwd with a `pyproject.toml` (and no `packages/` dir) as a **project install** and writes an `.mcp.json` assuming `memtomem` is already a dependency of that project — but the wizard never checks `pyproject.toml` to verify that, nor does it run `uv add memtomem` itself. Result: on an empty `uv init`-style project, the wizard happily writes a workspace-style `.mcp.json` that only works because the user also has a global `uv tool install memtomem` providing the…
[Read the thread](https://github.com/memtomem/memtomem/issues/436) · 2026-04-23 · closed · 2 comments
### cli: .mcp.json / Kimi mcp.json writes are non-atomic and parse the existing file unguarded
## Summary
`mm init`'s editor-config writers (`.mcp.json`, Kimi `mcp.json`) still use truncate-then-write (`Path.write_text`) instead of the atomic tempfile+`os.replace` helper that `config.json` writes were migrated to, and they `json.loads` the pre-existing file with no error handling. Two failure modes, both at the *last* step of `mm init` — after `~/.memtomem/config.json` has already been written — so a failure leaves the run half-applied.
## Where
-…
[Read the thread](https://github.com/memtomem/memtomem/issues/1568) · 2026-07-03 · closed · 1 comment
### security: clarify path policy for MCP mem_export / mem_import
## Decision needed
What path policy to apply to the MCP `mem_export` / `mem_import` tools, which
currently accept fully arbitrary resolved paths.
## Current state (verified against source)
- `mem_export(output_file=...)` writes the bundle to any resolved path —
`server/tools/export_import.py:49` (`Path(output_file).expanduser().resolve()`,
no allow-list).
- `mem_import(input_file=...)` reads any existing path —
`server/tools/export_import.py:101` (existence-checked only).
This is…
[Read the thread](https://github.com/memtomem/memtomem/issues/1486) · 2026-06-30 · closed · 1 comment
### security: decide network MCP transport (sse/http) auth stance
## Decision needed
Whether network MCP transports (`memtomem-server --transport sse|http`) should
gain an optional first-party auth token, or remain documented as
trusted-network-only behind an authenticated reverse proxy.
## Current state (verified against source)
There is no first-party bearer / API-key authentication for sse/http transports.
The MCP SDK middleware validates only Content-Type / Host / Origin. Existing
protections:
- Default transport is `stdio`; default host is…
[Read the thread](https://github.com/memtomem/memtomem/issues/1485) · 2026-06-30 · closed · 1 comment
### feat(web): Compose privacy warning — secret pattern confirm + client pattern sync
## Why
PR #575 follow-up review surfaced a gap: the secret patterns in `packages/memtomem/src/memtomem/privacy.py` are checked **only on the MCP path** (`server/tools/memory_crud.py: mem_add()`); the **Web UI's three modes all pass raw**. The CLAUDE.md invariant "STM-bypass must not be safety-bypass" defines an LTM trust boundary, but here the boundary is bypassed under an unspoken "Web UI = local user" assumption. When that assumption breaks (remote `mm web`, shared workstation, secret…
[Read the thread](https://github.com/memtomem/memtomem/issues/580) · 2026-04-30 · closed · 1 comment
### server: failed-handshake leaves legacy `.server.pid` flock locked; reconnects loop
## Summary
When a `memtomem-server` child process started by an MCP client (Claude Code) fails its stdio handshake but the process **stays alive**, it continues to hold the legacy `~/.memtomem/.server.pid` flock. Every subsequent reconnect attempt from the client spawns a fresh child that aborts immediately with:
error: another memtomem-server holds a lock at /Users/.../.memtomem/.server.pid (likely a pre-0.1.25 install). Stop it before starting a new server; mm uninstall will also…
Read the thread · 2026-04-23 · closed · 1 comment
memtomem-server leaves stale .server.pid on exit — risks mm uninstall liveness false-positive via PID recycling
Problem
memtomem-server writes ~/.memtomem/.server.pid on startup but does not unlink it on exit. After any non-clean termination (SIGKILL, parent-process death, system restart, crash) — and possibly after clean SIGTERM too — the file lingers on disk pointing at a PID that is no longer the server.
This is the mirror image of #384 (liveness check only sees MCP server pid):
- #384 → real writer present but no pid file → liveness check false-negative → uninstall proceeds, risks…
Read the thread · 2026-04-22 · closed · 1 comment
Most recent
embedding: huggingface-hub tags E5 downloads with the host agent and writes outside the fastembed cache — opt out by default?
Summary
The ONNX E5 profile downloads its model through huggingface_hub (embedding/profiles.py: hf_hub_download and snapshot_download of a pinned revision, then a sha256 check). With huggingface-hub 1.32.0 (bumped in #2518), those calls do two things memtomem does not control:
- User-Agent agent tag. When the process runs inside an AI coding agent (detected from environment variables), the User-Agent builder in
utils/_headers.pyappendsagent/<id>to every Hub request,…
Read the thread · 2026-09-25 · closed · 0 comments
GET /api/bootstrap does not list read_only_memory_dirs
What happens
GET /api/bootstrap reports the configured index roots as memory_dirs and
project_memory_dirs, but not indexing.read_only_memory_dirs (#2500). A
configured read-only root is loaded, watched and indexed, yet this snapshot of
"which sources are configured" leaves it out.
packages/memtomem/src/memtomem/web/routes/system.py, get_bootstrap_state
(around l.335-373 on main): it builds memory_dirs and project_memory_dirs
from config.indexing and returns them, with…
Read the thread · 2026-09-23 · closed · 0 comments
mm status does not list read_only_memory_dirs
What happens
mm status does not show indexing.read_only_memory_dirs anywhere. Its "Runtime context" block lists "User sources" (memory_dirs) and "Project sources" (project_memory_dirs) only, so a configured read-only root is invisible even though it is loaded and indexed.
Repro (isolated HOME, BM25-only preset):
# ~/.memtomem/config.json
# "indexing": {"memory_dirs": ["~/memories"], "read_only_memory_dirs": ["/path/to/vault"]}
mm status
Runtime context…
[Read the thread](https://github.com/memtomem/memtomem/issues/2519) · 2026-09-22 · closed · 0 comments
### MCP candidate approval leaves transition history when the write is refused
## Problem
MCP `mem_candidate_review(decision="approve")` claims the candidate before it knows whether the write can land. For a daily destination, `server/tools/formation.py` calls `claim_memory_candidate`, then `_mem_add_core`. If the core refuses without writing — an excluded day file (#2488), a namespace mix, the redaction guard — it returns `(message, None)` and the tool calls `release_memory_candidate`.
The candidate ends up `pending` again, but claim and release each record a row in…
[Read the thread](https://github.com/memtomem/memtomem/issues/2491) · 2026-09-16 · open · 0 comments
### Destination refusals on MCP and web print raw, unquoted paths the CLI now sanitizes
## Summary
The paused-destination and missing-store refusals that #2485 consolidated and
sanitized in the CLI still exist as hand-written copies on the MCP wire and in
two web routes. Those copies interpolate the destination path raw, and the
missing-store copies put it unquoted into a `cd` hint.
Found while landing #2485 (#2477/#2478) and left out of it to keep that PR on
the CLI and the settings producers.
## Where (at `main` de161601)
**MCP — `server/tools/context.py`**
-…
[Read the thread](https://github.com/memtomem/memtomem/issues/2489) · 2026-09-16 · open · 0 comments
### OpenCode plugin still launches base-only memtomem, so existing ONNX/E5 configs miss the #2449 fix
## What happens
#2449 (PR #2450) made the Claude and Codex plugins launch `memtomem[onnx]==<core>`, so an existing ONNX/E5 configuration no longer fails the first `mem_status` with `ModuleNotFoundError: huggingface_hub`. The OpenCode plugin was not changed and still launches the base package:
```ts
// packages/opencode-memtomem/src/server.ts — configure()
command: ["uvx", "--from", `memtomem==${CORE_VERSION}`, "memtomem-server"],
The Claude/Codex launches come from the contract…
Read the thread · 2026-09-14 · closed · 0 comments
fix: bundled plugin cannot report status with existing ONNX/E5 configuration
Installing the Claude Code plugin succeeds, including MCP tool discovery, but the first mem_status call fails for an existing ONNX/E5 configuration:
Error: internal error (ModuleNotFoundError: No module named 'huggingface_hub')
Reproduced with plugin 0.5.2 / Core 0.6.1 and embedding.provider=onnx, embedding.model=multilingual-e5-small (FP32).
The installed plugin runs uvx --from memtomem==0.6.1 memtomem-server, without extras. Its isolated environment lacks…
Read the thread · 2026-09-13 · closed · 0 comments
search: expose RRF configuration in runtime_profile and status for client diagnostics
STM issue https://github.com/memtomem/memtomem-stm/issues/1012 needs a read-only diagnostic for the RRF agreement boundary. The current 0.017 default assumes k=60, unit weights, and two lists of at most 50 candidates. Equal weights [0.5, 0.5] halve every fused score, so the default exceeds even the two-leg maximum.
Expose rrf_k, rrf_weights (BM25, dense order), bm25_candidates, and dense_candidates as additive fields of mem_do(action="version").runtime_profile.search, retaining…
Read the thread · 2026-09-08 · closed · 0 comments
mm agent search / mem_agent_search: --no-include-shared is disregarded when no agent resolves, and shared rows still come back
What happens
--no-include-shared (CLI) / include_shared=False (MCP) is disregarded when no
agent resolves, and the query can still return rows from the shared namespace —
the one thing the caller asked to exclude.
$ mm agent search "deploy" --no-include-shared # no session, no --agent-id
(no agent resolved — searching unpinned, not just this agent's scope. …)
(--no-include-shared was disregarded: with no agent there is no merge to drop a
leg from, and an unpinned search still…
[Read the thread](https://github.com/memtomem/memtomem/issues/2296) · 2026-09-03 · closed · 0 comments
### The MCP server never calls FileWatcher.reconfigure, so watched roots are frozen for the process lifetime
`FileWatcher.reconfigure` exists and works, but nothing under `server/` ever calls it.
The MCP lifespan constructs the watcher once in `AppContext.ensure_initialized` (`server/context.py`) and its watched roots are then frozen for the process lifetime. Every caller of `reconfigure` lives in the web app:
web/hot_reload.py:279 web/routes/system.py:872 web/routes/system.py:1049
So if a user adds a `memory_dir` — via `mm config set`, an editor, or the web UI — while the MCP server is…
[Read the thread](https://github.com/memtomem/memtomem/issues/2186) · 2026-08-25 · closed · 0 comments
### MCP and Web PATCH can persist a cross-field-invalid config section
## Summary
`mm config set` re-checks a section's cross-field invariants before writing
(#2111), but the other two mutation surfaces do not. Both still take the bare
`setattr` path, so a combination the section's `@model_validator(mode="after")`
rejects can be persisted and then silently dropped by every subsequent load.
* MCP: `_set_config_key` (`server/helpers.py`) → `mem_config(persist=True)`
* Web: `PATCH /api/config` (`web/routes/system.py`)
`ConfigModel` sub-configs do not set…
[Read the thread](https://github.com/memtomem/memtomem/issues/2110) · 2026-08-19 · closed · 0 comments
### mem_agent_search records its searches as origin="internal" and omits query_run_id
## What
`mem_agent_search` does not pass `origin` to the search pipeline, so its
searches are persisted as `origin="internal"` — the label meaning "not a user
request". Every other user-facing surface labels itself (`mem_search` sends
`"mcp"`, the CLI sends `"cli"`, web sends `"web"`).
Two consequences:
1. **Origin analytics are wrong.** Agent searches are counted as internal
machinery rather than as MCP traffic, so any per-surface query volume or
latency breakdown understates MCP and…
[Read the thread](https://github.com/memtomem/memtomem/issues/2086) · 2026-08-18 · closed · 0 comments
### mem_agent_search discards every hint in compact/verbose output, permanently consuming the one-shot dimension notice
## What
`mem_agent_search` builds a `hints` list and then discards it on every
non-structured path. Only `output_format="structured"` ever surfaces hints;
`compact` (the default) and `verbose` return the formatter output alone:
`packages/memtomem/src/memtomem/server/tools/multi_agent.py` (current `main`):
```python
dim_notice = await _announce_dim_mismatch_once(app)
if dim_notice:
hints.append(dim_notice)
if not results:
if output_format == "structured":…
[Read the thread](https://github.com/memtomem/memtomem/issues/2085) · 2026-08-18 · closed · 0 comments
### MCP malformed-matcher warning interpolates the hook event name unredacted
# MCP malformed-matcher warning interpolates the hook event name unredacted
Deferred finding from the #2028 review (Codex, Major). Recorded rather than
fixed — see "Why this was declined" — so the trigger condition is written down
somewhere other than a PR thread.
## What
`format_malformed_warning` embeds the raw hook event name:
`packages/memtomem/src/memtomem/context/settings_doctor.py:235`
```python
f"{location} ({finding.path}), event '{finding.event}' rule "
The MCP settings…
Read the thread · 2026-08-05 · closed · 0 comments
retryable_errors reaches only 2 of its 7 consumers (MCP, CLI, reindex, auto-index, LangGraph drop it)
Split out of the review gate on #2020 (issue #2018). Not a regression —
IndexingStats.retryable_errors is new in #2020, so every surface named below
is "not reading a field that did not exist yesterday". Filing it because the
field only reaches two of its seven consumers, and the ones it misses are the
ones a human or agent actually reads.
What happens
#2020 added IndexingStats.retryable_errors: the subset of errors whose
cause was a typed RetryableError, recovered at the two…
Read the thread · 2026-08-03 · closed · 0 comments
MCP tag_rename/tag_delete/tag_merge default to applying; the CLI equivalents default to dry-run
The same destructive tag operation defaults to preview on the CLI and to apply over MCP.
CLI — dry-run by default. mm tags rename ops operations prints what
would change and ends with "Run with --apply to perform the rename." Passing
--yes without --apply is rejected outright (--yes requires --apply),
so there are two deliberate steps between a user and a bulk rewrite.
MCP — applies immediately. From mem_do(action="help", params={"category": "tags"}):
tag_rename: ……
[Read the thread](https://github.com/memtomem/memtomem/issues/1992) · 2026-08-02 · closed · 0 comments
The remaining reports are on [the project's issue tracker](https://github.com/memtomem/memtomem/issues).