claude-code - 💡(How to fix) Fix [BUG] Concurrent-write race on shared MEMORY.md across concurrent Claude Code sessions in the same git repo [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

Claude Code's auto-memory system stores files at ~/.claude/projects/<encoded-git-root>/memory/, with MEMORY.md as the index. All Claude Code sessions launched inside the same git repository (including subdirectories and worktrees) share that single memory directory and index file.

When two sessions are concurrently active in the same repo and each appends a memory entry, both processes can write to MEMORY.md without coordination. One of the index-line additions can be lost. The Claude Code documentation does not specify any file-locking or write-coordination behavior for this case.

Environment

• Affects any multi-session workflow rooted in a single git repo (multi-pane terminal, tmux, multiple IDE windows, agent-orchestration setups, etc.)
• Storage path: ~/.claude/projects/<encoded-git-root>/memory/MEMORY.md
• Not OS-specific in theory; the absence of documented locking is the root issue

Why this matters

Multi-session and multi-agent Claude Code workflows are increasingly common. Several adjacent concurrent-session races have already been reported (.claude.json corruption #28847 / #29036 / #29198, OAuth refresh #24317 / #25609, AutoUpdater #19063). Auto-memory is the latest piece of shared mutable state and deserves the same hardening — or at least a documented warning.

What Should Happen?

One of the following:

1. Documented concurrency semantics for MEMORY.md writes (so users know what happens and can avoid the scenario), OR
2. File locking (flock / equivalent advisory lock around the read-modify-write), OR
3. Atomic append for index lines (each entry written as a single O_APPEND write that the OS guarantees won't interleave for small writes), OR
4. Per-session memory scoping so concurrent sessions never share a single mutable index (see the per-session-memory feature request filed separately).

Error Messages/Logs

Steps to Reproduce

Reproduction (conceptual):

1. Open two Claude Code sessions whose working directories are inside the same git repository.
2. In each session, trigger an auto-memory write near-simultaneously (anything that causes the assistant to append a new index entry to MEMORY.md).
3. Inspect MEMORY.md afterwards. If both writes occurred without file-level coordination, the resulting file may contain only one of the two new index lines.

This is a classic last-writer-wins race when two processes do read-modify-write against the same text file with no advisory lock, no atomic rename, or no per-line append-only protocol.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.121 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Filed by an operator running ~30 artificial-person Claude Code sessions concurrently inside a single git repository, where this race is non-hypothetical. Submitted via Claude Code on the operator's behalf.