Graph Memory Plugin: Learnings Saved by Hooks, Stored as a Graph You Can Read


The Graph Memory plugin uses your coding agent's hooks to save what a session learned and to bring it back when the next session starts. It does this in Claude Code, Codex and Grok Build with three hook events and one graph: it recalls up to five learnings on your first prompt, uploads a trimmed excerpt of the session when it ends, and stores what the session taught as typed statements in a learn-<project> knowledge graph in your own account. Its name is InfraNodus Graph Memory, its id in the catalogs is infranodus-memory, and the recall is GraphRAG: it follows the links between concepts by hop distance rather than matching text, so it also returns a learning reachable only through an intermediate concept.

Auto memory, which Claude Code ships with, already writes notes for itself into a MEMORY.md file on one machine. What the plugin changes is the form of the memory: a graph you can open, where you see which lessons cluster, which decisions sit alone, and where the memory never connects. The plugin names one of those gaps on the first prompt of a session, before Claude falls into it again. The same plugin runs in Codex and in Grok Build, and the same graph is read on your other machine, from Cursor through the InfraNodus MCP server, in the web app, and in the Obsidian plugin.

Get Started

1
Create an Account

Sign up for a free InfraNodus account to get access to the knowledge graph tools and your API key.

Create a Free Account
2
Install the Plugin
/plugin marketplace add infranodus/plugins
/plugin install infranodus-memory@infranodus-plugins

Run these two commands in the Claude Code prompt. Claude Code asks for your InfraNodus API key once and keeps it in your system's secure store.

3
Open a Project and Send One Prompt

Memory runs in any folder with a git repository or a project file. Your first prompt shows one line with a link to the graph, and /infranodus-memory:off stops it for that project.

4
Work, Then End the Session

There is nothing to run by hand. When the session ends or compacts, the upload starts in the background, and the next session tells you how many learnings were saved. /infranodus-memory:forget-last removes them.

5
Open the Graph

After a few sessions, read the clusters and the gaps between them. When the graph has a few dozen statements, run /infranodus-memory:optimize to find the clusters that never connect and the statements that would bridge them.

The Graph Memory plugin cycle: recall on the first prompt, work, upload at session end, extraction into the learn graph, next session
The cycle: recall on the first prompt, upload when the session ends, extraction into the learn graph, and the next session starts from it.

What the Graph Memory Plugin Does That Auto Memory Does Not

A memory plugin is a plugin whose hooks run at fixed moments of a session: when you submit a prompt, before the context is compacted, when the session ends. Auto memory lets Claude decide what to note down while it works. A plugin captures the session itself and lets a separate extraction step decide what to keep. The capture is the same every time. What differs between plugins is what happens to the capture afterwards, and whether you can see the result.

Most plugins stop at retrieval. Claude-Mem summarizes each session into a local database and injects the last few sessions at the start of the next one. Mem0 and Supermemory send memories to a hosted store and search them when the agent asks. All three are good at bringing text back. None of them shows you the memory as a structure, so you cannot tell which lessons repeat or which part of the project the agent has never formed a memory about.

This plugin treats the memory as the thing you look at. Each session becomes a handful of statements of a named type: a trap, a decision with its reason, a workflow that worked, a convention, a location, an open question. Each statement links the concepts it names, so after a few sessions the graph has clusters and gaps between them. The Claude Code memory guide covers CLAUDE.md and auto memory in detail. This page covers what the plugin adds on top of them.

Which Claude Code Hooks a Memory Plugin Uses

Claude Code's hooks reference lists the events a plugin can attach a command to. Three of them are enough for memory. UserPromptSubmit runs before Claude reads your prompt and can add text to the context through additionalContext. PreCompact runs before the conversation is summarized to make room. SessionEnd runs when you quit. The plugin registers one command on each of them in its hooks.json, with a five second timeout.

Hook When it fires What the plugin does How long it takes
UserPromptSubmit Your first prompt of a session. Later prompts: nothing Sends the prompt and the project name to /api/v1/recall; injects up to 5 learnings and 1 gap as additionalContext One HTTP call with a 2 second limit, about 170 ms in practice
PreCompact Before Claude Code compacts the context Starts a background upload of the session so far About 5 ms; the upload runs detached
SessionEnd When the session closes Uploads the lines not uploaded yet About 5 ms

