Skip to content

Concurrent Claude Sessions Silently Clobber Vault Journal Writes

Symptom

A write to the daily journal succeeds, is confirmed by the tool that made it, and is simply gone minutes later. No error, no conflict marker, no backup file — the line never appears again, and nothing in either session reports a problem.

What happened (2026-08-22, MajorM5Pro)

A Claude Code session added a Carry Forward task via mcp__majorvault__journal_add_carry_forward. The tool returned success:

{ "date": "today", "section": "backlog", "inserted_at_line": 19, "line": "- [ ] [MajorWiki] ..." }

Ten minutes later the line was absent — grep -c returned 0. The file's mtime had advanced to a time the Code session had not written. A Cowork session running on the same machine had written the journal in between.

Cause

Both sessions read the whole journal, modify it in memory, and write it back. There is no locking, no merge, and no compare-and-swap. If session B reads the file before session A writes, B's write silently discards everything A added:

A reads  ──────────────► A writes (line added)
   B reads ─────────────────────────► B writes (A's line gone)

Last writer wins the entire section, not just the conflicting line.

This is not an Obsidian Sync problem

The first instinct is to blame Sync propagating a copy from another machine. It is worth checking, but it was wrong here — both sessions were on the same host writing the same file on the same disk. Sync was never involved. Confirm before assuming: if MAJORVAULT_PATH is correct and only one copy of the file exists on disk (find ~ -name "YYYY-MM-DD.md" -path "*10-Journal*"), it is a local race.

What is and is not protected
📝 Notes scratchpad Protected — mcp-majorvault's journal.py preserves it explicitly
Every other journal section Not protected — no locking between sessions
Git-backed repos (MajorDocs, MajorAnsible) Partially — see the correction below
Vault .md files generally Not protected — no equivalent guard exists

The branching convention that makes concurrent work safe covers git repos only. Vault files have no equivalent, and the daily journal is the file most likely to be written by two sessions at once.

Correction, 2026-09-07: git repos are only partially protected

This article originally listed git-backed repos as simply "protected by the branching convention." That is too strong. The convention guards against branching off a stale main and against committing directly to main — both of which assume each session controls its own HEAD.

When sessions share one working copy, that assumption fails: git checkout belongs to the checkout, not the session, so a concurrent session switching branches silently redirects the next git add/commit onto their branch. Demonstrated on 2026-09-07 in ~/MajorAnsible — a commit landed on another session's branch, the merge reported success, and the change never reached main.

Full writeup and the fix (assert the branch before committing; per-session git worktree): Concurrent Sessions in One Git Checkout: Commits Land on the Wrong Branch

Mitigation

  • Treat the project file as the durable record. 20-Projects/*.md is the source of truth by convention anyway, and is far less likely to be rewritten wholesale than the daily note. A task that exists only in Carry Forward can vanish; one in its project file will not.
  • Verify the write, do not trust the return value. grep -c the file after writing anything that matters. A success response only proves the write happened, not that it survived.
  • Do not re-add defensively in a loop. Racing another agent just produces duplicates when both writes land. Re-add once, then leave it.
  • Annotate ownership when two sessions share a task. Marking a task claimed (🟡 being handled on Cowork — do not start from a Code session) in the project file stops the other session duplicating the work, and survives a journal clobber.