Hermes Agent Not Remembering Conversations: Fixes

Your Agent Was Supposed to Remember

You told Hermes Agent about your project on Monday. By Wednesday, it introduces itself as if you have never met. The promise of persistent memory is the whole reason you picked a self-hosted agent over ChatGPT, and now it feels like the same amnesiac tool with more setup steps.

The good news is that Hermes Agent's memory system is simple enough to diagnose from the outside. MEMORY.md and USER.md are plain markdown files on disk. If the agent is not remembering, one of four things is happening, and each one has a specific fix.

How Hermes Agent Memory Actually Works

Before diagnosing, it helps to know the shape of what is broken.

Hermes Agent writes two kinds of memory to the data directory (usually ~/.hermes/memories/):

• MEMORY.md - agent-curated notes about your projects, preferences, and workflows. Bounded at roughly 2,200 characters so the model is forced to prioritize.
• USER.md - a stable profile of who you are, your role, stack, and communication style.

At the start of every session, the agent reads both files and injects them into the system prompt. During the session, it updates them automatically based on what you talked about. When the session ends, the files stay on disk.

That last sentence is the entire promise. If the files are not on disk after a restart, memory is not persisting. If the files are there but the agent still forgets, something else is going wrong. Those are two different bugs.

For a fuller walkthrough of the memory system itself, see how Hermes Agent memory and skills work. This post is only about the failure modes.

Cause 1: The Data Volume Is Not Mounted

This is the single most common cause. Symptom: the agent works fine for a whole conversation, remembers everything you told it five minutes ago, then the container restarts and it forgets you exist.

What is happening: the memory files are being written inside the container's writable layer instead of a persistent volume. When you docker stop and docker start, the container's writable layer survives. When you docker rm (or docker compose down, or the host reboots and recreates the container), the writable layer is destroyed and MEMORY.md dies with it.

Check first: does the memory directory actually exist on your host?

ls -la ~/.hermes/memories/

If that directory is empty or missing after your agent has been running for a while, the container is not writing there.

The fix: mount ~/.hermes as a volume. In docker run:

docker run -v ~/.hermes:/root/.hermes ...

In docker-compose.yml:

services:
  hermes:
    volumes:
      - ~/.hermes:/root/.hermes

After the change, recreate the container (not just restart it) and verify the memories directory populates on the host as you use the agent. The Hermes Agent Docker guide covers the full compose file.

Cause 2: Volume Mounted But Permissions Are Wrong

You mounted the volume, the directory exists on the host, but the files are still empty or the agent's logs mention "permission denied" when it tries to write.

The container and the host share the same numeric UID space, and nothing reconciles them by default. If your agent runs as UID 1000 inside the container and the host directory is owned by root, the write silently fails. On Fedora, RHEL, and other SELinux-enabled distributions, the write is denied even when standard Unix permissions would allow it, and Docker will not warn you.

Check the ownership:

ls -ln ~/.hermes/memories/

Fix, plain Docker: make the host directory writable by the same UID the container uses:

sudo chown -R $(id -u):$(id -g) ~/.hermes

Fix, SELinux hosts: add the :Z label to the volume mount so Docker relabels it for container access:

volumes:
  - ~/.hermes:/root/.hermes:Z

Fix, rootless Docker: container "root" is mapped to your host UID via user namespaces, not actual UID 0. The chown above already handles this, but the mental model catches people out when they try to sudo into the file and it still fails.

Cause 3: The Context Window Is Full, Not the Memory File

Symptom: MEMORY.md is on disk, it has your project notes in it, cat shows the content, and the agent still acts like it does not remember. This is not a memory bug. It is a context window bug wearing memory's clothes.

Hermes Agent reads MEMORY.md and USER.md into the system prompt at session start, but it also carries the current conversation history in the same context window. If the combined size exceeds the model's context limit, older tokens are truncated first. Even before the hard limit, the "lost in the middle" effect kicks in: models retrieve information reliably from the beginning and end of context, and much less reliably from the middle.

So the memory file may be present and correct, but by turn 30 of a long conversation, the model has been served a truncated or middle-buried version and behaves as if it never saw it.

Diagnostics:

• Compare model context windows. Check the model you have configured. A smaller-window model will hit this sooner than a 200k or 1M-token model.
• Check MEMORY.md size. If it is near the 2,200 character cap, that is fine. If an older Hermes version let it grow to 20k, trim it.
• Look at the length of the current session. Long single sessions are more prone to this than short frequent ones.

Fixes:

• Switch to a larger-context model in your config.
• Trim MEMORY.md by hand if it has grown past its cap.
• Restart the session periodically. Hermes reads memory fresh at session start, so a new session loads MEMORY.md and USER.md into a clean context.

The same failure mode is described from a different angle in the Telegram troubleshooting guide under "messages come through but agent ignores the content." It is the same underlying bug across channels.

Cause 4: Per-Chat vs Global Memory Confusion

Some deployments run one Hermes Agent process per Telegram chat, others share memory across chats. If you told the agent something in a private DM and it does not know that thing when you switch to a group chat, you are looking at a scope mismatch, not a persistence bug.

Diagnostics:

• Read your config. If there is a per-chat data directory pattern, memory is scoped per chat by design.
• If you are on a self-hosted setup with a single ~/.hermes directory shared across all chats, memory is global and you should look elsewhere for the cause.
• If you are running multiple Hermes processes against the same home directory to serve different chats, you have a different problem entirely: two writers to the same MEMORY.md will overwrite each other and the file will end up in a state neither process authored. Don't do this.

Fix: decide which model you want and configure to match. Most self-hosted operators want global memory (one you, one agent, all chats). Multi-user or multi-tenant deployments usually want per-chat isolation. Both are valid, but they are not interchangeable.

Recovering After a Bad Restart

If MEMORY.md is corrupted, truncated to zero bytes, or contains garbled content after a crash or a bad shutdown, the recovery path is straightforward because it is a plain markdown file.

1. Stop the agent before touching the file. A running agent may write over your recovery attempt.
2. Check for backups. If you followed the guidance in migrating Hermes Agent to a new machine, you already have periodic snapshots of ~/.hermes. Restore the most recent good snapshot.
3. Edit by hand if needed. MEMORY.md is markdown. Open it in a text editor, remove the corrupted section, save. There is no schema to satisfy.
4. Start the agent and confirm the recovered memory shows up in the next session.

If you did not have backups, this is the moment to set them up. A daily tar czf hermes-backup-$(date +%F).tar.gz ~/.hermes in cron takes seconds and buys you a working recovery path for the next incident.

When to Stop Debugging and Delegate the Infrastructure

Every fix in this post is a small correction to how the container is wired. None of them is hard on its own. What burns time is discovering them the day your agent forgets a two-week project mid-conversation, then realizing the volume was never mounted, the permissions were wrong, and there is no backup to fall back on.

If you would rather never see a "permission denied" line in a Hermes log again, Hermify runs a managed Hermes Agent on Telegram with the same MEMORY.md and USER.md files, mounted correctly, backed up nightly, and restorable with one click. Your memory stays yours (the files are encrypted at rest and downloadable), and the volume-mount debugging stops being your problem.

For a broader look at how the deployment tradeoff shakes out, see Hermes Agent hosting vs self-hosting.

Get started with Hermify and skip the memory-persistence checklist entirely.

Sources

• Hermes Agent memory reference
• Hermes Agent Docker guide
• Docker volume permission issues on non-root containers
• Context window is RAM, not storage (Mem0)
• LLM context windows and truncation (Redis)