A session is stored as typed statements, and the gaps between those statements are what the next recall reports, so the hook chain and the graph form one loop.

Nothing runs during the session. There is no hook on tool calls, no local service listening on a port, and no daemon. Claude Code already writes every session to a transcript file, and the PreCompact and SessionEnd events hand the plugin its path, so the upload reads the transcript at that moment instead of recording tool calls one by one. If the API key is missing, the server is slow, or anything else fails, the hook prints nothing and exits with code 0. Claude Code never waits on InfraNodus and never sees an error from it.

The same three events exist in Codex, with the same payload and the same additionalContext output, so the plugin ships one hook file for both; Codex caps SessionEnd hooks at three seconds, which the five millisecond hand-off meets. Grok Build loads Claude Code hooks as they are but sends a camelCase payload and ignores what a hook prints, so there the recall is written to a .grok/rules/ file that Grok loads at session start.

This is what the recall looks like from Claude's side. The block is capped at five items and about 1,500 characters; the example is from a web project's graph:

From InfraNodus memory (learn-infranodus-web):
- [learning: workflow] Edits under src/ need npm run build, then touch ../infranodus-app/app.js so nodemon reloads the cached fragments.
- [learning: trap] EJS include paths differ by folder: pages in views/website/docs/ use ../../components/, pages in views/website/ use ../components/.
- [learning: decision] New docs pages are wired in infranodus-app (app.js, marketingStubs.js) as well as routes/website.js, because the app mounts the routes and serves the sitemap.
Gap: build, nodemon never connect to sitemap, robots.

What the Plugin Sends, and What It Never Sends

The upload is not the transcript. The worker builds an excerpt of about 6,000 tokens from the lines added since the last upload: your prompts, Claude's final answer in each turn, the tool calls that failed, the files edited, and a list of the shell commands that succeeded, with read-only ones such as ls, cat and grep left out. Tool output stays out. The commands are kept because they carry the how-to knowledge ("run the tests with node -r @babel/register") that prompts and answers alone miss. That was the finding of the extraction test on eight real sessions: a trimmed excerpt found most of the key learnings at about a tenth of the cost of the full transcript, and the commands list closed most of what it missed.

