# Reported issues for Memorix

Pod holds 18 of 23 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 [Memorix](/mcp/memorix).

## Most discussed

### MCP spec conformance: 10 requirement(s) violated (via @hasmcp/mcp-spec-test) — spec 2026-07-28

Running `npx -y memorix serve` against the `@hasmcp/mcp-spec-test` conformance suite pinned to MCP spec revision **2026-07-28**, the server does not implement the new pre-handshake `server/discover` method (it returns a JSON-RPC `-32601 Method not found` error, or in some runs the process/socket doesn't respond within the timeout), and the official-SDK client fails to complete the `initialize` handshake for this revision. By contrast, this same server tested cleanly against the older **2025-11-2

[Read the thread](https://github.com/AVIDS2/memorix/issues/249) · 2026-08-24 · open · external user · 3 comments

### HTTP control plane wedges /health on 40k+ observation stores

## Description

On hosts with a large local store (~40k–64k observations and a ~305MB Jina embedding cache), `memorix serve-http` accepts TCP on `:3211` but `/health` and MCP `initialize` time out for tens of seconds. LaunchAgents / watchdogs that probe `/health` or `initialize` in 15s then kill a process that is still warming up, which looks like a crash loop.

This is the HTTP control-plane form of #27 (closed). 1.6.0 still hydrates the corpus and parses the on-disk embedding cache on the HTTP

[Read the thread](https://github.com/AVIDS2/memorix/issues/215) · 2026-08-17 · closed · outside contributor · 3 comments

### HTTP control plane binds project to server cwd, not client workspace

## Description

In HTTP / control-plane mode, project-scoped tools bind to the **server process cwd** (often `$HOME` when started via LaunchAgent / `memorix background start`), not the client workspace.

Grok, Cursor, and other HTTP clients then get:

```
Cannot build project context for the current project yet.
No git project could be resolved from "<home>".
This client did not provide a usable workspace root, so project-scoped tools are disabled...
```

`memorix_search` (project scope), `memor

[Read the thread](https://github.com/AVIDS2/memorix/issues/198) · 2026-08-14 · closed · outside contributor · 3 comments

### HTTP MCP idle session close (30min) is silent; clients hang or handshake-fail

## Description

The HTTP control plane closes idle MCP sessions after **30 minutes** (`MEMORIX_SESSION_TIMEOUT_MS`, logged as `HTTP session idle timeout: 30min`). The close is only written to `background.log`. MCP clients (Grok, Claude, Codex) do not get a visible protocol error, so:

- in-flight or next tool calls hang or `handshake_failed`
- the chat looks stalled and then just ends
- users report “Memorix froze the chat for ~30 minutes”

This matches the log line:

```
[memorix] Session <id> 

[Read the thread](https://github.com/AVIDS2/memorix/issues/197) · 2026-08-14 · closed · outside contributor · 2 comments

### memorix_store can hang until MCP client timeout (observed 6000s)

## Description

`memorix_store` can fail to return a tool result for the full lifetime of the MCP client timeout. In Grok this default is **6000 seconds**. Two production sessions recorded:

- `2026-08-10T21:40:08Z` → `2026-08-10T23:20:08Z` — `memorix_store` `duration_ms=6000002` `success=false` — `MCP tool 'memorix_store' timed out after 6000 seconds`
- `2026-08-12T12:01:00Z` → `2026-08-12T13:41:00Z` — same error, `duration_ms=6000010`

Successful stores in the same sessions typically complete 

[Read the thread](https://github.com/AVIDS2/memorix/issues/196) · 2026-08-14 · closed · outside contributor · 3 comments

### 如何配置和解决 memorix.memorix_project_context() 超时问题

Memorix 版本号:  1.1.8 
在codex cli中配置, 使用stdio方式启动
config.toml 配置

```
[mcp_servers.memorix]
command = "memorix"
args = ["serve"]

[mcp_servers.memorix.tools.memorix_project_context]
approval_mode = "approve"

[mcp_servers.memorix.tools.memorix_store]
approval_mode = "approve"

[mcp_servers.memorix.tools.memorix_search]
approval_mode = "approve"

[mcp_servers.memorix.tools.memorix_detail]
approval_mode = "approve"
```

现在由于单个项目中active的条数太多了, 会导致新开会话使用 memorix_project_context() 超时. 

memorix retenti

[Read the thread](https://github.com/AVIDS2/memorix/issues/124) · 2026-07-13 · closed · external user · 5 comments

### 在cursor出现因为stdio类型的MCP没有传递正确的当前项目目录地址，而出现.git目录寻址错误

<img width="2560" height="1390" alt="Image" src="https://github.com/user-attachments/assets/4c47109f-daa8-4224-9a9d-0c467edd4be6" />

我在cursor内使用最新的memorix时，总是出错，cursor MCP的报错日志如下：

```log
2026-04-10 18:12:38.562 [info] [V2] Handling CreateClient action
2026-04-10 18:12:38.562 [info] [V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
2026-04-10 18:12:39.735 [error] [memorix] Starting with cwd: C:\Users\pc
[memorix] Unable to establish a reliable git-backed 

[Read the thread](https://github.com/AVIDS2/memorix/issues/75) · 2026-04-10 · closed · external user · 3 comments

### Startup should not block MCP availability on full embedding rebuild

## Summary
Starting the MCP server currently does a full `reindexObservations()` during startup and hot reload. On larger projects with API embeddings enabled, that couples MCP availability to corpus-wide embedding throughput.

In practice this can block the entire Memorix MCP from becoming available to clients like OpenCode, even though lexical/fulltext search could be ready immediately.

## Why this matters
For large corpora, startup currently does all of the following before the MCP is usable

[Read the thread](https://github.com/AVIDS2/memorix/issues/27) · 2026-03-27 · closed · outside contributor · 3 comments

## Most recent

### Server advertises MCP revision 2026-07-28 in server/discover but the pinned SDK does not implement it

## Summary

The HTTP server advertises MCP protocol revision `2026-07-28` in
`server/discover`, but the pinned SDK does not implement that revision. A client
that trusts the advertisement applies the strict 2026 schema and rejects every
`tools/list` response.

With Claude Code 2.1.245 this shows up as:

```
memorix: http://127.0.0.1:3211/mcp (HTTP) - ! Connected · tools fetch failed —
Invalid result for tools/list: missing required resultType — servers implementing
protocol revision 2026-07-28 M

[Read the thread](https://github.com/AVIDS2/memorix/issues/257) · 2026-08-25 · closed · outside contributor · 1 comment

### HTTP transport rejects every tools/list from Claude Code with -32000 "Stateless MCP requests require Mcp-Project-Handle"

## Summary

Since 1.8.0, Claude Code cannot use memorix over HTTP at all. Every `tools/list`
fails with `-32000 Stateless MCP requests require Mcp-Project-Handle; initialize
first.`, so the client shows `Connected · tools fetch failed`.

## Environment

- memorix 1.8.0 – 1.8.3 (verified on 1.8.3)
- Claude Code 2.1.245
- transport: `memorix serve-http`

## Reproduction

```bash
memorix serve-http --port 3299 &

curl -sS -i -X POST http://127.0.0.1:3299/mcp \
  -H 'Content-Type: application/json' 

[Read the thread](https://github.com/AVIDS2/memorix/issues/255) · 2026-08-25 · closed · outside contributor · 1 comment

### Dashboard: Retention page should offer Archive action

## User pain

The Retention page already shows archive-candidate counts and scores, but archiving still requires CLI/MCP:

- `memorix retention archive`
- MCP `memorix_retention` with `action: "archive"`

Operators should not have to re-type that after the control plane has already listed the candidates.

## Current vs desired UX

**Current (v1.6.1)**

- Retention is **read-only scores** (`loadRetention()` in `src/dashboard/static/app.js`).
- Summary cards show active / stale / archive candidate

[Read the thread](https://github.com/AVIDS2/memorix/issues/229) · 2026-08-17 · closed · outside contributor · 0 comments

### Dashboard: add Deduplicate button (preview + apply)

## User pain

The dashboard already lists observations, but **deduplicate** is CLI/MCP-only. Operators who can see duplicates in the control plane still have to type:

- `memorix memory deduplicate`
- MCP `memorix_deduplicate`

That marks overlapping memories resolved. There is no dashboard button, no preview, and no POST endpoint to run it.

## Current vs desired UX

**Current (v1.6.1)**

- No Deduplicate button anywhere in the UI.
- Observations `[CLEANUP]` only toggles batch-select for manual

[Read the thread](https://github.com/AVIDS2/memorix/issues/227) · 2026-08-17 · closed · outside contributor · 0 comments

### Dashboard: add Consolidate / Dream button (preview + execute)

## User pain

Operators already open the web dashboard (control plane on `:3211`, or `memorix dashboard` on `:3210`) to inspect memory. Consolidation — docs nickname **Dream** — still requires leaving the UI and typing CLI/MCP by hand:

- `memorix memory consolidate --action preview|execute`
- MCP `memorix_consolidate`

Background consolidation only runs on MCP startup when `auto_cleanup = true`. There is no way to trigger it from the dashboard.

## Current vs desired UX

**Current (v1.6.1)**

-

[Read the thread](https://github.com/AVIDS2/memorix/issues/226) · 2026-08-17 · closed · outside contributor · 0 comments

### HTTP/stdio without projectRoot still binds $HOME and can create a decoy ~/memorix.db

## Description

Follow-up to #198 (closed). HTTP and stdio clients that omit `projectRoot` still bind the **server cwd**. LaunchAgents and Cursor's stdio plugin often start with cwd `$HOME`. Memorix then:

1. Treats `$HOME` as the project (`No git project could be resolved from "/Users/…" / "/home/…"`).
2. Can create an empty decoy **`$HOME/memorix.db`** (4096 bytes, 0 observations) while the real store is `~/.memorix/data/memorix.db`.

Agents then search an empty store and conclude "Memorix has

[Read the thread](https://github.com/AVIDS2/memorix/issues/225) · 2026-08-17 · closed · outside contributor · 2 comments

### First memorix_session_start still takes 15-28s on 40k+ stores

## Description

After `/health` and MCP `initialize` are fast, the **first** `memorix_session_start` (and CLI `memory store`) still takes **15–28s** on a 40k–52k observation store. That is `initObservations` → `loadAll()` + lexical hydrate for the tool, not a hang.

Subsequent search/detail on the same HTTP process are milliseconds. The first tool in a cold control plane still feels broken to agents (Cursor / Claude / OpenCode timeouts of 10–15s).

## Steps to Reproduce

1. Restart `memorix back

[Read the thread](https://github.com/AVIDS2/memorix/issues/224) · 2026-08-17 · closed · outside contributor · 2 comments

### Cached-vector attach starves MCP initialize; OpenCode marks memorix failed

## Description

After HTTP is up and `/health` is green, `attachCachedVectors` updates tens of thousands of Orama documents with 1024-d vectors on the same event loop. Yields every 10/50 updates are not enough: the process sits at 60–70% CPU for many minutes.

MCP `initialize` then accepts the TCP connection but writes 0 bytes for 20s. OpenCode `mcp list` reports:

```
✗ mcpm_memorix failed
   http://127.0.0.1:3211/mcp
```

even though the config is correct and `/health` returns `ok`.

## Steps 

[Read the thread](https://github.com/AVIDS2/memorix/issues/223) · 2026-08-17 · closed · outside contributor · 2 comments

### withTimeout does not abort in-flight LLM/embedding fetches

## Description

`withTimeout` (`src/timeout.ts` in 1.4.3) only races a timer against a Promise. It does **not** abort the underlying `fetch` / LLM / embedding work.

```js
function withTimeout(promise, ms, label) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error(`${label} timed out after ${ms}ms`)), ms);
    promise.then(value => { clearTimeout(timer); resolve(value); }, error => { clearTimeout(timer); reject(error); });
  });
}
```

After the wrap

[Read the thread](https://github.com/AVIDS2/memorix/issues/200) · 2026-08-14 · closed · outside contributor · 2 comments

### Expose privacy-safe memory handoff receipts for cross-agent debugging

I saw #93 and the maintainer response about the important distinction between:

- MCP connection is configured correctly
- a memory write was actually requested by the agent / hook / CLI
- another agent searched the same project identity and got a result

That distinction seems worth making observable, because users understandably read “cross-agent memory” as “my Trae/Codex conversation will show up elsewhere automatically”. The current answer clarifies it well, but a small receipt/doctor artifa

[Read the thread](https://github.com/AVIDS2/memorix/issues/95) · 2026-05-21 · closed · external user · 2 comments

The remaining reports are on [the project's issue tracker](https://github.com/AVIDS2/memorix/issues).