* fix(memory): write the knowledge graph atomically
`saveGraph()` wrote the graph straight to the memory file:
await fs.writeFile(this.memoryFilePath, lines.join("\n"));
`fs.writeFile` opens the target with `'w'`, which truncates it before any
new bytes are written. If the process is interrupted between truncation
and completion — SIGKILL, container or host stop, OOM kill, power loss —
the memory file is left empty or half-written.
That file is the only persistence layer for the knowledge graph, so the
window is small but the loss is total and unrecoverable.
The fix writes to a temporary file in the same directory and renames it
over the target. `rename(2)` is atomic on POSIX filesystems: a reader
sees either the complete old file or the complete new one, never an
intermediate state. Keeping the temp file in the same directory ensures
the rename stays on one filesystem, since cross-device renames fail with
EXDEV. On failure the temp file is removed so no strays accumulate.
Tests added in `__tests__/atomic-save.test.ts`:
- the live memory file is never opened for truncating writes
- a committed graph survives a write that fails midway
- no temporary files remain after a successful write
- the temporary file is cleaned up when the rename fails
- graph contents still round-trip correctly across reloads
The first and fourth fail against the previous implementation.
Full suite: 55 passed (50 existing, 5 new). `tsc --noEmit` clean.
Fixes#4614
* fix(memory): use randomBytes for temp filename to avoid concurrent collision
---------
Co-authored-by: teddiesloco <teddiesloco@users.noreply.github.com>
* feat(memory): expose knowledge graph as MCP Resource
Register the knowledge graph as a readable MCP Resource at
memory://knowledge-graph, enabling clients to discover and read
the graph via the Resources protocol without invoking a tool.
Mutation tools (create_entities, create_relations, add_observations,
delete_entities, delete_observations, delete_relations) now emit
notifications/resources/updated so subscribed clients see live
graph changes.
Resource registration is extracted into the exported
registerKnowledgeGraphResource() function so it can be unit-tested
in isolation, mirroring the everything server's registration
pattern. New tests assert registerResource is called with the
correct kebab-case name, URI, mime type, and that the handler
returns the graph as JSON in the contents array.
Addresses PR #3323 review feedback:
- kebab-case resource name per CLAUDE.md style guide
- single-line comment per CLAUDE.md style guide
- title metadata for client discoverability
- resource update notifications after mutations
- test coverage matching everything/registrations.test.ts pattern
- README documents the new Resource
* feat(memory): support resources/subscribe for the knowledge-graph resource
PR #3323 emitted notifications/resources/updated after every mutation but
the server only advertised resources.listChanged, so resources/subscribe
returned -32601 and a spec-compliant client could never actually subscribe.
Declare resources.subscribe, add subscribe/unsubscribe request handlers that
track subscribed URIs, and only emit notifications/resources/updated when the
client has subscribed to that URI.
Co-authored-by: Lazreg Raed <lazregraed222@gmail.com>
---------
Co-authored-by: olaservo <olahungerford@gmail.com>
Previously, `openNodes` and `searchNodes` only returned relations where
BOTH endpoints were in the result set (using `&&`). This silently
dropped all relations to/from nodes outside the set — making it
impossible to discover a node's connections without calling `read_graph`
and filtering the entire dataset client-side.
Changed the filter from `&&` to `||` so that any relation with at least
one endpoint in the result set is included. This matches the expected
graph-query semantics: when you open a node, you should see all its
edges, not just edges to other opened nodes.
Fixes#3137
Tests updated and new cases added covering:
- Outgoing relations to nodes not in the open set
- Incoming relations from nodes not in the open set
- Relations connected to a single opened node
- searchNodes returning outgoing relations to unmatched entities
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(memory): convert to modern TypeScript SDK APIs
Convert the memory server to use the modern McpServer API instead of
the low-level Server API.
Key changes:
- Replace Server with McpServer from @modelcontextprotocol/sdk/server/mcp.js
- Convert all 9 tools to use registerTool() instead of manual request handlers
- Create reusable Zod schemas for Entity and Relation types
- Use Zod schemas directly in inputSchema/outputSchema
- Add structuredContent to all tool responses
- Fix type literals to use 'as const' assertions
The modern API provides:
- Less boilerplate code (removed ~200 lines of schema definitions)
- Better type safety with Zod
- More declarative tool registration
- Cleaner, more maintainable code
* fix: exclude test files from TypeScript build
Add exclude for test files and vitest.config.ts to tsconfig
- Added DETECTED message when legacy memory.json file is found
- Added COMPLETED message when migration finishes successfully
- Improves visibility of backward compatibility migration process
Co-authored-by: Ola Hungerford <olaservo@users.noreply.github.com>
When no custom MEMORY_FILE_PATH is set and memory.json exists but
memory.jsonl doesn't exist, automatically migrate the old file to
the new format with proper file extension.
This ensures existing users don't lose their data when upgrading
to the version with the corrected .jsonl extension.
Co-authored-by: Ola Hungerford <olaservo@users.noreply.github.com>
The Memory MCP server uses JSONL format (JSON Lines) where each line
contains a separate JSON object, but was using a .json file extension.
This caused IDE lint errors and confusion since the file is not valid JSON.
Changes:
- Update default filename in index.ts from memory.json to memory.jsonl
- Update documentation references in README.md
- Maintain backward compatibility for existing MEMORY_FILE_PATH configs
Fixes#2361
Co-authored-by: Ola Hungerford <olaservo@users.noreply.github.com>
- Add environment variable MEMORY_FILE_PATH to configure custom storage location
- Support both absolute and relative paths
- Update documentation with configuration examples
- Bump version to 0.6.3