Before anything leaves the machine, API keys, tokens, private key blocks and key=value secrets are replaced with [REDACTED], and anything you wrap in <private>…</private> is dropped. Nothing is sent from your home folder, from temp folders, from a folder that is neither a git repository nor carries a project marker, or from any folder that matches the exclude_paths setting (~/clients/*, for instance). An excerpt under 500 characters is not sent at all. A failed upload waits in ~/.infranodus/queue/ and is retried by the next session's worker for up to seven days.

On the server, one AI call turns the excerpt into statements, each with its [[entities]] marked and its type set, and drops what will not be true next month: version numbers, branch names, what is committed, anything "currently". Facts about you rather than the project are kept out of the project graph. The statements are tagged with the session's id, which is what makes the undo possible. Each session costs one AI call against your InfraNodus quota. The recall is an ordinary API call with no AI involved.

What Claude Code Learnings Look Like in the Graph

Every statement is one sentence, under 300 characters, self-contained, of one of seven types. The extraction prompt asks for fewer, better statements: three to twelve per session is typical, and an empty list is a valid answer for a session that taught nothing durable.

Type What it records Example
location Where something lives The language override lives in getContextForEntry in [[lib/context.js]]
trap What fails or misleads, and how to avoid it Running [[scripts/recomputeProfiles.js]] without --dry-run writes to production
convention A rule the project follows New docs pages are wired in [[app.js]] and [[marketingStubs.js]], not only in [[routes/website.js]]
decision A choice, always with its reason The FREE file cap is 500 KB and Cloud PDF 2 MB so that upgrading raises both limits
workflow A sequence or command that works Run [[lib/ai.js]] in tests with babel-node, not node
question Something the session left open Does [[gpt-6.1-sol]] accept reasoning_effort at all, or only some values?
approach What worked well or badly in how the task was done Reading [[CLAUDE.md]] before grepping saved a wrong build command

Open learn-<project> in the InfraNodus app and the statements become a network. Concepts are nodes, two concepts in one statement are an edge, and the size of a node is its betweenness centrality: how much of the agent's knowledge routes through it. In most repositories one cluster is the build and restart loop, another is the traps, and the decisions sit at the edges, connected to little. Select a cluster to inspect the statements behind it. Remove the top nodes and the graph re-forms around what was underneath: the lessons learned once and never connected to anything.

Then open the content gaps. A gap is two clusters with no statement bridging them, and in a learnings graph that is the exact shape of a rediscovery: the agent knows the deploy routine and knows the caching rule, and has never recorded that one breaks the other. The plugin reads these gaps on every recall and names the one that touches your current task ("Gap: build, nodemon never connect to sitemap, robots"), so the hole is visible before the session starts. /infranodus-memory:optimize runs the same analysis on demand and proposes statements that would bridge the gaps it finds; you approve the ones that are true. /infranodus-memory:recall webpack answers the narrower question: what is this concept connected to, one and two hops out, and which learnings sit on those links.

A gap between two clusters of a learnings graph is the shape of a rediscovery
A gap between two clusters of a learnings graph is the shape of a rediscovery: two things the agent knows, never connected.

The last step is manual on purpose. Ask AI Insights a follow-up on the selected gap ("what rule would connect these?"), save the answer to Project Notes, and write the one-line rule into CLAUDE.md. The files get shorter and more current because the graph showed what they were missing. The /infranodus skill can graph the repository itself, so you can compare the code graph with the learnings graph and see which modules the agent has worked in without learning anything about them.

Claude-Mem Plugin, Mem0, Supermemory and Auto Memory: What You Can See Afterwards

The comparisons of memory plugins that AI answers cite share the same columns: which hooks capture, where the memory lives, what a month costs. The column that decides whether the memory is worth having is missing from all of them: what you can see afterwards. This table adds it. For ten memory tools placed by storage model and price, see agent memory tools compared.

Auto memory Claude-Mem Mem0 Supermemory Graph Memory plugin
How it captures Claude writes notes when it decides to Lifecycle hooks on session start, tool use and stop; a summary per session Plugin with hooks, an MCP server and a rubric for when to search Plugin and MCP server; the agent adds memories Recall on the first prompt; upload at compaction and session end
Where it lives MEMORY.md and topic files on one machine Local SQLite with full-text and optional vector search, run by a local worker Mem0's hosted platform Hosted API, with a local Docker option A learn-<project> graph in your InfraNodus account
Other machines and clients No No Yes, through the platform Yes, through the API Yes: hooks in Claude Code, Codex and Grok Build; the graph in any MCP client, the web app, the Obsidian plugin
Read it yourself A list, through /memory A web viewer and generated timelines By ID through the API Through the API Every statement, editable in the app or with update_statements
Shows structure and gaps No No No No Clusters, central concepts, content gaps; one gap per recall
Undo a session Edit the file Not documented Delete by ID Delete by ID /infranodus-memory:forget-last
Runs a local service No Yes, a background worker on a local port No Only in the local Docker setup No; two scripts that exit silently on any error
Cost Included Free; paid Pro tier Free tier: 10,000 memory additions and 1,000 retrievals a month Free tier: $5 of credits a month Free account; one AI call per session from its quota

Other guides add Basic Memory, Engram and a dozen more rows; the ten-tool comparison covers the ones with a published storage model. One difference the table hides: plugins that summarize on your machine need an AI provider configured and paid for locally, while here the extraction runs on the InfraNodus server against the account's quota, so the API key is the only thing to set.

Two rows carry the weight. "Shows structure and gaps" is the reason to store memory as a graph at all: a list of memories cannot report what it is missing. "Runs a local service" is where the Reddit threads about Claude-Mem spend their time, with an antivirus flag and an audit of an unauthenticated local port. This plugin has no process to audit: the hooks are two Python files that use only the standard library, read one JSON object from standard input, make at most one HTTP call, and exit. What they send is the excerpt described above, and the tests in the repository show it.

Plugin or Skill: When the Opt-In Loop Is the Better Choice

The plugin and the Project Learnings skill write the same graph. The skill is opt-in per project: you enable learnings once, Claude proposes a batch at the end of a task, and nothing is saved until you approve it. It works in any client that connects the InfraNodus MCP server, including Claude Desktop, Codex and Cursor. The plugin is on from the moment you install it, in every project on that machine, and saves without asking; the undo is per session, and /infranodus-memory:off turns it off for one project while keeping the graph.

Choose the skill when you want to read every statement before it is stored, or when you work in a client without hooks. Choose the plugin when you run many sessions a day and would never remember to ask for a reflection at the end of each. Running both costs nothing: the plugin captures, and get_project_learnings is how Claude reads the graph in the middle of a task, with the task as the query. The memory MCP page shows the three memory graphs this one belongs to, and the AI memory stack explains why learnings, insights and content stay apart.

Install the Graph Memory Plugin

1. Create an account and copy the API key

Create a free InfraNodus account and copy the key from the API access page. The plugin asks for it once, at install, and keeps it in your system's secure store.

2. Add the marketplace and install the plugin

/plugin marketplace add infranodus/plugins
/plugin install infranodus-memory@infranodus-plugins

infranodus/plugins is the marketplace for InfraNodus plugins; it also lists the core infranodus plugin, and the skills have their own marketplace, infranodus/skills. To install from the plugin's own repository instead, add infranodus/infranodus-memory-plugin and run /plugin install infranodus-memory@infranodus-memory. Claude Code shows the plugin's description and asks for the key. The key is the only credential the hooks use: the recall on the first prompt and the upload at the end both carry it. The plugin also registers the InfraNodus MCP server, which authenticates on its own in /mcp and gives the same session the graph tools that /infranodus-memory:recall and :optimize call. Three optional settings in /plugin: save (both, the default, saves project learnings and topic facts about clients or cases, each in its own memory-<topic> graph; learnings saves project knowledge only), exclude_paths (folders where memory never runs), and api_base for a self-hosted server.

Codex instead of Claude Code

The same marketplace carries a Codex catalog, and the plugin's repository carries its Codex manifest:

codex plugin marketplace add infranodus/plugins

Install infranodus-memory from that marketplace in the Codex app or the /plugins screen, then trust its three hooks in /hooks; Codex runs no hook it has not been shown. Codex has no plugin settings screen, so set the key once with python3 <plugin folder>/hooks/memory.py set-key YOUR_KEY or export INFRANODUS_API_KEY. From then on the cycle is the one above: Codex sends the same events and the same transcript_path, and the plugin reads Codex's session rollout the way it reads a Claude Code transcript.

Grok Build instead of Claude Code

Grok loads Claude Code plugins and marketplaces without conversion, so the two Claude Code lines above, or grok --plugin-dir <plugin folder>, are enough. Trust the hooks with /hooks-trust and set the key as for Codex. Grok ignores a hook's output, so the plugin writes the recall to .grok/rules/infranodus-memory.md in the project, which Grok loads when a session starts; keep it out of commits with .git/info/exclude. Uploads run when Grok hands the hook a transcript path it can read.

3. Open a project and send one prompt

The first prompt in a project shows one line: "InfraNodus memory is on for <project> → graph link. /infranodus-memory:off to stop for this project." Memory is on for every folder with a git repository or a project marker (package.json, pyproject.toml, .obsidian, and the like); the line appears once per project. If nothing shows, run /infranodus-memory:status: it reports the project name, whether memory is on, and whether the key is set.

4. Work, then end the session

Nothing to run by hand at this step. When the session ends or compacts, the upload starts in the background. The next session opens with "InfraNodus memory saved 3 learnings from your last session in <project>". Read them before you trust them: open the graph link, or run /infranodus-memory:recall with the topic of the day. If a session saved something wrong, /infranodus-memory:forget-last removes everything from that session. To save in the middle of a long session instead of at its end, run /infranodus-memory:save.

5. After a few sessions, open the graph

Read the clusters, open the gaps, and move the one rule that would have saved the most rediscoveries into CLAUDE.md. Run /infranodus-memory:optimize when the graph has a few dozen statements; it also reads Claude's own memory notes, claude-mem and mem0 when they are present, so one pass covers every memory the project has.

Command What it does
/infranodus-memory:status Project name, on or off, key set or not
/infranodus-memory:recall <concept or question> What memory holds on it: a GraphRAG lookup along the graph's links, by hop distance
/infranodus-memory:save Upload this session now instead of at its end
/infranodus-memory:optimize Find the clusters that never connect and propose bridging statements
/infranodus-memory:forget-last Remove the learnings saved from the last session
/infranodus-memory:off and :on Stop or resume memory for this project on this machine; the graph is kept

Get Started


Frequently Asked Questions

How do I give Claude memory that persists across sessions?

It depends on which Claude. Claude.ai has a memory setting in the app, and the API has a memory tool. Claude Code has CLAUDE.md and auto memory, both loaded at the start of every session and both limited to one machine. For memory that persists across sessions, machines and clients, install the Graph Memory plugin or connect the memory MCP server: the learnings live in a graph in your account that every client reads.

Is the Claude-Mem plugin the same kind of memory plugin?

The same kind, with a different end product. The Claude-Mem plugin captures observations through lifecycle hooks, summarizes each session into a local SQLite database, and injects recent sessions at the start of the next one. This one captures through three hooks and turns the session into typed statements in a graph you can open. One gives you back what was said. The other shows you what was learned and where the learning is thin.

Claude-Mem is on GitHub. Where is this plugin's code?

Both are on GitHub. Claude-Mem's repository holds the plugin, its local worker and its viewer. This plugin lives at github.com/infranodus/infranodus-memory-plugin: two Python files for the hooks, the seven commands, the tests, and the extraction experiments with their results, so you can read what the hook sends before you install it. The extraction itself runs on the InfraNodus server, where the same endpoints serve the MCP memory tools.

What do the Claude-Mem Reddit threads ask for, and does this plugin answer it?

The threads ask for two things: an alternative without a local worker, after an antivirus flag and an audit of an unauthenticated local port, and a memory that does not grow into noise. This plugin runs no local service and opens no port. Its hooks exit silently on any error, secrets are redacted before upload, and you turn it off per project. Against noise: statements are deduplicated and superseded on the server, and the graph shows you what accumulated.

Is there a Claude-Mem skill equivalent in this plugin?

Claude-Mem adds a skill with search tools and private tags. This plugin adds seven commands under its own namespace, so they never clash with Claude Code's /memory: /infranodus-memory:recall for GraphRAG lookups that follow the graph's links by hop distance, /infranodus-memory:optimize for gaps, /infranodus-memory:save and /infranodus-memory:forget-last for control. Text inside <private> tags is never uploaded. For the opt-in loop with a confirm step, install the Project Learnings skill.

Does a memory plugin slow Claude Code down?

This one is built not to. The recall hook runs once per session, on the first prompt, with a hard two second limit; the upload hooks return in about five milliseconds and hand the work to a detached process. No hook runs on tool calls. On any error, timeout or missing key the hooks print nothing and exit with code 0, so a slow server costs you nothing. Each hook logs its own duration to ~/.infranodus/timings.log so you can check.

Does it work in an Obsidian vault?

Yes. A folder with an .obsidian directory counts as a project, so running Claude Code inside a vault gives the vault its own learn-<vault> graph: where notes on a subject live, which templates the vault uses, which links break. The Obsidian Graph View Plugin opens the same graph next to your notes, and the Obsidian MCP page compares the four ways to connect Claude to a vault.

Does the plugin work with Codex, Grok Build or Cursor?

Codex and Grok Build run the plugin's hooks: Codex from its own manifest in the same repository, Grok through its Claude Code compatibility. Cursor has no hooks that can inject context, so there the memory is read over the InfraNodus MCP server with get_project_learnings and written through the Project Learnings skill and its confirm step. All of them read and write the same learn-<project> graph. Set up the server for each client on the Claude Code and Cursor pages.


 

Give Claude Code a Memory That Fills Itself

Install the plugin, run your next session as usual, and open the graph after a week: the clusters of what Claude learned about your project, the concepts that connect them, and the gaps between them.

Log In    Sign Up    Get the MCP Server
 

 
Get the InfraNodus MCP