Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/memorix/issues.md or /mcp/memorix/issues.json, or Pod over MCP.

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.

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 · 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 · 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 · 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:

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 · 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

Reproduction

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 · 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:

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 · 2026-05-21 · closed · external user · 2 comments

The remaining reports are on the project's issue tracker.