Forem: Mohamed ali May

Solving Claude's Amnesia: Building Persistent Memory with MCP

Mohamed ali May — Wed, 11 Feb 2026 12:14:50 +0000

As a solo developer working on his next idea, Claude has been my pair programming partner for months now, and honestly, it's been incredible, except for one problem that kept driving me crazy:

Every time I hit /compact, Claude forgets everything we just worked on.

All those architecture decisions we debated? Gone. That bug fix we finally figured out? Vanished. Client preferences I mentioned three times? Claude asks again. It's like Groundhog Day, except I'm the one who has to repeat myself.

Until one evening, when I closed my laptop in frustration and made myself some coffee and decided to dig deeper in the topic. After hours of reading, I found two papers that completely changed my life: Recursive Language Models from MIT and MAGMA about multi-graph memory architecture.

That's when it clicked. I could build a memory system that works the way I actually think.

What I built

MemCP is an MCP server that plugs into Claude Code. Here's what makes it different:

Never lose context again

MemCP watches for /compact commands. When you hit it, Claude gets blocked with "save your work first" until it actually saves insights and context. No more silent memory wipes.

There's also gentle reminders every 10 turns if Claude hasn't saved anything yet.

Two types of storage

Memory is for insights like decisions, facts, preferences, findings. Small pieces of knowledge that matter.

Contexts are for big stuff such as entire files, docs, logs. These stay on disk. Claude can inspect metadata (file type, size, tokens) without loading anything. Then peek at specific sections, grep for patterns, or chunk into navigable pieces.

Knowledge that connects itself

Every time Claude saves an insight, MemCP automatically builds connections:

Links to similar ideas
Links to things from the same work session
Links cause-and-effect (it detects "because" and "therefore" in text)
Links things mentioning the same files or modules

So when you ask "why did we make that choice?", it doesn't just keyword search, it follows the cause-and-effect chain.

Search that improves as you go

Start with basic install? Keyword search works fine.

Add one package? You get ranked search.

Add another? Typo tolerance.

Add embeddings? Searches understand meaning, not just words.

The system automatically uses the best method available. No config needed.

Navigation tools for large files

Say you have a 50,000-line codebase file. Instead of dumping it into context:

Inspect it first (see type, size, preview and costs zero tokens)
Chunk it into sections
Peek at just section 5
Filter for only function definitions

You control what enters your context window.

Smart cleanup

After 30 days, unused stuff gets compressed and archived automatically. Important things (marked critical, accessed frequently, tagged "keep") stay active.

If you need archived content later, it restores instantly.

Quick install

