Continuous dotfiles watcher can publish false deletions through a shared scratch-index race

[moniquelive]

Sorry—this report is being written by an AI agent helping me investigate and recover from a dotfiles synchronization failure. The observations below include a reproduction using an unmodified mise release.

Summary

The continuous dotfiles watcher can record files as deleted even though they have not been deleted on disk. Those false deletions can then be published and applied on another machine, causing actual data loss there.

I encountered this between two macOS machines and reproduced the same pattern with stock mise 2026.9.7, using isolated temporary homes and a local Git origin.

Suspected cause: concurrent snapshot and synchronization operations reuse the same PID-based scratch Git index.

Environment

Component	Details
OS	macOS, Apple Silicon
Installation	Homebrew
Affected watcher	2026.9.5, still running after the installed executable was upgraded
Reproduced with	Stock mise 2026.9.7
Synchronization	history.sync = "sync" with a connected Git setup repository
Tracking	Explicit files and directories using mode = "track"
Service command	mise bootstrap dotfiles watch
Checkpoint descriptions	history.describe_command adds the machine name

The notebook’s stale watcher is relevant context, but the reproduction also failed on 2026.9.7, so restarting that process alone would not resolve this problem.

What happened

On September 14, 2026:

1. At 14:57:20 UTC−03, the notebook recorded a checkpoint removing 208 files.
2. Those paths were exactly the first 208 paths in the previous snapshot’s sorted, 264-file home/ subtree.
3. Neither the tracking configuration nor .mise-history/manifest.json changed in that checkpoint.
4. The checkpoint reported no incomplete capture or relevant read failures.
5. At 15:26:44 UTC−03, the desktop applied those incoming deletions and actually removed its copies.

When the notebook became reachable, all 208 files were still present there, with creation and modification timestamps predating the incident.

After recovery, all affected files on both machines match their original Git blobs.

This points to files being lost from the saved snapshot, rather than an ordinary filesystem deletion being synchronized.

Isolated reproduction

The reproduction used:

• Two temporary homes with separate mise configuration, data, cache, and state directories.
• A local bare Git repository as their shared origin.
• 80 sentinel files named file-000 through file-079.
• Two heartbeat files, edited independently on the two simulated machines.
• The continuous watcher on one machine and explicit syncs from the other.

Relevant configuration:

[settings]
experimental = true
history.sync = "sync"
history.sync_interval = "1s"
history.fetch_interval = "1s"
history.watch.debounce = "100ms"
history.watch.reconcile = "2s"
history.describe_command = "printf watcher"

[dotfiles]
"~/.config/example" = { mode = "track" }
"~/.config/mise" = { mode = "track" }

After saving and publishing the initial files, the second home adopted the local origin. The first home ran:

mise bootstrap dotfiles watch --json

The test repeatedly changed its heartbeat file while the second home changed the other heartbeat and ran:

mise bootstrap dotfiles sync

The test never removed any sentinel files.

Results

Mode	Result
Continuous watcher	Across 18 checkpoints, one recorded deletion of file-000 through file-050—an exact sorted prefix
Serialized watch --once runs	33 checkpoints, zero false deletions or watcher errors, all 80 sentinels preserved, and the peer’s final heartbeat edit received

The continuous watcher also emitted:

local saved history changed while planning; reconcile again

local saved history changed since planning; nothing was applied; run pull again

Suspected cause: shared scratch index

In HistoryRepo::compose() in v2026.9.7, the scratch index is named only by process ID:

let index = self
    .dir()
    .join(format!("mise-index-{}-compose", std::process::id()));
let _ = std::fs::remove_file(&index);

The function performs multiple Git operations against that index, then removes it again on completion.

Meanwhile, the continuous watcher starts synchronization on a background task, while capture can continue within the same process.

A PID-based filename separates different processes, but not concurrent composition calls within one process.

If another call resets or removes the index partway through snapshot construction, the resulting tree can lose files already inserted while retaining later files. That matches the sorted-prefix omissions observed in both the real incident and the isolated reproduction.

The historical incident was not instrumented at the individual Git-operation level, so that precise interleaving is inferred from the implementation and reproduction.

Expected behavior

• Concurrent capture and synchronization must not interfere with each other’s scratch indexes.
• A failed or interrupted snapshot build should fail without committing a truncated snapshot.
• Downstream machines must not receive a partial snapshot as intentional file deletions.

Could each composition invocation use its own scratch index, or otherwise serialize access across all operations sharing that index?

A regression test involving concurrent capture and synchronization against a second writer would help cover this.

Current workaround

Both machines retain:

[settings.history]
sync = "sync"

The continuous macOS watcher has been replaced with a native launchd timer running:

mise bootstrap dotfiles watch --once --json

The timer runs at login and every 60 seconds, without overlapping instances.

In one-shot mode, capture completes before synchronization/application, and description generation is awaited afterwards.

This retains automatic synchronization with approximately one-minute capture latency. No patched mise executable is involved.

Related reports checked

• PR #13038 — Keep history locks independent of cache directories
• Discussion #13189 — Stale watcher after an upgrade
• PR #13190 — Restart a history watcher that is not watching this store

These address related locking and stale-process problems, but I did not find an existing report covering concurrent reuse of the composition scratch index and the resulting false deletions.

---

[jdx]

Confirmed, and your diagnosis was exactly right. Thank you — the sorted-prefix detail is what made this findable, and the isolated reproduction against a stock release saved a lot of guessing.

Fix in #13195.

What was happening

HistoryRepo::compose() named its scratch index after the process id alone, and the watcher runs two compositions in one process: it saves checkpoints on its own thread while the synchronization it started plans on a blocking task. Those took different locks — capture the operation lock, sync the sync lock — so neither excluded the other, and both composed into the same file.

compose() resets the index and then inserts overlays one git invocation at a time. When the second composition reset the index partway through the first, everything the first had inserted was gone; its remaining overlays landed in the fresh index, and write-tree wrote a tree missing exactly the paths inserted before the reset. Overlays are sorted, so that is a sorted prefix. A capture composes onto the empty tree, so the truncated result read as a deliberate removal — committed, published, and applied elsewhere.

I turned this into a unit test that composes distinct snapshots from three threads at once. Against the unreleased code it fails on every run, in both forms:

26 composed paths were lost, first: home/0/file-0

fatal: Unable to create '.../mise-index-2764070-compose.lock': File exists.

The second form is the same collision caught by git's own index lock, which is why you also saw the reconcile warnings. The first is the silent one that cost you files.

The fix

Each composition now gets a scratch index of its own, removed when the call ends, plus a sweep of indexes left behind by an earlier process holding the same process id.

To your question — I went with a private index per invocation rather than serializing, because synchronization deliberately does not block saving and should keep not blocking it. Making composition reentrant fixes it at the right layer.

Your data

Worth saying explicitly: the blobs were never lost. Only one snapshot omitted them, so every affected file is recoverable from an earlier checkpoint on either machine — which matches what you found when you recovered and the contents matched their original blobs.

Your launchd workaround is sound in the meantime. watch --once completes its capture before synchronizing, so it never has two compositions in flight, which is why your 33 serialized checkpoints were clean while the continuous run was not.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: unavailable.