Maintaining Claude Memory Across Multiple DevContainers
This page has been translated by machine translation. View original
The Claude Code memory extension MCP plugin "claude-mem" is convenient.
You can reuse and share past context.
However, I encountered an issue when developing in DevContainers.
The problem is that claude-mem information cannot be shared between multiple DevContainers.
In this article, I'll introduce a method to share claude-mem information between DevContainers by running a worker on the host PC with a socat proxy, while sharing the SQLite database using bind mount.
Please also check our company blog for explanations about Claude Code setup in DevContainers and claude-mem.
Conclusion First
Start the claude-mem worker on your host PC, and add socat relay and SQLite bind mount settings to docker-compose.yml.
services:
claude-mem-proxy:
image: alpine/socat:latest
command: TCP-LISTEN:37777,fork,reuseaddr TCP:host.docker.internal:37777
app:
# ...(existing settings)
volumes:
# Mount host SQLite to Docker home folder
- ~/.claude-mem:/home/node/.claude-mem
network_mode: "service:claude-mem-proxy"
depends_on:
- claude-mem-proxy
HTTP communication to the Worker reaches the host PC worker via claude-mem-proxy, and direct SQLite writes from Hooks reach the host PC's DB file via bind mount.
What is claude-mem?
claude-mem is a plugin that automatically records Claude Code session content, organizes it with AI, and saves it to a local DB.
Stored information can be retrieved using a hybrid search combining full-text search (SQLite) and vector search (ChromaDB), and used as context for future sessions.
claude-mem architecture
The claude-mem plugin consists primarily of the following three components:
Worker
An HTTP server running on localhost:37777. It runs in the background, providing full-text search API endpoints and Viewer UI.
Hook
Event handlers that trigger according to the Claude Code lifecycle. They operate during SessionStart, UserPromptSubmit, PostToolUse, Stop, etc. Data is saved by writing directly to SQLite or by HTTP POST to the Worker for asynchronous processing.
MCP
An MCP that searches and retrieves memories from past sessions.
It is called from Claude Code and sends requests to the Worker's HTTP API to retrieve data.
Here's a conceptual image:
References
Solution: Run worker on host PC with proxy & SQLite sharing
Based on the architecture described above, using host claude-mem in devcontainers requires two bridges.
HTTP requests to the Worker are forwarded to the host via socat, and direct DB writes from Hooks are shared via bind mount of the host's SQLite files.
For the method of forwarding to the host PC with socat, please refer to the blog I wrote recently.
Here's a conceptual image:
The key points of this configuration are:
- HTTP communication to the Worker is forwarded to the host PC worker via socat relay
- Direct SQLite writes from Hooks reference the host PC's DB files via bind mount
- Multiple DevContainers share the same host worker and DB, so memories are naturally shared
- Even if containers are recreated, the host's worker and DB remain, so memories are preserved
Procedure
Prerequisites
- Claude Code and claude-mem plugin installed on host PC
- Docker and Docker Compose installed
1. Start claude-mem worker as an HTTP server on the host PC
Start the claude-mem worker as a network-accessible server on the host PC.
The easiest way is to launch Claude Code with the claude-mem plugin installed on the host PC, allowing the SessionStart hook to start the worker.
You could also create a script or alias based on the worker startup method visible in the hooks command.
Reference: claude-mem/plugin/hooks/hooks.json at main · thedotmack/claude-mem
2. Edit docker-compose.yml
Since I use docker compose for devcontainer settings, I'll explain using docker compose.
Add the claude-mem-proxy service to docker-compose.yml and share the network with the main app service.
services:
# Relay service to host PC's claude-mem worker
claude-mem-proxy:
image: alpine/socat:latest
command: TCP-LISTEN:37777,fork,reuseaddr TCP:host.docker.internal:37777
## Required for Linux environments
# extra_hosts:
# - host.docker.internal:host-gateway
app:
# ...(existing settings)
volumes:
# Mount host's SQLite to Docker home folder
- ~/.claude-mem:/home/node/.claude-mem
network_mode: "service:claude-mem-proxy"
depends_on:
- claude-mem-proxy
3. Rebuild the devcontainer
After configuration, rebuild the devcontainer.
Run Rebuild Container from the VS Code command palette.
4. Install claude-mem plugin in Claude Code on Docker
Launch Claude Code on Docker and install the claude-mem plugin.
The procedure is the same as installing the claude-mem plugin on the host PC, so I'll omit it.
Verification
Check if the host PC's worker is visible from Docker.
# Run inside container
$ curl localhost:37777/health
{"status":"ok","timestamp":1772071782619}
Try using the /mem-search skill in Claude Code chat to confirm that memories from previous sessions can be searched.
# Run inside container (Claude Code)
/mem-search I want to check if past data can be retrieved correctly
● Search successful. Checking details of several records.
● plugin:claude-mem:mcp-search - get_observations (MCP)(ids: [361,360])
⎿ [
{
"id": 361,
… +42 lines (ctrl+o to expand)
● Past data is being retrieved correctly.
Verification results:
- Search: 26 hits for "blog" query (10 observations, 10 sessions, 6 prompts)
- Latest record: Data up to February 25, 2026 recorded
- Detailed retrieval: Complete data for ID #360, #361 (facts, narrative, concepts) returned normally
All past work history is properly saved and searchable. The memory system is functioning normally.
Conclusion
For security concerns, I usually prefer to limit AI agents' access range to within containers, so I develop in devcontainers with enclosed environments.
The claude-mem plugin was very interesting, but it didn't work well with devcontainers.
I think this configuration offers a good balance between security and convenience.
I hope this blog helps someone.
