graphmem: one shared brain for every Claude and Codex session I run

Claude Code and ChatGPT Codex are absurdly capable, absurdly fast systems. I want to take that power one step further and use it everywhere: in my projects, in my backend, on my VMs, on my local machine. From that vantage point, the plan looks quite clean.

Then reality shows up. MongoDB, GCP, Turso, Oracle Cloud, Tailscale, SSH keys, environment variables, Vercel, Cloudflare. Each with its own secrets, its own settings, its own deployments and automations, and things get messy fast. My first attempt was the obvious one: lean on Claude's and Codex's built-in memory, plus notes saved locally. It fell apart for two reasons:

1. It doesn't scale. Past a certain point the agents either search endlessly or simply fail to find what they need.
2. Their own memory isn't enough for me. It remembers preferences; I need it to remember infrastructure.

Here is a concrete example of what I actually want. I have a bird-species app, and it shares a design lineage with my general project template. When a UI change lands in the birds app, I want that knowledge to flow back to the template, and the next time any agent works on the template, on any machine, I want it to already know about that change.

A generic automation system that still hits its target doesn't happen on memory alone. I wish it did.

The way out: Oracle's free tier

While hunting for a solution I discovered Oracle's Autonomous Database and their Always Free VM. Both are completely free, forever. The ADB ships with in-database embedding search and enough smart features to work beautifully as a graph database. The VM is roughly 1/6 the power of my laptop with 12 GB of RAM. Modest, but it never sleeps.

The conclusion was inevitable: build a global Claude / Codex workbench on the Oracle VM and ADB. And ta-da, here I am, open-source repo and all: graphmem.

The setup

Everything I tell any agent to remember becomes a node in one ever-growing, interlinked graph living in the Autonomous Database:

Three design choices matter most:

• Dedup-first writes. remember refuses near-duplicates and suggests linking instead, so the graph stays clean as it grows.
• Embeddings inside the database. No OpenAI key, no external API. Semantic search runs where the data lives, for free.
• Open vocabulary. Domains, kinds, and relation types are data, not schema. The graph grows forever with zero migrations.

What the memory actually looks like

Every dot is something an agent learned: a project, a server, a deployment recipe, a design decision, a pointer to where a credential lives. The edges are what make it work. My personal webpage links to the design template, the template links to the birds app, the birds app links to its MongoDB. When an agent walks the graph, it picks up exactly the context that plain flat memory kept losing.

This is the part that makes graph-based memory better than a pile of notes. Claude and Codex both feed from the same shared pool, and even when a semantic search doesn't land on the right answer on the first try, they don't give up. They land somewhere close, then wander node to node along the edges until they reach what they actually need. Flat memory either hits or misses; a graph lets the agent navigate.

Code and usage

Any machine connects in about five minutes. The database is in the cloud, so every device sees the same brain:

git clone git@github.com:sezer-muhammed/graphmem.git && cd graphmem
python3 -m venv .venv && .venv/bin/pip install -e .
cp .env.example .env            # ADB wallet + password
claude mcp add --scope user graphmem $PWD/.venv/bin/python -- -m graphmem.server

From then on it's invisible. Claude calls the tools on its own, or I poke at the graph directly:

graphmem recall "how do I reopen the website"   # semantic search
graphmem walk graphmem-project -d 2             # hop along weighted edges
graphmem stats                                  # health overview

What actually lives in the repo: one core module with all graph operations, and every interface is a thin wrapper around it. The MCP server for Claude and Codex sessions, the CLI, the force-directed web explorer, a fresh-database initializer that applies the schema and loads the ONNX embedding model, a daily keepalive job (the free-tier database auto-stops after 7 idle days, so a tiny cron touches it and can even auto-start it), and full export / import for portable backups. It is also packaged as a Claude Code plugin, so a new machine gets the MCP server, a usage skill, and a guided setup with one install command.

The most useful parts

Investigating a 100 GB dataset without downloading it. My home connection is 90 Mbit; the Oracle VM has 2.5 Gbit ethernet. So I don't download anything. Claude on the VM pulls the dataset at datacenter speed, analyzes it, writes the findings into the knowledge base, and deletes it. I read the conclusions from wherever I am.

Any session, anywhere, already knows. I update an app, a repo, a project. Then I open a completely different Claude or Codex session on another machine, and voila: it knows the important parts. And when it needs more than the summary, it knows where the credentials live, SSHes into that machine, connects to the session there, and reads whatever it needs.

Models training 24/7 while I take a walk. I have several models training around the clock because Claude Code watches them, improvises, and retrains for me. I read the progress every day, give feedback, and let it run. I don't even need to connect to that computer. I do it from my phone on my morning walk.

The model is replaceable. The VM is replaceable. The knowledge graph is the thing I would actually be sad to lose.

If this setup sounds interesting, get in touch and let's compare notes.