pip install claude-memory-mcp
bash <(curl -s https://raw.githubusercontent.com/maydali28/memcp/main/scripts/install.sh)

Two minutes. Restart Claude Code. Done.

What difference does it make?

I ran benchmarks comparing normal usage vs. MemCP:

Loading 500 insights normally costs 9,380 tokens. With MemCP? 462 tokens. That's 20x less.

Analyzing a massive 50K token document? Normally costs 50,460 tokens (eats your whole context). With MemCP? 231 tokens because you're just peeking at metadata and specific chunks. That's 218x less.

But the real killer stat: after /compact, normal mode loses almost everything. MemCP keeps 100% of your stored knowledge.

Real workflow example

Morning session:

memcp_remember("User sessions expire after 1 hour, use Redis for storage", 
              category="decision", importance="critical", tags="auth,redis")

Three days later:

memcp_recall(query="how long do sessions last?")

Claude instantly recalls the decision, sees it was tagged critical, knows it's about auth and Redis.

Working with large files:

memcp_load_context("api-routes", file_path="src/api/routes.py")
memcp_inspect_context("api-routes")  // Shows: python file, 2400 lines, ~15K tokens
memcp_filter_context("api-routes", pattern="def\\s+\\w+")  // Just function names
memcp_chunk_context("api-routes", strategy="lines", chunk_size=100)  // 24 chunks
memcp_peek_chunk("api-routes", 5)  // Read chunk 5 only

You navigate the file like a filesystem, not cramming it into context.

Why it matters for solo devs

When you're building alone, you can't afford to waste time re-explaining yesterday's decisions. MemCP gave me:

No more context anxiety
Sessions that build on previous work automatically
Ability to work with huge files without thinking about token limits
Decisions from last month still accessible today

The three weeks I spent building this paid back in productivity within the first month.

Try it

MemCP is open source (MIT):

GitHub: memcp
PyPi: claude-memory-mcp
RLM paper: RLM paper
MAGMA paper: MAGMA paper

21 tools. Zero mandatory dependencies. Works out of the box.

If you've ever hit /compact and felt that sinking feeling watching your context disappear, give it a try. Stars and feedback appreciated.

If this helped, drop a heart below!

PS: Yes, Claude helped me build its own memory system. Meta, I know.

Using docker for embedded systems development

Mohamed ali May — Mon, 09 Oct 2017 16:30:54 +0000

One of the top challenges that I have faced while working on some projects is updating the state of my entire work machine and some times breaking something unrelated, and this problem gets me crazy every time. As a fan of software development as well as embedded systems, I decided to mix the two disciplines and use virtual machines to solve this issue, by building an isolated environment for embedded systems development.

This may seem like a stretch, but the traditional way to do this is to create a virtual machine, install Linux, then install the packages we need for cross compiling, edit the code on the host machine, switch to the VM, compile and repeat the process every time. This is too slow and heavy and it's not fun.

So why do we need to use docker?

Well because it offers us an efficient and speedy way to port applications across systems and machines. It is light and lean, allowing you to quickly containerize applications and run them within their own secure environments.

background :

My goal is setting up an isolated and repeatable environment for developing STM32 applications using docker that encompasses all the needed resources and the automation we are using, also add a shared directory between the host file system and our docker container so that we don't need to copy the code every time to the VM and restart it.

Once all of this is ready, we can quickly start a development environment on our machine without having to worry about finding, installing, and configuring project dependencies every time we need it.

our final result features :
-Docker build files and Ubuntu 14.04LTS image;
-GNU ARM toolchain;
-GDB for debugging application;
-OpenOCD as GDB server;
-Example of LED blink Project for stm32F4;

The project originally is cloned from Here

Let's start

before we start you must setup docker, you can check the installation instructions Here from the official docker website. All the code of this tutorial is available on github. so go clone or fork the project now so you can have all the code to build, compile and modify it.

Write Dockerfile:

The container with our application is a little more interesting :

    #the first thing we need to do is define from what image we want to build from.
    #Here we will use a 14.04 LTS(long term support) version of ubuntu from docker Hub :
    FROM ubuntu:14.04

    MAINTAINER Mohamed Ali May "https://github.com/maydali28"

    ARG DEBIAN_FRONTEND=noninteractive

    RUN mv /etc/apt/sources.list /etc/apt/sources.list.old
    RUN echo 'deb mirror://mirrors.ubuntu.com/mirrors.txt trusty main restricted universe multiverse' >> /etc/apt/sources.list
    RUN echo 'deb mirror://mirrors.ubuntu.com/mirrors.txt trusty-updates main restricted universe multiverse' >> /etc/apt/sources.list
    RUN echo 'deb mirror://mirrors.ubuntu.com/mirrors.txt trusty-backports main restricted universe multiverse' >> /etc/apt/sources.list
    RUN echo 'deb mirror://mirrors.ubuntu.com/mirrors.txt trusty-security main restricted universe multiverse' >> /etc/apt/sources.list
    RUN apt-get update -q
    #install software requirements
    RUN apt-get install --no-install-recommends -y software-properties-common build-essential git symlinks expect

    # Install build dependancies
    RUN apt-get purge binutils-arm-none-eabi \
    gcc-arm-none-eabi \
    gdb-arm-none-eabi \
    libnewlib-arm-none-eabi
    RUN add-apt-repository -y ppa:team-gcc-arm-embedded/ppa
    RUN apt-get update -q
    RUN apt-cache policy gcc-arm-none-eabi
    RUN apt-get install --no-install-recommends -y gcc-arm-embedded

    #install Debugging dependancies
    #install OPENOCD Build dependancies and gdb
    RUN apt-get install --no-install-recommends -y \
    libhidapi-hidraw0 \
    libusb-0.1-4 \
    libusb-1.0-0 \
    libhidapi-dev \
    libusb-1.0-0-dev \
    libusb-dev \
    libtool \
    make \
    automake \
    pkg-config \
    autoconf \
    texinfo
    #build and install OPENOCD from repository
    RUN cd /usr/src/ \
    && git clone --depth 1 https://github.com/ntfreak/openocd.git \
    && cd openocd \
    && ./bootstrap \
    && ./configure --enable-stlink --enable-jlink --enable-ftdi --enable-cmsis-dap \
    && make -j"$(nproc)" \
    && make install
    #remove unneeded directories
    RUN cd ..
    RUN rm -rf /usr/src/openocd \
    && rm -rf /var/lib/apt/lists/
    #OpenOCD talks to the chip through USB, so we need to grant our account access to the FTDI.
    RUN cp /usr/local/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d/60-openocd.rules

    #create a directory for our project & setup a shared workfolder between the host and docker container
    RUN mkdir -p /usr/src/app
    VOLUME ["/usr/src/app"]
    WORKDIR /usr/src/app
    RUN cd /usr/src/app

    EXPOSE 4444

A Dockerfile is a set of instructions to build and create an image. After each instruction the docker build commits a new layer. If a layer hasn’t changed, it doesn’t need to be rebuilt the next time the build runs. Instead, the cached layers are used. This layering system is one of the reasons why Docker is so fast.
Let’s go through a brief overview of the instructions used in this Dockerfile:
-FROM tells the Docker with which image to start. All Docker images need to have one root image. In this case it is the official ubuntu image.
-WORKDIR sets the current working directory for subsequent instructions.
-RUN starts arbitrary commands during the build process. so the processes is for downloading and installing GCC for arm and GDB to debug our application and finaly openocd as a GDB server.
-VOLUME adds files from the host file system into the Docker container.
Note that there are several instructions. The reason for this are the different layers.
-ARG sets environment variables. for build-time customization
-EXPOSE exposes PORTS from the container.

Build Docker image:

With the instructions ready all that remains is to run the â€˜docker build’ command, Go to the directory that has your Docker file and run our famous command. after that set the name of our image with â€˜-t’ parameter.

$ docker build -t docker-arm .

the image will now be listed by docker:

$ docker images

Run Docker container:

Running your image with â€˜-it’ gives you a running shell inside the container. using -v “volume” will make the directory /usr/src/app inside the container live outside the Union File System and directly accessible on the folder “app” on our host and also to have access to our usb device with root privileges. the -p flag redirects a public port to a private port inside the container. Run the image you previously built:

    $ docker run -it --name docker-arm -p 4444:4444 -v "$(pwd)/app":/usr/src/app --privileged -v /dev/bus/usb:/dev/bus/usb docker-arm /bin/bash

after that we will have access to our container using bash
to Print the output of your container:

$ docker ps -a

Deploy our Project and run it inside Docker Container:

For testing our environment, I created a blink led project for stm32f407vg6, you can clone the project from the Github Repo and paste the content of app folder into your workspace where your Dockerfile is located. you will end up with a directory structure similar to the one bolow :

    $ tree -L 3
    .
    â”œâ”€â”€ app
    â”‚   â”œâ”€â”€ blinky
    â”‚   â”‚   â”œâ”€â”€ main.c
    â”‚   â”‚   â”œâ”€â”€ Makefile
    â”‚   â”‚   â”œâ”€â”€ stm32f4xx_conf.h
    â”‚   â”‚   â”œâ”€â”€ stm32_flash.ld
    â”‚   â”‚   â””â”€â”€ system_stm32f4xx.c
    â”‚   â””â”€â”€ STM32F4-Discovery_FW_V1.1.0
    â”‚   â”œâ”€â”€ _htmresc
    â”‚   â”œâ”€â”€ Libraries
    â”‚   â”œâ”€â”€ MCD-ST Liberty SW License Agreement 20Jul2011 v0.1.pdf
    â”‚   â”œâ”€â”€ Project
    â”‚   â”œâ”€â”€ Release_Notes.html
    â”‚   â””â”€â”€ Utilities
    â”œâ”€â”€ Dockerfile
    â””â”€â”€ README.md

So after that we need to compile our project using gcc for arm :

$ cd blinky
$ make

Then, we will found that there are a new files : “main.elf,main.bin and main.hex”

$ ls

after compiling our project, let’s flash it into the Board with openocd using :

 $ openocd -s "/usr/local/share/openocd/scripts" -f "interface/stlink-v2.cfg" -f "target/stm32f4x.cfg" -c "program blinky.elf verify reset exit")
```


##Conclusion
as you can see, it’s really easy to configure an embedded system project using docker, we only need a Docker file in order to configure our environment.

with our new project we are ready to start developing Applications .

see you next time.
#If you enjoyed reading, please support my work by hitting that little heart!

[FYI: this article originally appeared on my website.](http://nodeit.azurewebsites.net/using-docker-embedded-systems-development/)