**Deterministic reproduction and the mechanism — still present in 1.13.7**
I’ve been hit by this: roughly fifteen notes in my vault silently replaced with other notes’ content over several weeks. I built (OK, Claude built) a test vault to isolate it, and I believe I have the mechanism plus a reliable way to reproduce it. It still reproduces on **1.13.7**, after the 1.10+ file-opening changes mentioned earlier in this thread.
### The mechanism
When you switch to a note whose content takes time to load, **the editor keeps showing — and holding — the previous note’s text, but has already retargeted to the new file.** A keystroke in that window edits the previous note’s buffer, and autosave writes it into the new note’s file.
It is **silent**. At the moment it happens, the UI goes on to show the new note’s *correct* content once loading finishes. The wrong content is on disk only, and appears on the next fresh read — which is why it can go unnoticed for weeks.
### Steps to reproduce
Restricted mode: **no community plugins**, default core plugins. Using iCloud Drive on macOS purely as a reliable way to make one file load slowly; I don’t think iCloud is the cause — see “Why slow load” below.
1. Create a vault in iCloud Drive, in a folder **not** set to “Keep Downloaded”, with *Optimise Mac Storage* on (so macOS allows eviction).
2. Create two notes with clearly distinguishable content, e.g. `note-100.md` containing “This is note-100” and `note-014.md` containing “This is note-014”.
3. Evict the second note so its content must be downloaded when opened: `brctl evict note-014.md`. Confirm with `ls -lO note-014.md` — it should show `dataless`.
4. Open `note-100` and let it load fully.
5. Switch to `note-014` using ordinary navigation (I used the file explorer).
6. **Type a character before `note-014` finishes loading.** It appears in `note-100`'s displayed text.
7. Wait for `note-014` to load. It displays its own correct text; the typed character has vanished.
8. Switch back to `note-100` (correct), then back to `note-014`.
### Expected
`note-014.md` is unchanged, or at worst contains its own text plus the typed character. `note-100.md` is unaffected.
### Actual
`note-014.md` on disk now contains **`note-100`'s entire text plus the typed character**, with a fresh modification time. `note-100.md` is untouched. The damage shows at step 8, not at step 7.
### Why “slow load” rather than “iCloud”
I tested each ingredient separately against 300 self-identifying notes (each note’s text states its own ID, so any substitution names its source):
| condition | Obsidian involved | substitutions |
|—|—|—|
| evicted files downloaded by Finder, no app open | no | 0 of 553 |
| evicted files read with `cat` | no | 0 of 5 |
| evicted files written by shell (append and overwrite) | no | 0 of 6 |
| vault open in Obsidian, evicted notes left untouched (60 s) | yes, passive | 0 of 5 |
| evicted notes opened in Obsidian, **no typing** | yes | 0 of 5 |
| evicted note opened, **typed during load** | yes | **1 of 1** |
iCloud reads and writes on their own are clean, and Obsidian viewing without typing is clean. It takes **Obsidian’s editor plus a slow load**. Eviction is just the most reliable way I found to make the load slow on demand. Any other cause of a slow open — a large vault, a sync client or plugin touching the file, rapid navigation while a previous load is still in flight — should open the same window. That would explain the reports above from Obsidian Sync and local vaults, and the pattern of **rapid navigation** (clicking quickly through Calendar days, repeated Back) that several people describe.
I also checked inode numbers throughout: they never change and are never reused, so this doesn’t look like file identity getting confused at the filesystem level.
### Suggested fix direction
Either don’t accept edits — or don’t autosave — until the newly opened file’s content has actually loaded; or bind the save target to the buffer that was loaded rather than to the currently-selected path. The core problem is a window in which the displayed buffer and the save target belong to different files.
### Environment
- Obsidian **1.13.7** (installer 1.12.7)
- macOS 15.7.4 (24G517), Apple Silicon
- Reproduced in restricted mode, no community plugins
- Real-vault damage occurred with community plugins enabled (Calendar, Dataview, Templater, Local REST API, plus a custom plugin) — consistent with the mechanism rather than caused by any one plugin
### Test harness
Happy to share the small Python script that generates the self-identifying vault and a verifier that reports intact / evicted / substituted notes without reading evicted files (reading an evicted file forces a download, which would disturb the experiment).
(Full disclosure: Claude Code wrote this bug report, but I did sit with it during all the testing and have read and approved the report.)
. Fortunately I could recover those affected notes.